Feature Request: Use GitHub App to checkout

[alec-pinson]

We are unable to create service/bot accounts within our Enterprise.
We would really like the option to be able to use a GitHub app for authentication.

I created an example of how this would work below:-

      - uses: actions/checkout@v2
        with:
          repository: <org>/github-actions
          github_app_id: ${{ secrets.APP_ID }}
          github_app_key: ${{ secrets.APP_KEY }}
          path: .github/actions

This is our current workaround but we would prefer to remove the generate token step

      - name: Generate token
        id: generate_token
        uses: tibdex/github-app-token@v1
        with:
          app_id: ${{ secrets.APP_ID }}
          private_key: ${{ secrets.APP_KEY }}

      - name: Checkout action
        uses: actions/checkout@v2
        with:
          repository: <org>/github-actions
          token: ${{ steps.generate_token.outputs.token }}
          path: .github/actions

[kousu]

We're using Github Organizations, but not GitHub Enterprise. As far as I can tell, there's no such thing as Service Accounts on github.com anymore. Is that true? The only reference I see to them on the docs currently are here, which is

1. Only rendered under "Enterprise Cloud" (so, probably not supported at all on the public site)
2. Says "To retain access", as if service accounts are even being deprecated even on Enterprise sites

Does anyone know if they got phased out this year?

PATs are fine for personal projects, and maybe service accounts (if they exist?) are fine for big corporate ones, but for projects in the middle (+ enterprise accounts if service accounts have been phased out?), I really agree with this

It seems inappropriate for a CI job to use a PAT. If I leave the organization, the workflow will just start failing.

So your workaround is very helpful to me at the moment :). Thank you for sharing it @alec-pinson.

I think what Github is expecting people who need to have workflows trigger workflows to migrate to Reusable Workflows. I got that working but found it takes a significant amount of extra code to handle triggering each process and at least a few echo '::set-output name=KEY::value's to finagle everything, which is a step backwards IMO. I'm going to migrate to tibdex/github-app-token now, and also put my vote in for this feature to be integrated directly into actions/checkout.

[loganvolkers]

Looks like there is a PR from 2020 that implements this functionality: #220

[bakwc]

Any progress here?

[Jojoooo1]

any new on this ?

[vixus0]

For people who also came across this issue, the official way of doing this seems to be covered here: https://github.com/actions/create-github-app-token#use-app-token-with-actionscheckout

[anxo-outeiral]

For people who also came across this issue, the official way of doing this seems to be covered here: https://github.com/actions/create-github-app-token#use-app-token-with-actionscheckout

Thanks a lot @vixus0 . It works perfectly!

I found this issue after searching for a lot of information to be able to download other private repositories from a certain GitHub Actions pipeline from our Enterprise/Organization. With this indicated actions function, it has worked perfectly for me.

My idea was not to use a PAT (which is the only option that allows this actions https://github.com/actions/checkout#checkout-multiple-repos-private). Therefore, the only available and safe option was to use a Github App.

Let me share with you another URL (https://dev.to/dtinth/authenticating-as-a-github-app-in-a-github-actions-workflow-27co) that I found during this research process, and that helped me reach this issue.

[wherka-ama]

Intro

It's been a while since people left comments here. I'll try to freshen it up a bit as I don't believe we have a perfect solution as of 2025.
We have a bunch of workarounds for various flows. Sure. With a bit of an awkward dance it may even work, but I'm yet to see one consistent recipe that actually works smoothly.

Enterprise Context

In the Enterprise environment where I also work apart from the Open Source, there are certain limitations like the repositories distribututed across multiple organisations and Enterprises and where there is a desire to work in the Inner Source model.
For that purpose the common pattern is to use the submodules. It is fairly natural and a very efficient way to reduce the duplication by always refering to the 'single truth' repos.
It's all good on paper. However, the moment we cross the origanisation, the GITHUB_TOKEN obtained manually or even with actions/create-github-app-token will only suffice to extend the scope by the installation of a given app in one organisation - which may totall to 2 organisation: the one we start with and the other extended by the extra token generated by the action mentioned earlier.

Proposal

To make it work smootly we would need to use the github app installed in all the organisations in the scope of the submodules ensuring only the minimal set of privileges granted to checkout the code.
Then such application would need to be incorporated into a flow which dynamically routes the requests from git and generates the tokens required to checkout specified submodules respecting the organisations and perhaps even fully qualified paths of the repos.
This is not a magic wand, of course. We would need to use the git-credential protocol to make it work.

I believe such solution should be implemented as part of the the actions/checkout and used when some extra configuration parameters suggesting that we have to deal with more complex scenarios are passed.

If there is an interest of the community and the maintainers of `actions/checkout`` I am willing to work on the draft implementation of such solution for the benefit of the entire community.