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
github.ref_name is not set to the branch/tag that HEAD points to. #2056
Comments
GROwen
added a commit
to GROwen/act
that referenced
this issue
Oct 23, 2023
GROwen
added a commit
to GROwen/act
that referenced
this issue
Oct 23, 2023
GROwen
added a commit
to GROwen/act
that referenced
this issue
Oct 23, 2023
GROwen
added a commit
to GROwen/act
that referenced
this issue
Oct 23, 2023
Issue is stale and will be closed in 14 days unless there is new activity |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Bug report info
Command used with act
act schedule -W .github/workflows/context-check.yml --defaultbranch "5.x" --container-architecture linux/amd64 --rm -P ubuntu-latest=catthehacker/ubuntu:act-latest -v
Describe issue
If a Git reference points to multiple branches the last pointer in the series is selected as the value for github.ref_name
i.e.
Expected behaviour (personally)
The values for "ref" and "ref_name" in the GitHub context are set to the branch/tag pointer that
HEAD
is pointing to i.e.Actual behaviour
See the output posted in the "Relevant log output" section.
Link to GitHub repository
No response
Workflow content
Relevant log output
Additional information
I was trying to solve this and provide a PR but am uncertain of the broader implications of the change that would fix the issue for my scenario.
pkg/common/git/git.go:FindGetRef is responsible for setting the values. I'm assuming the requirement for this and not just the value set for head in pkg/common/git/git.go:FindGitRevision is to lookup any tags that would be related to the revision. Otherwise I'd expect the pointer for HEAD could be used?
It'd be helpful to have this assumption verified by someone more experienced with the project before I dive into a solution.
Expanding the existing tests to check for this scenario seems trivial although I don't think that explicitly checks for what would be output to github.ref_name. Could I have missed that somewhere?
The text was updated successfully, but these errors were encountered: