Split compute-version and update-version-file into separate jobs #35
Conversation
Fix action name since github-tag-action runs in DRYRUN and does not actually create a tag. Remove unecessasry if statement. Rename docker image to something more generic to be able to reuse this workflow elsewhere.
|
For reference, here is the job that successfully created a new release using this pipeline. Compared to this PR, there were some additional debug prints (2070e4b) and I did at a slight tidy up to this PR (7d33c7a) but those really shouldn't make a difference. Before merging, I will remove the tag and release created by the test workflow. I will also use the #major label as discussed yesterday. |
| docker run --rm -v /tmp/artifacts:/tmp/artifacts util_caching_release cp -r /release /tmp/artifacts/ | ||
| docker run --rm -v /tmp/artifacts:/tmp/artifacts release_builder cp -r /release /tmp/artifacts/ |
There was a problem hiding this comment.
Not directly related, but I guess you can simply use docker cp
There was a problem hiding this comment.
I know about this one but that only works for running containers. So we'd have to start the container, then run docker cp. My solution is a single command that's why I opted for that one.
There was a problem hiding this comment.
Ah, didn't know about that – again sth. learned 😁
This fixes an issue with the release pipeline.
The version bump action does not seem to work with a repository cloned via ssh. This PR therefore splits this into two jobs: One job to just compute the new version using an https clone and a second job that updated the version file and creates a tag. This one then uses the deploy key to bypass the branch protections for the automated changes.
This fixes the issue (tested on a protected devel branch) and also adds a separation of concerns for the different parts of the pipeline.