| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
There was a problem hiding this comment.
Falling back to the other token is useful on GitHub Enterprise Server, where it will have access to all public repositories.
That said, I'm happy with the change. I think the implicit credentials should technically still work, so the fallback is still there; it's just in a different place.
Sorry, something went wrong.
Could you explain what you mean here? Also I now realise that I haven't actually tried testing that this fixes the bug. If the github token is being picked up through some other means there's a chance this won't fix anything. |
Sorry, something went wrong.
|
The GITHUB_TOKEN is stored in the Git configuration of the runner automatically when you do a checkout so it will also be used for Git operations against external repositories even if we don't pass it explicitly. |
Sorry, something went wrong.
|
I've tested this out in all possible configurations that I could think of and it seems to be working as expected.
|
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Addresses a bug reported by @lcartey that we accidentally introduced in #357 which was breaking the workflow for people using a workaround we suggested at https://docs.github.com/en/github/finding-security-vulnerabilities-and-errors-in-your-code/configuring-code-scanning#accessing-private-repositories and also a version using a deploy key and rewriting to a SSH URL.
The PR changes it so we only insert the external repositories token into the URL if it is explicitly supplied and don't fall back to using the main github token. Also avoids adding in a double slash to the URL sometimes.
@chrisgavin do you think this is ok? Why was the falling back to the other token there? It's unlikely to have access to other repos. Was it just in case it did to avoid having to add the token argument twice?
Merge / deployment checklist