Skip to content
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

Closed
dgokcin opened this issue Jan 5, 2023 · 10 comments
Closed

Question: Shouldn'tVersion 1.58 should have been a major release? #236

dgokcin opened this issue Jan 5, 2023 · 10 comments

Comments

@dgokcin
Copy link

dgokcin commented Jan 5, 2023

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.

@jalavosus
Copy link

jalavosus commented Jan 5, 2023

I pinned the version of gihub-tag-action in my workflow files to 1.55.0, ex:

- 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.

@dgokcin
Copy link
Author

dgokcin commented Jan 5, 2023

@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.

@sbe-arg
Copy link
Collaborator

sbe-arg commented Jan 5, 2023

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.
I the meantime can you share the runner logs in debug mode of the broken workflows?

@sbe-arg
Copy link
Collaborator

sbe-arg commented Jan 5, 2023

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.

@dgokcin
Copy link
Author

dgokcin commented Jan 5, 2023

@sbe-arg I believe what I am having is caused because of this. #230

@sbe-arg
Copy link
Collaborator

sbe-arg commented Jan 5, 2023

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

@dgokcin
Copy link
Author

dgokcin commented Jan 5, 2023

@sbe-arg I am not using squash, I am using merge commits.

@sbe-arg
Copy link
Collaborator

sbe-arg commented Jan 5, 2023

#237 we are gonna switch to a different log strategy as proposed by @jonavos in #232 I tested this with rebase and squash and seems to work when using compare but definitely broken on full due the HEAD comparison

@sammcj
Copy link
Collaborator

sammcj commented Jan 5, 2023

See also #238

@sbe-arg
Copy link
Collaborator

sbe-arg commented Jan 6, 2023

Gonna close this one as we are tracking in #243

@sbe-arg sbe-arg closed this as completed Jan 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants