Action can not report test results due to 'Bad Credentials'

[buehlerjochen]

Hi,

we would like to use your action in our GH Enterprise instance. Unfortunately, we get errors for the action:

##[error]Failed to create checks using the provided token. (HttpError: Bad credentials)
##[warning]This usually indicates insufficient permissions. More details: #32

I am aware of this discussion in the archived repo: mikepenz/action-junit-report-legacy#32
Do we have the same issue here with a read-only token because we are building a PR? Using pull_request_target is not very attractive to us...

How is the action then intended to be used? I have to admit, that I am a bit confused. 🤔
How do I have to set up the repo and permission that it would work?

Thank you for your help and the action. :)

[mikepenz]

@buehlerjochen which token do you use with the action?

Sadly I have no access to a GH Enterprise instance (assuming it's self hosted?), so I can't tell for sure if those require a different API / different endpoint for publishing results. All the below information is in regards to github.com.

---

The issue with the original legacy ticket was the following setup:

• main repo
• fork repo
• PR from fork repo opened against main repo.

GitHub actions won't provide the tokens to the PR from the fork repo (default config) to prevent leaks. E.g. to prevent evil parties who may did a fork to steal the token by modifying the github actions script.

There are some settings which would for example tokens to be provided to PRs from forks:

---

As an alternative creating a PAT (personal access token) could circumstance this too, giving the action the rights to comment on the PR/repo.

---

Please note that those limitations ore requirements are not specific to this actions but are generally true as its high risk for PRs from forks to potentially inject code into your run actions to steal secrets.

[buehlerjochen]

Thank you for the quick and detailed response.
From the legacy ticket I learned about the limitations regarding PR from forks, and I think that actually makes sense as a security measure. However, my scenario is a PR from the same repo, not a fork.

I have been trying to use secrets.GITHUB_TOKEN and github.token. Both seem to be available but not sufficient to complete the action's operation.

    - name: Publish Test Report
      if: ${{ github.event_name == 'pull_request' }}
      uses: mikepenz/action-junit-report@v1
      with:
        report_paths: '**/build/test-results/test/TEST-*.xml'
        github_token: ${{ github.token }}
#        github_token: ${{ secrets.GITHUB_TOKEN }}

I was able to run a successful test with the labeler action, which added a label to the PR and another test where the Github API is used to create a new ticket from a workflow. Both worked with the provided token so the write access seems to be OK:

    - uses: actions/labeler@v2
      with:
        repo-token: ${{ secrets.GITHUB_TOKEN }}

To be honest I also tested other actions to "publish" test results, but I liked your plugin's features best, especially reporting the results as PR check.

Do you have any other ideas what could be causing the issue? Any "special" APIs you are calling or maybe an connection that does not use the dynamic repo URL but maybe is hardcoded to github.com?
I am really grasping for straws here because there is no way to get more information on the issue and I really would like to get it to work. Thanks again for your help!

[mikepenz]

@buehlerjochen thank you so much for the further details on your setup. I'll look into the labeler actions source and try to see if I can identify a different usage of the API.

It's much more complicated to debug such things without having the direct possibility to test in a similar infrastructure.

I'll keep you updated on the findings

[mikepenz]

@buehlerjochen would you please be so kind to retest with the v2.2.0 release

[buehlerjochen]

@mikepenz Thank you for the fast update. I tested it on our server and it looks like it got a few steps further than before. At least it is showing the icons in the log now and before there was only the error message.

Looks like the API is in Preview on our version 2.22.x of GH Enterprise. It is stable in 3.0, but we haven't deployed that yet.
The documentation shows how to use the API in preview mode: https://docs.github.com/en/enterprise-server@2.22/rest/reference/checks#create-a-check-run-preview-notices
It would be awesome if you could add that. If you hesitate to use a preview API, you could protect the behavior with a parameter on the action ore something similar. :)

[mikepenz]

@buehlerjochen not sure if it is the best idea to push that upstream, but I think I have a good solution to offer for you.

I have pushed the preview label to this branch: https://github.com/mikepenz/action-junit-report/tree/feature/37_2

So you should be able if the way the flag is provided works by doing:

mikepenz/action-junit-report@74524a9efd8091798ea6a3464de483cc42ad8979

Please let me know if that works for you

[buehlerjochen]

I ran a test with that version and I am happy to report that it works! :)

I intentionally added a failing test to see the effect in the PR.

For some reason the builds with this version of the action are much slower than the regular builds on the repository, but not sure if that has something to do with the version.

Considering a released version with the latest fix, what would be your plan to make it available? I just learned that GH Enterprise 3.0 is not released yet (RC stage), so the 2.22 version with the Preview Checks API is the best there is right now. I really would love to have a regular release, but that decision is up to you. :)

[mikepenz]

Thank you so much for trying it. that's awesome news!

I would assume they are slower because it will do the API requests now successfully to apply the check, vs before them getting instantly declined.

---

You may want to consider the following. Especially as it sounds you plan to use this in an enterprise environment, it is a great common pattern to include github actions with full length sha hashes so you can 100% ensure the state of the action you execute is exactly what you verified to be without any malicious intend.

While it's very unlikely that you will run into this issue, but if you use the label like @v2 the maintainer of a library will be able to modify the actual result at any time (usually done in good intention. If I release a new v2.3.0 I will also move the v2 tag to reference v2.3.0 so that v2 always references to the latest v2 release, same as I would introduce a v3 with the first v3.0.0 release)

More details on this here: https://docs.github.com/en/actions/learn-github-actions/security-hardening-for-github-actions#using-third-party-actions

---

Independent of this I will probably think a bit more on including the preview flag in, not sure if this could un-intentionally enable other features which other parties may not like to have.

[buehlerjochen]

Thank you very much for your great help and the quick fix! :)

[mikepenz]

Thank YOU so much for taking the time to work on getting this resolved. ;)