Container Scanning generates incorrect changelog entries for branches
Summary
The release process for the v4.x
branch in container scanning is currently manual:
> 1. Create a [new tag](https://gitlab.com/gitlab-org/security-products/analyzers/container-scanning/-/tags) matching the
> version in [`lib/gcs/version.rb`](lib/gcs/version.rb)
> 1. A [tag pipeline](https://gitlab.com/gitlab-org/security-products/analyzers/container-scanning/-/pipelines?scope=tags&page=1)
> will perform the release
When the tag pipeline executes, it runs a job to update the changelog, however, this job generates an incorrect changelog with too many entries, because it compares the changes against the default branch instead of the v4.x
branch.
V5 also breaks if changelog
trailer is not capitalized, as the part of this issue we should make it case in-sensitive in rake task.
Steps to reproduce
Create and push a new tag for changes in the v4.x
branch for container scanning and let it run the update_changelog
job. Notice that it generates an incorrect changelog.
Example Project
https://gitlab.com/gitlab-org/security-products/analyzers/container-scanning/-/tree/v4.x
What is the current bug behavior?
Incorrect changelog entries are added.
What is the expected correct behavior?
Only the changes related to the branch being targeted should be added.
Workaround
Let the update_changelog
job job run and create the incorrect changelog entry, then manually update the changelog in a follow-up MR, like this one: Manually fix Changelog entry for 4.6.22 (gitlab-org/security-products/analyzers/container-scanning!2857 - merged).
Possible fixes
The update_changelog job calls the changelog rake task which in turn calls GitlabClient#generate_changelog which finally makes a request to the GitLab Reposiroties API using POST /projects/:id/repository/changelog, however, it does not set to
and from
values, so the changelog ends up being filled with changes for all previous versions.
We need to restrict the number of changes to the major version of the current tag, by setting the to
and from
values in GitlabClient#generate_changelog to the SHAs corresponding to the current tag and second most recent tag, respectively.
Implementation Plan
Update GitlabClient#generate_changelog:
-
Fetch the list of tags matching the same major value for the passed
version
using the Tags API.Use
order_by=version
andsearch=^<tag-major-version>
to filter the results.For example, if
version
is4.6.24
, then we make the following API call:curl 'https://gitlab.com/api/v4/projects/24673064/repository/tags?order_by=version&search=^4' | jq '[.[] | {name, target}]'
This will return the tags and commit SHAs sorted by semantic tag version:
[ { "name": "4.6.24", "target": "39bc02082ef03aa06c34b65f2742dbed6dd46d39" }, { "name": "4.6.23", "target": "48ccb32d1a66aae1680df58bb9b0e5ee8521c20b" }, "...", ]
-
Pass
to
andfrom
values to thepost
call ingenerate_changelog
, setting them to the most recent and second most recent tag SHA values, respectively (ie elements[0]
and[1]
of the array returns in step1.
above):def generate_changelog(version) message = "[skip ci] Add changelog for version #{version}" res = post(changelog_uri, form_data: { to: '39bc02082ef03aa06c34b65f2742dbed6dd46d39', from: '48ccb32d1a66aae1680df58bb9b0e5ee8521c20b', version: version, message: message }) generic_result(res) end
-
Test this using the Generate changelog data API call.