-
-
Notifications
You must be signed in to change notification settings - Fork 75
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: support non-tag push event trigger #77
Conversation
dcf4d0c
to
04fb57a
Compare
friendly ping? @crazy-max |
I would maybe do the inverse: a config wdyt? |
@haya14busa I agree with @caarlos0, adding this argument would be confusing for the end user and would overlap the |
Thanks. I actually totally agreed with it. This change was not to break backward compatibility. If it's ok to break it, then we can just remove the code related with snapshot and let users use |
75805e7
to
4ea3102
Compare
It supports usecases that users manually tag new version with GitHub Actions workflow, and then release it. e.g. https://github.com/actions/create-release support `tag` input and can be used for non tag push event.
Users can explicitly use `args: release --snapshot` instead.
4ea3102
to
57b36a0
Compare
Updated. PTAL @crazy-max @caarlos0 |
@haya14busa I may have misspoken, but what I wanted to say is that the operation of this action is sufficient in its present state and does not, in my opinion, require the changes you wish to make via this PR. To summarize the So in your case if no tag is defined, the application will still be built as a SNAPSHOT. |
It's not sufficient, that's because I opened this PR. For example, this workflow add new tag when merging pull-request (non-tag push event) and then release it via actions/create-release later step. Because gorelease-action unnecessary add |
goreleaser would still not run in this case because it also checks if current commit == latest tag, if it is not it will exit 1. |
The workflow adds a new tag to the current commit and also push the tag to github, so it should work. |
Can you give us a link to a workflow that fails? |
OK: https://github.com/haya14busa/offset/runs/430337153?check_suite_focus=true For NG workflow, even though head commit has latest tag, the actual release didn't happen because it's snapshot mode.
|
@haya14busa Have you tried with your modifications? (replace |
OK link above uses my branch and it worked. |
For me this build "breaks" the purpose of GitHub Action and CI philosophy. Let me explain why. Everytime something is push/merge to master your action creates a new tag. It's not a best practice in a typical Gitflow. Tag must be created on purpose by maintainers. This is why the goreleaser-action does not detect the tag and forces If you still prefer to keep this workflow, we could improve the detection of a tag and no longer go through this environment variable. I'll think about this possibility, which I think is the most feasible. |
I agree with @crazy-max, creating a tag on every push to master is... well, weird... IMHO @haya14busa can also use their own fork, but I'm not sure I'm up adding this to the action itself. |
Only handle snapshot flag for release cmd (#94) Use core.info instead of console.log
The example workflow does NOT create a tag on every push to master, but the workflow will create a tag only when merging pull-request with specific tags (e.g. |
@haya14busa #95 should fix your issue. |
It supports usecases that users manually tag new version with GitHub
Actions workflow, and then release it.
e.g. https://github.com/actions/create-release support
tag
input andcan be used for non tag push event.