🌱 Auto-create git tags for the tools/setup-envtest submodule#3476
Conversation
|
Hi @porridge. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Tip We noticed you've done this a few times! Consider joining the org to skip this step and gain Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
| shell: bash | ||
| env: | ||
| GH_TOKEN: ${{ github.token }} | ||
| run: | |
There was a problem hiding this comment.
Please move the contents of this into a file under ./hack so its easier to run for testing
| on: | ||
| push: | ||
| tags: | ||
| - 'v*' # Code below does further filtering. |
There was a problem hiding this comment.
Any reason to not filter here already?
There was a problem hiding this comment.
I think only basic globbing is available here, not terribly expressive...
There was a problem hiding this comment.
It appears to be an odd subset of regex that doesn't support match groups, but should be possible to validate for major/minor/patch here? https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax#filter-pattern-cheat-sheet
There was a problem hiding this comment.
I wasn't able to come up with an expression that accepts v1.2.3-rc1 but rejects v.1.2.3invalid but perhaps it's not a big issue. Let me know if you'd like me to reinstate the regex match in bash.
| exit 0 | ||
| fi | ||
|
|
||
| echo "skipped=false" >> $GITHUB_OUTPUT |
| NEW_TAG="${PREFIX}${ORIGINAL_TAG}" | ||
|
|
||
| echo "Original tag '$ORIGINAL_TAG' matches expression '$REGEX'." | ||
| echo "Creating new tag: '$NEW_TAG' at SHA: ${{ github.sha }}" |
There was a problem hiding this comment.
Can we first check if the tag already exists?
There was a problem hiding this comment.
Sure. If it does, should we exit silently right away, or further check whether it's the same commit and vary the exit code based on that?
I'm leaning towards the former, in order to respect any pre-existing tags created out of band.
|
Sorry but I could not find the time for this recently, I will do my best to address the feedback next week. |
|
Feedback addressed, PTAL @alvaroaleman Tested here: |
|
LGTM label has been added. DetailsGit tree hash: e9eb1104e448d0373b95c91423a3570e4c0b2d2b |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: alvaroaleman, porridge The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
See slack discussion.
Using the GitHub CLI (gh api) built into GitHub's runners to create the tag, rather than using standard
git tagandgit pushcommands because it:Tested a copy of this workflow in this run in a clone repo.