From 4b4bc897e14ae5876b6a13cf23cf4adfeca401e5 Mon Sep 17 00:00:00 2001 From: Tom Krizek Date: Mon, 30 Jan 2023 13:48:55 +0100 Subject: [PATCH] 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. --- .gitlab/issue_templates/Release.md | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitlab/issue_templates/Release.md b/.gitlab/issue_templates/Release.md index 482b0b059d..16cc0c73b8 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.