$COMMITS_URL issues

[fharper]

In two out of six repositories where we are using this action, I'm having an error on all pull requests:

jq: error (at <stdin>:5): Cannot index string with string "commit"

It seems like in some cases, github.event.pull_request will be empty (see the discussion at https://github.com/orgs/community/discussions/25220). There are some workarounds in the thread.

Unfortunately, it happened only in some repositories I cannot share here as they contain private code, so I cannot show you a case where this issue is happening. I would gladly help debug, provide information about the workflow, and test any fix you may have.

I may try to fix the action myself once I have the time, but we are in the middle of a big release, so time is scarce for now.

[florisvdg]

Would help if you could share some YAML snippets of the workflow you're calling this action from. For example: what event does it run on, pull_request, pull_request_target, something else?

And for those repos where you're seeing the error, does it always happen there or only in certain PRs or certain circumstances?

[florisvdg]

Also, I'm seeing now that not every curl command in the action is configured to fail fast, so it might be that GitHub is returning a 4XX or 5XX status code for some reason. I've put up a branch to fail sooner print the error message, which you can use in your workflow YAML like this:

uses: 1Password/check-signed-commits-action@519a1dbdded076a15e1d628896a3b6beb3a9ed0b

[fharper]

I totally missed your comment, sorry.

Here is how I use it https://github.com/kubefirst/docs/blob/main/.github/workflows/check-signed.yml . It's not the one that is failing, but it's the same exact code in the same exact kind of repository (I cannot share the other one).

I'll test the branch, and report back, thanks

[fharper]

So your branch branch is giving me more information. The curl command is returning a 403 on the https://api.github.com/repos/MY-ORG/MY-REPO/pulls/14/commits call. The repository is private, but I thought the default token would do the job, no?

[florisvdg]

Does it work if you change on: [pull_request, pull_request_target] to on: pull_request_target?

[fharper]

I got this error even with on: pull_request_target only

[fharper]

So it seems like the problem is only happening with private repositories. We made public the ones where I had this issue, and now it's back to working properly.