I appreciate the subject of this might seem obvious, but I’m hoping that by explaining what I’m doing, whether there’s a solution I’ve not thought of…
We your Github Actions starter defined like this:
on: [push] jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 run: | git config --global push.default simple git remote set-url origin "https://$GH_ACTOR:$GITHUB_TOKEN@github.com/$GITHUB_REPOSITORY.git" - name: Build Package run: | git fetch --prune --unshallow --tags && docker build .
Hence, for any branch which is pushed/updated, we fire off docker to do all of our building for us. This is because our environment is very specific. Once a build succeeds within docker, one or several artefacts are published to a cloud repository.
This works great.
However, here’s the problem I’m facing… for one specific branch (
branch-x) when a push occurs, the docker container goes through the same process of building and uploading, but will also automatically commit a piece of metadata and tag that commit, pushing the commit and tag to the repository on Github.
This works, however as soon as that happens, Github Actions realises something has occurred on
branch-x and then proceeds to build the commit it has just committed and tagged, only to commit more metadata and tag the repository on
branch-x. The result is now an endless loop.
So some questions around this:
- Should I be separating out in Github Actions the difference between
pull-requestbuild steps? Even if I did, this poses some further problems for me:
This would end using two builds in the case where
topic-branchhas been pushed to, and had a corresponding open pull-request. This is undesirable as this is a redundant step and ultimately eats in to the build minutes on Github.
It still wouldn’t necessarily solve the cyclical build problem I’ve just described.
- I did think of trying to solve this by checking the
HEAD~1commit (i.e., previous commit), and check if the two commits together were tagged with the metadata, but this feels clunky. Indeed, even though I could detect this condition, failing this step doesn’t invalidate other steps in the build.
What are my other options? How can I break the cyclic dependencies on
TIA. If I can clarify any points, do please let me know.