Test and roll out changelog generation using Omnibus
In &351 (closed) and &399 (closed) we are rolling out the ability to generate changelogs using the GitLab API.
As part of this roll out, we want to start testing the feature using Omnibus, and keep using it if deemed OK. The goal here is to gather feedback from those working on Omnibus before we enable this new setup permanently, and to allow gradual roll outs per project; instead of changing all at once.
Testing process
During the testing period, developers are asked to annotate their commits
(should they go in the changelog) with the Git trailer Changelog
. This trailer
can have the following values:
- added
- fixed
- changed
- deprecated
- removed
- security
- performance
- other
This means that when a commit should go in the changelog, it will look something like this:
The subject of the commit message.
More details about the change here, if necessary.
Changelog: fixed
This would be done in addition to the process currently used.
Further, changelogs would be generated on a separate branch using a manually triggered API call (by Delivery team members). Keeping the old process intact for the time being ensures our testing doesn't affect releases. We generate the new changelogs on a separate (temporary) branch for the same reason.
When reviewing merge requests, reviewers should ensure the appropriate Git trailer is used whenever a commit is supposed to go in a changelog. This is similar to reviewing changelog files in the main GitLab project. Should Danger or similar tools be used to suggest adding changelog YAML files, we will extend these rules to also suggest using the new process.
@yorickpeterse will take care of setting up the necessary configuration files, and is the contact person for any feedback.
Testing period
This is yet to be decided.
After testing
Should the new process be deemed a success, we want it to replace the old process. This will require changes to Release Tools, as well as changes to the workflow for Omnibus (e.g. CI rules may need to be adjusted accordingly).
When deemed OK to enable permanently, we would have to apply a cut-over date. After this date, changelog YAML files would no longer be allowed in the repository, and all developers should use the new process. This will likely be paired with converting existing YAML files (should they still exist) into separate commits.
The exact steps here are yet to be determined, as they will depend on the feedback received from those working on Omnibus.