From: Tom Krizek Date: Mon, 30 Jan 2023 12:48:55 +0000 (+0100) Subject: Add container rebuild step to release checklist X-Git-Tag: v9.19.10~2^2~5 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=4b4bc897e14ae5876b6a13cf23cf4adfeca401e5;p=thirdparty%2Fbind9.git Add container rebuild step to release checklist It was agreed that the monthly CI container image rebuild should be done manually rather than be automated. This allows us to have control over when things could break and the end of the release cycle is the most convenient time to have that happen. --- diff --git a/.gitlab/issue_templates/Release.md b/.gitlab/issue_templates/Release.md index 482b0b059db..16cc0c73b8b 100644 --- a/.gitlab/issue_templates/Release.md +++ b/.gitlab/issue_templates/Release.md @@ -89,6 +89,7 @@ - [ ] ***(QA)*** Sanitize confidential issues which are assigned to the current release milestone and do not describe a security vulnerability, then make them public. - [ ] ***(QA)*** Sanitize confidential issues which are assigned to older release milestones and describe security vulnerabilities, then make them public if appropriate[^2]. - [ ] ***(QA)*** Update QA tools used in GitLab CI (e.g. Black, PyLint, Sphinx) by modifying the relevant `Dockerfile`. + - [ ] ***(QA)*** Run a pipeline to rebuild all [images](https://gitlab.isc.org/isc-projects/images) used in GitLab CI. [^1]: If not, use the time remaining until the tagging deadline to ensure all outstanding issues are either resolved or moved to a different milestone. [^2]: As a rule of thumb, security vulnerabilities which have reproducers merged to the public repository are considered okay for full disclosure.