feat(release-it): tweak template to be common pipeline amenable
Compare changes
Files
3+ 1
− 0
@@ -20,6 +20,7 @@ include:
GitLab has been upgraded. See what's new in the Changelog.
As noted in #94 (closed), release-it was not yet present in the common pipeline which was a blocker of the vision of "OpenAPI client generation releases are zero-configuration". #94 (closed) also noted that not much had to be done to add release-it to the common pipeline.
Gate the release-it jobs behind the presence of a .release-it.json
file in the root of the repository. This should have zero effect on
current users since that file needs to be present in order to use
release-it. Guard against inadvertent triggering by allowing jobs to be
explicitly disabled via a RELEASE_IT_DISABLED variable.
To guard against future namespace clashes, namespace all the release-it
jobs. In #94 (closed), it was originally suggested that the
USE_MERGE_REQUEST_RELEASE_FLOW variable could be namespaces and given
the backup value of USE_MERGE_REQUEST_RELEASE_FLOW to avoid breaking
clients but, upon reflection, having two variables controlling this
behaviour adds more confusion than it prevents. As such, leave the
variable un-namespaced as an interesting historical remnant.
Closes #94 (closed)
https://gitlab.developers.cam.ac.uk/uis/devops/experiments/rjw57/misc/-/pipelines/654270 is an example of a pipeline for a branch which a) does not explicitly include the release-it template but b) does have a .release-it.json file in the root. The release-it:update-release-merge-request job was correctly created.
https://gitlab.developers.cam.ac.uk/uis/devops/experiments/rjw57/misc/-/pipelines/654271 is an example of a pipeline for the same branch but where .release-it.json is not present. The release-it:update-release-merge-request job was correctly skipped.
The only significant change from this MR is to add release-it to the common pipeline and to tweak the rules so I think this exercises the required behaviours.