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 482b0b059dbe6ce5967ce507c8dd7d44663362a6..16cc0c73b8b85effe9b768e28fb274642ab864d1 100644 (file)
--- 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.