Fixes the security template sections
What does this MR do and why?
- Fixes the security template sections
The 'Two days before the release day' section was rendered twice when the 'automatic_picking_process' FF was enabled. This commit fixes the section so it is only displayed once regardless if the feature flag is enabled or not.
Testing
Prework
I adjusted the code to enable all the feature flags by default
git diff
+++ b/lib/release_tools/patch_release/security_issue.rb
@@ -62,25 +62,34 @@ module ReleaseTools
end
def security_pipeline
- @security_pipeline ||= GitlabOpsClient.create_pipeline(
- Project::ReleaseTools,
- SECURITY_RELEASE_PIPELINE: 'true',
- SECURITY: ENV.fetch('SECURITY', nil)
- )
+ # @security_pipeline ||= GitlabOpsClient.create_pipeline(
+ # Project::ReleaseTools,
+ # SECURITY_RELEASE_PIPELINE: 'true',
+ # SECURITY: ENV.fetch('SECURITY', nil)
+ # )
+ Pipeline.new(web_url: 'foo')
end
+ Pipeline = Struct.new(:web_url)
+
protected
def dynamic_release_date?
Feature.enabled?(:dynamic_release_date)
+
+ true
end
def automatic_picking_process?
Feature.enabled?(:automatic_picking_process)
+
+ true
end
def combined_blog_post?
Feature.enabled?(:combined_blog_post)
+
+ true
end
Before with the FF enabled
The 'Two days before the due date' section is rendered twice
Click to expand
Security patch release: 16.4.2, 16.3.6, 16.2.9
First steps
-
Set the Due date on this issue with the planned Security publish date -
Start the security_release_prepare:start
job in the security release pipeline: foo-
Ensure the security_release:prepare
stage completes before continuing to the next section.
-
-
Modify the dates below to accurately reflect the plan of action. For example, if the planned due date is 28th, update the section titled "One day before due date" to "On 27th (One day before due date)".
Two days before due date
-
Check if the security release tracking issue contains any linked issues for projects under GitLab managed versioning (cng-ee, gitaly, gitlab-pages, omnibus-gitlab-ee). -
If there are any linked issues, follow the release manager instructions and adjust this issue to include any additional steps needed. -
If a Gitaly security fix is included in the upcoming security release, follow the How to deal with Gitaly security fixes guide.
-
-
Check the issues linked to the security release tracking issue. If there are any that DO NOT have the security-target label applied, check to make sure they are expected to be included, otherwise unlink them and point the assignees to the correct process. -
Merge the merge requests targeting default branches # In Slack /chatops run release merge --security --default-branch
-
Verify that the table of issues in the security release tracking issue has been updated showing the default MRs have been merged or set to Merge When Pipeline Succeeds (MWPS/auto-merge).
Two days before due date
-
After running the default merge chatops command for the last time, disable the security-target issue processor
pipeline schedule to ensure no other issues are linked to the security release tracking issue.
One day before due date
If this date is on a weekend, do this work on the next working day.
-
Start the security_release_blog_post:start
job of the security release pipeline: foo -
Check that all MRs merged into the default branch have been deployed to production: # In Slack: /chatops run auto_deploy security_status
NOTE: This only checks
gitlab-org/security/gitlab
. If other projects have security MRs you should verify those manually. -
Make sure to execute the post-deploy migration pipeline to ensure that all post-deploy migrations have been executed: /chatops run post_deploy_migrations execute
-
Unlink any security issues that are not ready from the security release tracking issue (in gitlab-org/gitlab
), and post a comment listing the issues that have been removed, why they have been removed (the reason returned by therun release merge
command), and ping the authors. Make sure to complete this step before merging backports to avoid picking up unexpected changes -
Merge backports and any other merge request pending: # In Slack: /chatops run release merge --security
-
Ensure all Merge Requets associated with Implementation Issues with label reduced backports
are merged -
If any merge requests could not be merged, investigate what needs to be done to resolve the issues. Do not proceed unless it has been determined safe to do so. -
Ensure tests are green in CE and green in EE # In Slack: /chatops run release status --security
-
If all the security issues have been deployed to production, consider tagging.
On the Due Date
Packaging
-
Ensure tests are green in CE and green in EE # In Slack: /chatops run release status --security
For the next task: Waiting between pipelines is necessary as they may otherwise fail to concurrently push changes to the same project/branch.
-
Tag the 16.4.2 security release, and wait for the pipeline to finish: /chatops run release tag --security 16.4.2
-
Tag the 16.3.6 security release, and wait for the pipeline to finish: /chatops run release tag --security 16.3.6
-
Tag the 16.2.9 security release, and wait for the pipeline to finish: /chatops run release tag --security 16.2.9
-
Check that EE and CE packages are built: - 16.4.2: EE packages and CE packages
- 16.3.6: EE packages and CE packages
- 16.2.9: EE packages and CE packages
Deploy
-
Verify that release.gitlab.net is running the latest patch version - Check in Slack
#announcements
channel - Go to https://release.gitlab.net/help
- Check in Slack
Release
Consider communicating with the AppSec counterpart before publishing to sync on the time of releasing the blog post. Emails to the security mailing list are normally handled as a follow up task and should not delay release tasks
-
Publish 16.4.2 via ChatOps: /chatops run publish --security 16.4.2
-
Publish 16.3.6 via ChatOps: /chatops run publish --security 16.3.6
-
Publish 16.2.9 via ChatOps: /chatops run publish --security 16.2.9
-
Notify AppSec counterparts they can submit the blog post to https://gitlab.com/gitlab-com/www-gitlab-com/
-
Verify that the check-packages
job completes:-
EE check-packages
on 16.4.2+ee.0 -
CE check-packages
on 16.4.2+ce.0 -
EE check-packages
on 16.3.6+ee.0 -
CE check-packages
on 16.3.6+ce.0 -
EE check-packages
on 16.2.9+ee.0 -
CE check-packages
on 16.2.9+ce.0
-
-
Deploy the blog post -
Create the versions: -
Create 16.4.2
version on version.gitlab.com. Be sure to mark it as a security release. TheVulnerability Type
column should indicate "No" for the new version. -
Create 16.3.6
version on version.gitlab.com. Be sure to mark it as a security release. TheVulnerability Type
column should indicate "No" for the new version. -
Create 16.2.9
version on version.gitlab.com. Be sure to mark it as a security release. TheVulnerability Type
column should indicate "No" for the new version.
-
Final steps
-
Start the security_release_finalize:start
job in the security release pipeline: foo -
Sync the GitLab default branch by using the merge-train project: -
Disable the gitlab-org/gitlab@master -> gitlab-org/security/gitlab@master
pipeline schedule on the merge-train. -
Trigger the gitlab-org/security/gitlab@master -> gitlab-org/gitlab@master
pipeline schedule on the merge-train and wait until it finishes. This pipeline will attempt to sync the GitLab default branch. -
If the sync fails, repeat the above step.
-
-
If after 5 times the sync by the merge train continues to fail, use the previous strategy to sync the GitLab project: -
Disable the merge_train_to_canonical
feature flag on ops. -
Enable the gitlab-org/gitlab@master -> gitlab-org/security/gitlab@master
pipeline schedule on the merge-train. -
Execute the sync_remotes
task on Slack:/chatops run release sync_remotes --security
. In this case, if the sync fails, a merge request will be created and release manager intervention will be required.
-
-
Verify all remotes are synced: # In Slack /chatops run mirror status
If conflicts are found, manual intervention will be needed to sync the repositories.
After with the FF enabled
Click to expand
Security patch release: 16.4.2, 16.3.6, 16.2.9
First steps
-
Set the Due date on this issue with the planned Security publish date -
Start the security_release_prepare:start
job in the security release pipeline: foo-
Ensure the security_release:prepare
stage completes before continuing to the next section.
-
-
Modify the dates below to accurately reflect the plan of action. For example, if the planned due date is 28th, update the section titled "One day before due date" to "On 27th (One day before due date)".
Two days before due date
-
Check if the security release tracking issue contains any linked issues for projects under GitLab managed versioning (cng-ee, gitaly, gitlab-pages, omnibus-gitlab-ee). -
If there are any linked issues, follow the release manager instructions and adjust this issue to include any additional steps needed. -
If a Gitaly security fix is included in the upcoming security release, follow the How to deal with Gitaly security fixes guide.
-
-
Check the issues linked to the security release tracking issue. If there are any that DO NOT have the security-target label applied, check to make sure they are expected to be included, otherwise unlink them and point the assignees to the correct process. -
Merge the merge requests targeting default branches # In Slack /chatops run release merge --security --default-branch
-
Verify that the table of issues in the security release tracking issue has been updated showing the default MRs have been merged or set to Merge When Pipeline Succeeds (MWPS/auto-merge). -
After running the default merge chatops command for the last time, disable the security-target issue processor
pipeline schedule to ensure no other issues are linked to the security release tracking issue.
One day before due date
If this date is on a weekend, do this work on the next working day.
-
Start the security_release_blog_post:start
job of the security release pipeline: foo -
Check that all MRs merged into the default branch have been deployed to production: # In Slack: /chatops run auto_deploy security_status
NOTE: This only checks
gitlab-org/security/gitlab
. If other projects have security MRs you should verify those manually. -
Make sure to execute the post-deploy migration pipeline to ensure that all post-deploy migrations have been executed: /chatops run post_deploy_migrations execute
-
Unlink any security issues that are not ready from the security release tracking issue (in gitlab-org/gitlab
), and post a comment listing the issues that have been removed, why they have been removed (the reason returned by therun release merge
command), and ping the authors. Make sure to complete this step before merging backports to avoid picking up unexpected changes -
Merge backports and any other merge request pending: # In Slack: /chatops run release merge --security
-
Ensure all Merge Requets associated with Implementation Issues with label reduced backports
are merged -
If any merge requests could not be merged, investigate what needs to be done to resolve the issues. Do not proceed unless it has been determined safe to do so. -
Ensure tests are green in CE and green in EE # In Slack: /chatops run release status --security
-
If all the security issues have been deployed to production, consider tagging.
On the Due Date
Packaging
-
Ensure tests are green in CE and green in EE # In Slack: /chatops run release status --security
For the next task: Waiting between pipelines is necessary as they may otherwise fail to concurrently push changes to the same project/branch.
-
Tag the 16.4.2 security release, and wait for the pipeline to finish: /chatops run release tag --security 16.4.2
-
Tag the 16.3.6 security release, and wait for the pipeline to finish: /chatops run release tag --security 16.3.6
-
Tag the 16.2.9 security release, and wait for the pipeline to finish: /chatops run release tag --security 16.2.9
-
Check that EE and CE packages are built: - 16.4.2: EE packages and CE packages
- 16.3.6: EE packages and CE packages
- 16.2.9: EE packages and CE packages
Deploy
-
Verify that release.gitlab.net is running the latest patch version - Check in Slack
#announcements
channel - Go to https://release.gitlab.net/help
- Check in Slack
Release
Consider communicating with the AppSec counterpart before publishing to sync on the time of releasing the blog post. Emails to the security mailing list are normally handled as a follow up task and should not delay release tasks
-
Publish 16.4.2 via ChatOps: /chatops run publish --security 16.4.2
-
Publish 16.3.6 via ChatOps: /chatops run publish --security 16.3.6
-
Publish 16.2.9 via ChatOps: /chatops run publish --security 16.2.9
-
Notify AppSec counterparts they can submit the blog post to https://gitlab.com/gitlab-com/www-gitlab-com/
-
Verify that the check-packages
job completes:-
EE check-packages
on 16.4.2+ee.0 -
CE check-packages
on 16.4.2+ce.0 -
EE check-packages
on 16.3.6+ee.0 -
CE check-packages
on 16.3.6+ce.0 -
EE check-packages
on 16.2.9+ee.0 -
CE check-packages
on 16.2.9+ce.0
-
-
Deploy the blog post -
Create the versions: -
Create 16.4.2
version on version.gitlab.com. Be sure to mark it as a security release. TheVulnerability Type
column should indicate "No" for the new version. -
Create 16.3.6
version on version.gitlab.com. Be sure to mark it as a security release. TheVulnerability Type
column should indicate "No" for the new version. -
Create 16.2.9
version on version.gitlab.com. Be sure to mark it as a security release. TheVulnerability Type
column should indicate "No" for the new version.
-
Final steps
-
Start the security_release_finalize:start
job in the security release pipeline: foo -
Sync the GitLab default branch by using the merge-train project: -
Disable the gitlab-org/gitlab@master -> gitlab-org/security/gitlab@master
pipeline schedule on the merge-train. -
Trigger the gitlab-org/security/gitlab@master -> gitlab-org/gitlab@master
pipeline schedule on the merge-train and wait until it finishes. This pipeline will attempt to sync the GitLab default branch. -
If the sync fails, repeat the above step.
-
-
If after 5 times the sync by the merge train continues to fail, use the previous strategy to sync the GitLab project: -
Disable the merge_train_to_canonical
feature flag on ops. -
Enable the gitlab-org/gitlab@master -> gitlab-org/security/gitlab@master
pipeline schedule on the merge-train. -
Execute the sync_remotes
task on Slack:/chatops run release sync_remotes --security
. In this case, if the sync fails, a merge request will be created and release manager intervention will be required.
-
-
Verify all remotes are synced: # In Slack /chatops run mirror status
If conflicts are found, manual intervention will be needed to sync the repositories.
After with the FF disabled
Click to expand
Security patch release: 16.4.2, 16.3.6, 16.2.9
First steps
-
Set the Due date on this issue with the planned Security publish date -
Start the security_release_prepare:start
job in the security release pipeline: foo-
Ensure the security_release:prepare
stage completes before continuing to the next section.
-
-
Check if the security release tracking issue contains any linked issues for projects under GitLab managed versioning (cng-ee, gitaly, gitlab-pages, omnibus-gitlab-ee). -
If there are any linked issues, follow the release manager instructions and adjust this issue to include any additional steps needed.
-
-
Modify the dates below to accurately reflect the plan of action.
Early-merge phase
Up until one day before the Security Release due date
-
Merge the merge requests targeting default branches
# In Slack /chatops run release merge --security --default-branch
-
Verify if a Gitaly security fix is included in the upcoming security release, if it is, follow the How to deal with Gitaly security fixes guide.
On the 25th (three days before due date)
-
Check which security issues are not ready, and post a comment listing the issues that will be removed, why they will be removed (the reason returned by the run release merge
command), by when they need to be ready (next day), and ping the authors. This serves as a warning to authors who weren't aware that their security issue was not in an acceptable state, and should hopefully result in less security issues needing to be unlinked.
Two days before due date
-
After running the default merge chatops command for the last time, disable the security-target issue processor
pipeline schedule to ensure no other issues are linked to the security release tracking issue.
On the 27th (one day before due date)
If this date is on a weekend, do this work on the next working day.
-
Determine the security release manager from the schedule. Look for the security release manager of the latest released monthly version -
Post the following message to #sec-appsec
in Slack:<security-release-manager> We are starting the [security release](<link to this issue>), aiming for release tomorrow. Please create a blog post MR on gitlab-org/security/www-gitlab-com.
-
Once the blog post MR has been created by the security release manager, add a link to it here: https://gitlab.com/gitlab-org/security/www-gitlab-com/-/merge_requests/
-
Fetch the list of non-security MRs that will be included in these releases: /chatops run release pending_backports
-
Crosslink the list to #sec-appsec
letting the security release manager these should be included in the blog post.
-
-
Check that all MRs merged into the default branch have been deployed to production: # In Slack: /chatops run auto_deploy security_status
NOTE: This only checks
gitlab-org/security/gitlab
. If other projects have security MRs you should verify those manually. -
Make sure to execute the post-deploy migration pipeline to ensure that all post-deploy migrations have been executed: /chatops run post_deploy_migrations execute
-
Unlink any security issues that are not ready from the security release tracking issue (in gitlab-org/gitlab
), and post a comment listing the issues that have been removed, why they have been removed (the reason returned by therun release merge
command), and ping the authors. Make sure to complete this step before merging backports to avoid picking up unexpected changes -
Merge backports and any other merge request pending: # In Slack: /chatops run release merge --security
-
Ensure all Merge Requets associated with Implementation Issues with label reduced backports
are merged -
If any merge requests could not be merged, investigate what needs to be done to resolve the issues. Do not proceed unless it has been determined safe to do so. -
Ensure tests are green in CE and green in EE # In Slack: /chatops run release status --security
-
If all the security issues have been deployed to production, consider tagging.
On the Due Date
Packaging
-
Ensure tests are green in CE and green in EE # In Slack: /chatops run release status --security
For the next task: Waiting between pipelines is necessary as they may otherwise fail to concurrently push changes to the same project/branch.
-
Tag the 16.4.2 security release, and wait for the pipeline to finish: /chatops run release tag --security 16.4.2
-
Tag the 16.3.6 security release, and wait for the pipeline to finish: /chatops run release tag --security 16.3.6
-
Tag the 16.2.9 security release, and wait for the pipeline to finish: /chatops run release tag --security 16.2.9
-
Check that EE and CE packages are built: - 16.4.2: EE packages and CE packages
- 16.3.6: EE packages and CE packages
- 16.2.9: EE packages and CE packages
Deploy
-
Verify that release.gitlab.net is running the latest patch version - Check in Slack
#announcements
channel - Go to https://release.gitlab.net/help
- Check in Slack
Release
Consider communicating with the AppSec counterpart before publishing to sync on the time of releasing the blog post. Emails to the security mailing list are normally handled as a follow up task and should not delay release tasks
-
Publish 16.4.2 via ChatOps: /chatops run publish --security 16.4.2
-
Publish 16.3.6 via ChatOps: /chatops run publish --security 16.3.6
-
Publish 16.2.9 via ChatOps: /chatops run publish --security 16.2.9
-
Notify AppSec counterparts they can submit the blog post to https://gitlab.com/gitlab-com/www-gitlab-com/
-
Verify that the check-packages
job completes:-
EE check-packages
on 16.4.2+ee.0 -
CE check-packages
on 16.4.2+ce.0 -
EE check-packages
on 16.3.6+ee.0 -
CE check-packages
on 16.3.6+ce.0 -
EE check-packages
on 16.2.9+ee.0 -
CE check-packages
on 16.2.9+ce.0
-
-
Deploy the blog post -
Create the versions: -
Create 16.4.2
version on version.gitlab.com. Be sure to mark it as a security release. TheVulnerability Type
column should indicate "No" for the new version. -
Create 16.3.6
version on version.gitlab.com. Be sure to mark it as a security release. TheVulnerability Type
column should indicate "No" for the new version. -
Create 16.2.9
version on version.gitlab.com. Be sure to mark it as a security release. TheVulnerability Type
column should indicate "No" for the new version.
-
Final steps
-
Start the security_release_finalize:start
job in the security release pipeline: foo -
Sync the GitLab default branch by using the merge-train project: -
Disable the gitlab-org/gitlab@master -> gitlab-org/security/gitlab@master
pipeline schedule on the merge-train. -
Trigger the gitlab-org/security/gitlab@master -> gitlab-org/gitlab@master
pipeline schedule on the merge-train and wait until it finishes. This pipeline will attempt to sync the GitLab default branch. -
If the sync fails, repeat the above step.
-
-
If after 5 times the sync by the merge train continues to fail, use the previous strategy to sync the GitLab project: -
Disable the merge_train_to_canonical
feature flag on ops. -
Enable the gitlab-org/gitlab@master -> gitlab-org/security/gitlab@master
pipeline schedule on the merge-train. -
Execute the sync_remotes
task on Slack:/chatops run release sync_remotes --security
. In this case, if the sync fails, a merge request will be created and release manager intervention will be required.
-
-
Verify all remotes are synced: # In Slack /chatops run mirror status
If conflicts are found, manual intervention will be needed to sync the repositories.
Author Check-list
- [-] Has documentation been updated?