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

Fixes #309 #310

Merged
merged 1 commit into from Apr 12, 2024
Merged

Fixes #309 #310

merged 1 commit into from Apr 12, 2024

Conversation

druskus20
Copy link
Contributor

@druskus20 druskus20 commented Apr 10, 2024

Summary of changes

Breaking Changes

NO

Since I added a new argument (FORCE_WITHOUT_CHANGES_PRE), there shouldn't be any.
Alternatively, we can use FORCE_WITHOUT_CHANGES for prereleases as well, which would imply a breaking change.

How changes have been tested

I've tried the fork on a private repo. It works as expected. The changes are also minimal so they should be fine.

image

List any unknowns

@sbe-arg
Copy link
Collaborator

sbe-arg commented Apr 10, 2024

I like it but the releases are broken and we don't know why and I don't have time to debug. see failed releases https://github.com/anothrNick/github-tag-action/actions/workflows/main.yml

@druskus20
Copy link
Contributor Author

druskus20 commented Apr 10, 2024

@sbe-arg
I just ran the CI myself on my fork and it worked. I needed to push to master for "Version Bump" to activate, due to the nature of the CI job. I later force pushed, removing my tests from the history of this PR, but they still show up on https://github.com/anothrNick/github-tag-action/actions. My apologies.

In any case: the Bump CI job does work on my own repo, so changes to the yaml manifests should not be needed. It might be worth checking if "read and write permissions" are enabled?
image

PD: For my specific usecase a release is not needed, I will pin the commit hash regardless.

@sbe-arg
Copy link
Collaborator

sbe-arg commented Apr 10, 2024

Any of those repo config changes are only allowed by @anothrNick wich has been tagged in this issue/problem before.

Also is unclear why we suddenly started having this problem.

Its hard to "test" this myself is something on hands of @anothrNick to fix atm 🤷‍♂️

@anothrNick
Copy link
Owner

Settings all look right on this repo, I've also confirmed that the latest commit on master, as well as the other configuration options within the workflow, work fine in another repo...

I'll keep reading around a bit today, really not sure whats going on.

@anothrNick
Copy link
Owner

Made a change to our workflow using pull_request_target - https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target

That would explain why it is working in contributors' repos but not when its PR'd here.

I also wonder if this just started popping up due to timing with:

  • Optionally pushing tag with git vs. API
  • The permission changes for workflows

Either way, I'm going to merge this PR and see if it works.

@anothrNick anothrNick merged commit bec1ecd into anothrNick:master Apr 12, 2024
@anothrNick anothrNick mentioned this pull request Apr 12, 2024
@anothrNick
Copy link
Owner

@druskus20 can you resubmit this PR? I didn't update the event_name check in the job

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

Successfully merging this pull request may close these issues.

None yet

3 participants