Closed sigand closed 2 months ago
Currently, Harness requires a tag for checking out the correct version of the chart, so not tagging will be a breaking change. I think this will make very much sense if we switch to GH for CD 👍🏻
Then we should probably create a reusable workflow that can delete all these tags once a pull-request has been closed
Currently, Harness requires a tag for checking out the correct version of the chart, so not tagging will be a breaking change. I think this will make very much sense if we switch to GH for CD 👍🏻
Nope, Harness requires a tag or a commit ID so not tagging will still work as long as we update the reference in Harness to look for commit ID instead of complete tag 🤓
That works well for docker tags with a SHA but sadly not everyone uses the proposed convention. :/
Currently this would break for everyone but your teams @Chr1stian (and replacing all those service specs to use split and then forcing the tagging convention is probably not likely :/ ).
In what scenario is the amount of tags bothersome @sigand?
Come to think of it, you are of course proposing an opt-option. So if it's enabled all vets are off anyways.
Sorry for the roundabout way if getting there, but I think it's worth the addition! 😅 I'll have a stab at it tomorrow and assign you both to the PR. Thanks for your time and explanations.
Having experienced previously that repos become slow to push/pull and eventually stop working when the amount of tags become too great. I don't know what GitHub's limit is, but we wished to be proactive about it.
@sigand @Chr1stian https://github.com/entur/gha-docker/releases/tag/v1.3.5
uses: entur/gha-docker/.github/workflows/push.yml@v1
with:
# ...
git_tag: false
Git tags on feature branches build up and create clutter. Consider adding av option to
docker-push
to disable git tagging