How to use gh auth login CLI Programmatically in GitHub Actions | josh-ops

[utterances-bot]

How to use gh auth login CLI Programmatically in GitHub Actions | josh-ops

Using the gh cli to programmatically authenticate in GitHub Actions

https://josh-ops.com/posts/gh-auth-login-in-actions/

[shuuji3]

Thanks for sharing useful tips! 🙂 I was searching the same issue and found another way to set the token. gh check specific environment variables (gh environment | GitHub CLI) so we can also set GH_TOKEN environment variable like the following:

---
on:
  - pull_request
env:
  GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
  ...

This might be helpful in some case.

[joshjohanning]

ahh! That is super helpful, thanks for the tip @shuuji3 !

Then you can just run your regular gh commands with GH_TOKEN set, very nice.

[joshjohanning]

I just updated the post to reflect this :)

Thanks!

[shuuji3]

Nice! Thank you for the update.

[harsid17]

Hey Josh, thanks for this! I was running into an issue using this auth method and was wondering if you could help! I wanted to use the command gh release edit --repo $REPO_TWO within a workflow in REPO_ONE. Both repos are private repos. So I set up auth as you mentioned:

env:
       GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
       REPO_TWO: 'some-other-private-repo`

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
           - name: CLI Auth
              run: |
                   gh api -X GET /repos/${{ GITHUB.REPOSITORY }}/topics --jq='.names'

           - name: Release
              run: |
                   gh release edit --repo $REPO_TWO .....

With this, I still run into a HTTP 404 error on the Release step, which leads me to believe Auth isn't working properly. Is there a different auth step I need since I'm referencing REPO_TWO?

[joshjohanning]

Yes @harsid17! Since you're accessing resources outside of the repo where you are running your action, you will have to create a secret in this repo with a PAT that you generate and refer to that. The ${{ secrets.GITHUB_TOKEN }} only has access to resources in the current repo.

This would be a good use case for the newer "fine-grained" PATs, otherwise a PAT that you create would have access to ALL repositories that you have access to, and with the fine-grained PAT, you can only give it access to $REPO_TWO.

Then something like this:

env:
  GH_TOKEN: ${{ secrets.MY_PAT }}
  REPO_TWO: 'some-other-private-repo`

[harsid17]

that makes sense. Is there a way to authenticate without needing a PAT? Wondering as both private repos are under an organization with limited to no access to generating/storing secrets other than those provided

[joshjohanning]

Yes @harsid17! The better way is to use a GitHub app: temporary generated authentication that doesn't rely on an individual user. See my other post for an example of how you could implement this in Actions.

But you would need to have an administrator in the organization install the app on the target repository for you 😢 .

[harsid17]

This is great, thanks so much!

[james-s-w-clark]

This has been a really helpful resource! There are a few things I'd like to add, which may help other users of GitHub Enterprise:

• Even if you pipe in a token and use --with-token, if it's for GHES you would need to actually run echo TOKEN | gh auth login --hostname github.companydomain.com --with-token.
  • The hostname can't be extracted from the token, it seems
  • Even if you set GH_HOST, doing echo TOKEN | gh auth login --with-token still requires user interaction (to choose between github.com and your enterprise domain). At least, for slightly older versions of the GH CLI.
• If you run just gh environment, you see what environment variables the GitHub CLI can pick up automatically. Of note are GH_HOST and GH_ENTERPRISE_TOKEN. Here's an (abbreviated) example usage that got our GH CLI running in self-hosted runners:

• name: do GH CLI stuff env: GH_ENTERPRISE_TOKEN: ${{ secrets.GITHUB_TOKEN }} GH_HOST: github.companydomain.com run: |

  Note: Don't need to login with gh auth!

  .... gh pr list

[joshjohanning]

Great tip @IdiosApps on the GH_HOST and --hostname parameters for GHES - thank you!