Repository navigation
Panic using gh workflow run in GitHub Actions #10519
Description
Activity
- Reacted by Tyler McGoffin
Thanks @williammartin! For the token permissions thing, it would be neat to know if my suspicion is correct but I'm not going to request someone go digging just to satisfy my curiosity :P
I'll still open to sending a PR but again the contributing guide suggests I hold off for now, and aside from any tests it's likely just a 1-line change anyway so I'm indifferent if a maintainer just goes ahead and fixes it.
Have a great weekend 👋
Hey @catsby,
Tried to reproduce this.
Working fine for me.
Got 404 and 403 but no panic.Could you please see what I'm missing?
Here are the workflows that I used:
.github/workflows/ci-wd-test-runner.ymlname: wd_test_runner on: workflow_dispatch permissions: actions: write jobs: ci: runs-on: ubuntu-latest steps: - name: Run env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} run: | gh --version gh workflow run ci-wd-test.yml --repo iamazeem/test
.github/workflows/ci-wd-test.ymlname: wd_test on: workflow_dispatch jobs: ci: runs-on: ubuntu-latest steps: - name: Test run: echo
Workflow runs:
- https://github.com/iamazeem/test/actions/runs/13593475109/job/38004926608 (runner)
- https://github.com/iamazeem/test/actions/runs/13593477522/job/38004932939
gh version$ gh version 2.67.0 (2025-02-11) https://github.com/cli/cli/releases/tag/v2.67.0
I agree that an error should be returned from the non-404 branch.
Just want to understand the root cause. 🤔Hey @iamazeem - thanks for putting a example together! I'm not able to try it out at this time but hopefully later today I can try it. It looks just like my description, the only difference notice is that in my example I don't use the
--repoflag so maybe that's a clue.Got 404 and 403 but no panic
That's curious... I wonder how this
getWorkflowByID()method is returning a403error, but you are not getting a nil pointer dereference 🤔 unless I'm just misunderstanding some workflow or codepath somewhere.Reacted by Azeem@catsby: Sure, thank you! 👍
the only difference notice is that in my example I don't use the
--repoflag so maybe that's a clueI'm not using a checkout step that's why
--repoflag is there.
Doesn't seem related though.
I'll verify it later.
I wonder how this
getWorkflowByID()method is returning a 403 error403 here is not from the same path.
Earlier, you mentioned that:
maybe the
getWorkflowByID()call is returning a 403 or something due to the token being used?So, I deliberately missed
permissionsto generate a 403 error for the defaultGITHUB_TOKEN.
It did generate the 403 error but no panic.
Update
- Tried using an invalid (non-existent) workflow filename with
gh workflow runcommand from the runner workflow. - Updated both workflows for the
tag_nameinput as described in your example.
Both worked fine as expected i.e. failure and success respectively.
- Tried using an invalid (non-existent) workflow filename with
@iamazeem I used your examples to make my own reproduction and found similar results, but with a twist..
403 here is not from the same path.
This comment confused me because I couldn't see how you were hitting this method in shared.go where the panic was coming from, you were getting a 403 and no error...
Sure enough though I got a
403when I reproduced this on a public test repo that I made. Therein lies the issue I suppose, in something I overlooked in my initial report: I'm encountering this panic on an private/internal repo, not a public one. As soon as I made my test repo internal I got the panic again. My apologies to all for not including that detail, it didn't even occur to me that it would make a difference.My testing runs are at https://github.com/catsby/gh_panic_test/actions , you can ignore runs 1-2 as I didn't have things configured right.
Run 3 shows the 403, with some other error message I didn't bother to investigate because the
403was what I was not expecting but also looking for.Run 4 was done after I made the repo private/internal. There you can see the panic!
Run 5 was done after I made the repo public again, and is the same results as Run 3.
Reacted by AzeemHey y'all, we appreciate the investigation!
While you've been digging into this, I've been writing a fix. Well, I've mostly been writing tests to cover this part of the code, as the fix was easy 😅
I've got a PR up for this.
@catsby, we aren't planning on doing a patch release for this as the issue is fairly isolated, but we will be releasing on Monday or Tuesday next week and I'll make sure this fix gets in. I hope that's not too disruptive for you.
Reacted by AzeemShort term workaround until the latest GitHub Actions hosted runner image is updated
As of March 7th, the GitHub Actions runner images, which are rebuilt weekly, have
v2.67.0installed. If you need a temporary workaround, you can install the latest version within a workflow:- name: Upgrade to latest gh release run: | (type -p wget >/dev/null || (sudo apt update && sudo apt-get install wget -y)) \ && sudo mkdir -p -m 755 /etc/apt/keyrings \ && out=$(mktemp) && wget -nv -O$out https://cli.github.com/packages/githubcli-archive-keyring.gpg \ && cat $out | sudo tee /etc/apt/keyrings/githubcli-archive-keyring.gpg > /dev/null \ && sudo chmod go+r /etc/apt/keyrings/githubcli-archive-keyring.gpg \ && echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/githubcli-archive-keyring.gpg] https://cli.github.com/packages stable main" | sudo tee /etc/apt/sources.list.d/github-cli.list > /dev/null \ && sudo apt update \ && sudo apt install gh -y
In the example above, this step will setup the GitHub CLI Apt package repo to install the latest for a
ubuntu-latestworkflow.actions/runner-imagesuses a different process for downloading and installing GitHub CLI that doesn't rely upon Apt repository, which is why you cannot simplesudo apt upgrade gh.Note
New GitHub Actions runner images should be built early next week.
Reacted by Kynan Ware- marked Invalid memory address or nil pointer dereference #10638 as a duplicate of this issue
on Mar 20, 2025
Describe the bug
I was trying to use
gh workflow runat the end of a step in a GitHub action to trigger another workflow run. After reading some documentation though it seems I'm doing things wrong and should be using reusable workflows instead, so I'll figure that out elsewhere...Anyway, when trying to do this in a GitHub Action, the
gh workflow runcall always ended in a panic. Here's the step in the job:(the
$TAGis correctly set in a previous job step)Note the use of
secrets.GITHUB_TOKEN, which might be part of the problem due to how that token is limited in GHA to prevent recursive actions, etc... but maybe not...Here's the panic:
I believe the panic comes from the cli/cli/pkg/cmd/workflow/shared/shared.go:139 in the stack there.
cli/pkg/cmd/workflow/shared/shared.go
Lines 131 to 140 in f8d9aac
On line 135 we check for
errors.As() && httpErr.StatusCode == 404in order to return anerr, so I'm speculating that thegetWorkflowByID()call on 132 is returning anilworkflow with some other error code that's not a http error or not a404, and as a result we get thenil pointer dereferenceon 139.I was going to add a PR to return a generic error message between line 137 and 138, but the contributing guide asks (suggests?) to not open PRs unless there's a
help-wantedon a bug or something, plus in the short time I looked I wasn't sure how to write a test for this so I just opt to give all this info here.Again just speculation but maybe something to do with the token I'm using, because using
gh workflow runon my machine while authenticated works fine:So maybe the
getWorkflowByID()call is returning a403or something due to the token being used?Affected version
This is happening inside GitHub Actions, so I'm not totaly sure what
gh version, but here's the runner version:Steps to reproduce the behavior
gh workflow runExpected vs actual behavior
Return an error instead of panic, to help educate me on what I'm doing wrong.
I'm happy to PR a fix here as I suspect even if my speculations on tokens are wrong, we probably still want to return
nil, errbetween 137 and 138. Tips on how/where to test for that would be cool too, if we want to have a regression test there.