Repository navigation
Unexpected failure in GitHub Action run #581
Description
In a recent pull request (#579), one of our GitHub Action (GHA) workflow runs failed.
Overview of failed GHAs:
Now when looking at the details of that workflow run, I noticed something interesting:
- when you click on "workflow file", it takes you to the
book.ymlfile from this branch/PR (which comes from a fork) - however the file that really got executed is actually the one on the
mainbranch of the upstream. I am so sure about this as the main branch contains the config for a matrix build for this GHA, while the branch from the PR does not have that matrix build yet)
So at the very least I am starting to wonder how GHAs really work. Seems like I might have some misunderstandings here.
My questions are:
- which GHAs are executed? the ones on the
mainbranch, or the ones on the PR branch, or both? mainand PR contain different versions of the same GHA. what happens in that case?
And lastly:
Why does this GHA run fail at all?
It seems like it is looking for a git ref hive-mind-pattern-1 and cannot find it? Possibly because that ref only exists on the fork but not on the upstream?
Do we have to configure the actions/checkout differently, so that it can find that git ref?
Right now we use ref: ${{ github.head_ref }}, which is defined as:
The head_ref or source branch of the pull request in a workflow run. This property is only available when the event that triggers a workflow run is either pull_request or pull_request_target.
I am suspecting that we are checking out the upstream repo InnerSourceCommons/InnerSourcePatterns but then trying to point to a ref that does not exist on that upsream.
Just not sure how one would configure this correctly?
Activity
spier commentedon Aug 29, 2023
@zkoppert and @yuhattor you are my best resources on GitHub Actions :) Maybe you have a hunch what might be going on here? Would be great to get your help.
zkoppert commentedon Sep 5, 2023
👋🏻 Yeah this is a confusing topic 😓
For the question, "which GHAs are executed? the ones on the main branch, or the ones on the PR branch, or both?"
Given your other points, I think the way forward is to switch to running GitHub actions in the context of the upstream repo when a PR from a fork comes in. This can be done by use the actions trigger
pull_request_taarget. The docs for that are here: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target. The important risk to note here is:Does that make sense? Happy to help with a pull request to get this changed if you would like.
spier commentedon Oct 31, 2023
I forgot about this issue :)
Saw a different issue with the same GitHub Action today, which is sort of a collateral of this:
toc.mdfileThis is confusing. So yes, I think it is time to fix this issue :)
@zkoppert sorry for all the notifications today. If you have time to help me configure the
pull_request_targetevent on the book.yml that would be awesome!zkoppert commentedon Oct 31, 2023
@spier No problem. I've opened up #608 to get us going and laid out what I believe are the next steps.
Switch to pull_request_target strategy (#608)
zkoppert commentedon Oct 31, 2023
I think the other piece of this is specifying
ref: ${{ github.head_ref }}during checkout. The net experiment would be to remove that and see if it gets past the checkout phase (it should) but then it will also need to be able to get past the commit stage. There we might need to specify the branch name.Reconfigure branch specifications with pull_request target (#609)
zkoppert commentedon Oct 31, 2023
I think that may have actually worked! Looks like checks are passing here: https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/579/checks
spier commentedon Oct 31, 2023
Well we (and with that I mean me) are certainly learning something about git and GitHub Actions here :)
You are right, the action ran successfully on the PR/branch that I am testing on.
Where previously the action failed on this:
/usr/bin/git -c protocol.version=2 fetch --no-tags --prune --progress --no-recurse-submodules --depth=1 origin +refs/heads/hive-mind-pattern-1*:refs/remotes/origin/hive-mind-pattern-1* +refs/tags/hive-mind-pattern-1*:refs/tags/hive-mind-pattern-1*It is now passing:
/usr/bin/git -c protocol.version=2 fetch --no-tags --prune --progress --no-recurse-submodules --depth=1 origin +f570a5af72f4f1c2c9914283cebfb821de3d9993:refs/remotes/origin/mainf570a5a is the ref of the latest commit on `main. So I guess this is the expected behavior?
Now that leads us to another issue though:
The
book.ymlaction is generating a new table of contents for the book, based on the files on the branch from the PR. i.e. if checkout is now getting the content frommainrather than from the PR branch, I guess this won't work?Will keep looking ... but rather tomorrow. Thanks for all your help so far already Zack!
spier commentedon Oct 31, 2023
I did run a test to confirm that the current configuration of the GHA really checks out
main, and not the PR branch.Result: confirmed :)
Also from the pull_request_target docs:
So I guess that leaves us in a pickle, or whatever the English idiom is :)
zkoppert commentedon Nov 1, 2023
Maybe there is a way to break up this action into 2. The first part makes sure that everything builds on the branch so that you know the PR is good to merge, and then a second action detects that a merge to
mainhas occurred and it goes and builds and checks in the files needed on the main branch.spier commentedon Nov 2, 2023
Yeah, possibly.
There are two separate issues it seems:
main) outside of a PRSwitch to pull_request_target strategy (InnerSourceCommons#608)
Reconfigure branch specifications with pull_request target (InnerSour…