Blog post assigns to appsec for security changes
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?