Closed m-roberts closed 1 year ago
Cool, works great!
Before merging, I want to set up some workflow that regularly checks the latest Docker tags and updates the tag in the config here:
Using latest
here makes any rev
that users use for this pre-commit hook misleading. If needed, we change it to 0.8.0
(optionally with alpine) and merge it.
Then there is still the problem though what tag to release this mirror repo with. In fact, given the tags that have already been released for this repo, I wonder if it makes sense to host this hook as a separate repo...
Using latest here makes any rev that users use for this pre-commit hook misleading. If needed, we change it to 0.8.0 (optionally with alpine) and merge it.
I've updated the version tag to match the original workflow.
Then there is still the problem though what tag to release this mirror repo with. In fact, given the tags that have already been released for this repo, I wonder if it makes sense to host this hook as a separate repo...
If it were me, given that there is no risk of functional change (particularly regression) for those already using this tag, I would simply force push the v0.8.0 to point to the latest commit. This is quite a common practice in other GitHub Actions repos.
Before merging, I want to set up some workflow that regularly checks the latest Docker tags and updates the tag in the config here
I would say that this is is something to merge in after this PR, as it is an administrative convenience rather than something related to this PR. I have created #3 to capture my thinking on what would be an ideal solution for this.
Closes #1