Skip to content

Drop versions argument from security:issue task

Mayra Cabrera requested to merge remove-versions-arg-from-security-task-issue into master

What does this MR do and why?

Drop versions argument from security:issue task

At the beginning of time, the security:prepare task used to fetch the versions on the rake task via next_security_versions (https://gitlab.com/gitlab-org/release-tools/-/blob/98834945540fd9ad14b61cb27a732c093e64f577/lib/tasks/security.rake#L45). That bit was later removed in favor of the PatchCoordinator logic (fada897b) and in preparation for the maintenance policy extension.

The PatchCoordinator logic continues to be the SSOT of truth when it comes to calculating the next three versions (3e2dea62), so we can drop the versions parameter from the security:issue task

Test

Open up for a surprise 🎈

I've tested the security:issue rake task by invoking the security:prepare task on my local:

~/code/release-tools remove-versions-arg-from-security-task-issue*
16:06:58 ❯ TEST=true rake security:prepare



2024-06-18 16:07:29.652291 I [dry-run] ReleaseTools::PatchRelease::SecurityIssue -- Creating security pipeline
2024-06-18 16:07:30.109816 D [dry-run] ReleaseTools::GitlabClient -- [HTTParty] [2024-06-18 16:07:30 -0600] 200 "GET https://gitlab.com/api/v4/projects/gitlab-org%2Fgitlab/issues" -
2024-06-18 16:07:30.110675 I [dry-run] ReleaseTools::PatchRelease::SecurityIssue -- Creating security pipeline
2024-06-18 16:07:31.077481 I [dry-run] ReleaseTools::PatchRelease::SecurityIssue -- Creating security pipeline
2024-06-18 16:07:31.486286 I [dry-run] ReleaseTools::PatchRelease::SecurityIssue -- Creating security pipeline

Patch release: 17.0.3, 16.11.5, 16.10.8

First steps

  • Start the security_release_prepare:start job in the security pipeline: https://example.com/foo/bar/-/pipelines/1
    • 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 tracking issue contains any linked issues for projects under GitLab managed versioning that are not automatically processed (cng-ee, gitaly, gitlab-pages).

  • Before running the default merge chatops command, disable the security-target issue processor pipeline schedule to ensure no other issues are linked to the security tracking issue and no linked issues are inadvertently unlinked after this point.

  • Check the issues linked to the security 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 tracking issue has been updated showing the default MRs have been merged or set to Merge When Pipeline Succeeds (MWPS/auto-merge).

One day before the due date

If this date is on a weekend, do this work on the next working day.

  • Start the security_release_release_preparation:start job of the security pipeline: https://example.com/foo/bar/-/pipelines/1

  • 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

  • Merge backports and any other merge request pending:

    # In Slack:
/chatops run release merge --security

  • 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 17.0.3 patch release, and wait for the pipeline to finish: /chatops run release tag --security 17.0.3

  • Tag the 16.11.5 patch release, and wait for the pipeline to finish: /chatops run release tag --security 16.11.5

  • Tag the 16.10.8 patch release, and wait for the pipeline to finish: /chatops run release tag --security 16.10.8

  • Check that EE and CE packages are built. Please note the completion of the RAT-Tag job on the slow_jobs stage is not required for the next steps.

  • Check that the CNG Images are built. Do not play any manual jobs.

Deploy

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 17.0.3 via ChatOps:

    /chatops run publish --security 17.0.3

  • Publish 16.11.5 via ChatOps:

    /chatops run publish --security 16.11.5

  • Publish 16.10.8 via ChatOps:

    /chatops run publish --security 16.10.8

  • Verify with AppSec release managers if the blog post is ready to be published. Do not proceed until AppSec has given green light

  • Start the security_release_publish:start stage of the security pipeline: https://example.com/foo/bar/-/pipelines/1

  • Verify that the check-packages job completes:

  • Verify that Docker images appear on hub.docker.com: EE / CE

  • Create the versions:

    • Create 17.0.3 version on version.gitlab.com. Be sure to mark it as a security release. From the Security Release dropdown choose Non Critical. After it is created, the Vulnerability Type column should indicate No for the new version.
    • Create 16.11.5 version on version.gitlab.com. Be sure to mark it as a security release. From the Security Release dropdown choose Non Critical. After it is created, the Vulnerability Type column should indicate No for the new version.
    • Create 16.10.8 version on version.gitlab.com. Be sure to mark it as a security release. From the Security Release dropdown choose Non Critical. After it is created, the Vulnerability Type column should indicate No for the new version.

Final steps

  • Start the security_release_finalize:start job in the security pipeline: https://example.com/foo/bar/-/pipelines/1

  • Sync the GitLab default branch by using the merge-train project:

  • 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?
Edited by Mayra Cabrera

Merge request reports