Skip to content

Blog post assigns to appsec for security changes

Steve Abrams requested to merge delivery19673-blog-assigns-to-reviewers into master

What does this MR do and why?

We are combining the security and patch releaese blog posts. This MR updates the Blog Post merge request generator so the merge request is also assigned to active AppSec release managers if there are security changes included in the blog post.

Related to gitlab-com/gl-infra/delivery#19673 (closed)

Testing

We can trust that the BlogMergeRequest class will assign to whichever ids are in the #assignee_ids method since this is a well tested and already working functionality of Issuable classes.

So here, we test the result of the assignee_ids method when there is and is not security changes:

~/workspace/gitlab-org/release-tools (delivery19673-blog-assigns-to-reviewers ✔) RELEASE_BOT_VERSION_TOKEN=REDACTED RELEASE_BOT_PRODUCTION_TOKEN=REDACTED be pry --gem
[1] pry(main)> mr = ReleaseTools::PatchRelease::BlogMergeRequest.new
=> #<ReleaseTools::PatchRelease::BlogMergeRequest>
[2] pry(main)> mr.assignee_ids
2023-10-12 20:21:52.498718 I ReleaseTools::ReleaseManagers::Schedule -- dynamic_release_date feature flag disabled. Using release_managers.yml as source
2023-10-12 20:21:52.499268 I ReleaseTools::ReleaseManagers::Schedule -- dynamic_release_date feature flag disabled. Using release_managers.yml as source
=> [10054776, 11761787]
[3] pry(main)> mr = ReleaseTools::PatchRelease::BlogMergeRequest.new(security_content: ['foo', 'bar'])
=> #<ReleaseTools::PatchRelease::BlogMergeRequest security_content=["foo", "bar"]>
[4] pry(main)> mr.assignee_ids
2023-10-12 20:22:23.206735 I ReleaseTools::ReleaseManagers::Schedule -- dynamic_release_date feature flag disabled. Using release_managers.yml as source
2023-10-12 20:22:23.206904 I ReleaseTools::ReleaseManagers::Schedule -- dynamic_release_date feature flag disabled. Using release_managers.yml as source
2023-10-12 20:22:23.853586 I ReleaseTools::ReleaseManagers::Schedule -- dynamic_release_date feature flag disabled. Using release_managers.yml as source
2023-10-12 20:22:24.201209 D ReleaseTools::GitlabClient -- [HTTParty] [2023-10-12 20:22:24 -0600] 200 "GET https://gitlab.com/api/v4/groups/4654006/members" -
=> [10054776, 11761787, 4992072, 9820844]

We can verify the same result with dynamic_release_date feature flag enabled:

~/workspace/gitlab-org/release-tools (delivery19673-blog-assigns-to-reviewers ✔) RELEASE_BOT_VERSION_TOKEN=REDACTED RELEASE_BOT_PRODUCTION_TOKEN=REDACTED be pry --gem
[1] pry(main)> mr = ReleaseTools::PatchRelease::BlogMergeRequest.new(security_content: ['foo', 'bar'])
=> #<ReleaseTools::PatchRelease::BlogMergeRequest security_content=["foo", "bar"]>
[2] pry(main)> mr.assignee_ids
2023-10-12 20:24:30.232778 I ReleaseTools::ReleaseManagers::Schedule -- dynamic_release_date feature flag enabled. Using gitlab-releases gem as source
2023-10-12 20:24:30.623589 I ReleaseTools::ReleaseManagers::Schedule -- dynamic_release_date feature flag enabled. Using releases.yml as source
2023-10-12 20:24:31.217632 I ReleaseTools::ReleaseManagers::Schedule -- dynamic_release_date feature flag enabled. Using gitlab-releases gem as source
=> [10054776, 11761787, 9820844, 13198912]
[3] pry(main)> 2023-10-12 20:24:31.757726 D ReleaseTools::GitlabClient -- [HTTParty] [2023-10-12 20:24:31 -0600] 200 "GET https://gitlab.com/api/v4/groups/4654006/members" -

This has one user ID that is different, but that is because the releases.yml contains different appsec names for 16.4 than release_managers.yml

Author Check-list

  • [-] Has documentation been updated?
Edited by Steve Abrams

Merge request reports