-
Notifications
You must be signed in to change notification settings - Fork 381
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
Question: Shouldn'tVersion 1.58 should have been a major release? #236
Comments
I pinned the version of - name: Bump Tag
uses: anothrNick/github-tag-action@1.55.0 1.55.0 Being the most recent version which my coworker found to be 100% working without issues. |
@jalavosus We used to use this action like that. Than all of a sudden github changed something in their api and this action stopped working. I believe it was #181 so I did not want to do what you did. |
Okay so DEFAULT_BRANCH is not working for you either are you using squash? See issue #232 Ill try to do some more deep testing on this today. Apologies. |
1.55 could have been major but is a cascading of events that come from a problem in 1.47 was hard to define it as v2. We are considering reverting from default full back to default last due squash vs non squash log capture differences. For now if you are using squash stick to using logs last. |
And what workflow do you use is squash? Or commit merge. The full log does not currently work when using squash merge with rebase for example as discussed in issue #232 hence the full_squash option and option to set as default the last instead of full introduced in 1.55 |
@sbe-arg I am not using squash, I am using merge commits. |
See also #238 |
Gonna close this one as we are tracking in #243 |
Hello
I have been using this action on pushes to my main branches and using the bumped version output in many places like tagging production docker images, publishing release notes etc. I was using the action with @v1 tag to get the latest non-breaking updates.
This morning, I had to update 40+ repositories and add the DEFAULT_BRANCH option to every single one of them because all of a sudden the most critical workflows in my repos which are the deployment workflows, this action started to fail. Thats why I believe the latest version should have been a breaking change.
How should I configure my workflows so that I do not have to live through this again?
Thanks.
The text was updated successfully, but these errors were encountered: