Skip to content

Security tracking issue uses correct versions

Steve Abrams requested to merge fix-tracking-issue-versions into master

What does this MR do and why?

The most recent security release tracking issue was opened with the incorrect versions: 16.6.x, 16.4.x, 16.3.x. It should have been 16.5.x, 16.4.x, 16.3.x. Looking at where the 16.6 is coming from, it is from this line of code: https://gitlab.com/gitlab-org/release-tools/-/blob/6de084237a21a4539b64fce2188b8744d0194696/lib/release_tools/security/tracking_issue.rb#L85. We can see this also happened during the previous release.

Testing locally, we can see it brings up the incorrect version:

[1] pry(main)> ReleaseTools::ProductMilestone.next.title
2023-09-28 13:02:46.653496 I ReleaseTools::ReleaseManagers::Schedule -- dynamic_release_date feature flag enabled. Using gitlab-releases gem as source
2023-09-28 13:02:46.853148 D ReleaseTools::GitlabClient -- [HTTParty] [2023-09-28 13:02:46 -0600] 200 "GET https://gitlab.com/api/v4/groups/gitlab-org/milestones" -
=> "16.6"
[2] pry(main)> ReleaseTools::ProductMilestone.current.title
2023-09-28 13:02:50.895044 I ReleaseTools::ReleaseManagers::Schedule -- dynamic_release_date feature flag enabled. Using gitlab-releases gem as source
=> "16.5"

This MR updates the line in question to use .current.title to fetch the correct version.

Content

  • Security tracking issue uses correct versions

Author Check-list

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

Merge request reports

Loading