auth in github actions

[median prawn]

Hello! What kind of git interactions are you picturing? Simply loading dagger modules from private repos, or more advanced interactions programmed inside your module logic?

[soft saffron]

Loading modules from private repos, cloning private repos, and committing changes back are the primary use cases to start with.

[median prawn]

OK, I believe @rapid dock is the expert of git auth in Dagger. So we should wait for him to weigh in (it's morning for him).

[rapid dock]

Hi 👋,

Most users rely on the fact that Dagger supports Git credential helpers, which can seamlessly handle authentication using Personal Access Tokens (PATs).

In your GitHub Actions setup, you can pass the PAT securely to Dagger by initializing a credential helper. Dagger will automatically pick up these credentials for interacting with private repositories.

Here’s a concrete example of this approach in action (for GitLab): https://github.com/dagger/dagger/issues/8989#issuecomment-2521503589.

As shown in the example above, and for GitHub, this integration should be straightforward 😇

Don't hesitate to ping if you need a hand, happy to help

[median prawn]

But isn't that only for loading modules from private git repos? I thought it didn't work for programmatic git operations, which is what @soft saffron wants to do

[rapid dock]

Oh so inside a Dagger pipeline pushing to another private repo and such ?

[median prawn]

My understanding based on 👆

[soft saffron]

Yes exactly.

Ideally we'd use a github app instead of a PAT though.

[median prawn]

can you explain what you mean by using a github app, and the benefits of that? This is an app you have already developed and want to reuse?

cc @abstract nova

[rapid dock]

My guess is that you're looking to use the github app token for those operations to centralise the token management ? (correct me if i'm wrong)

[soft saffron]

Yeah I'm trying to use a github app essentially as a service account. Without it, I'd have to create a github user account and long lived auth credentials for that user. Management of that user account doesn't scale well in a team and requires us to share access credentials if any changes need to be made to the PAT or whatever.
https://docs.github.com/en/apps

The code behind this app would be dagger.

Mostly run from an actions workflow but sometimes locally to test changes.

[rapid dock]

Thanks for the details 🙏

Short answer: today Dagger’s built-in git APIs are read-oriented (clone/fetch). For write operations (commits/pushes), the recommended pattern is to run git via an exec step inside the pipeline. Since directories are first-class in Dagger, you can clone a repo into a working dir, mutate files, then commit and push from within the container.

We recently added the possibility to transform any Directory with a .git into a first-class Git object, via .AsGit(), so it might make sense to allow the push function on top of it now ? Auth would be passed down the same way as for our read operations, as it's a git top-level primitive.

So there are two parts for your request: 1) retrieving the token of your app and 2) passing it down to Dagger

If you’re on GitHub Actions, the simplest and most secure way to authenticate is with a short-lived GitHub App installation token, passed to Dagger as a secret, then used by git via a per-process header:

- uses: actions/create-github-app-token@v1
  id: app
  with:
    app-id: ${{ secrets.APP_ID }}
    private-key: ${{ secrets.APP_PRIVATE_KEY }}
    owner: your-org
# Export the token to your Dagger step (env or secret input)
- uses: dagger/dagger-for-github@vX
  env:
    GIT_AUTH_TOKEN: ${{ steps.app.outputs.token }}

And inside your Dagger pipeline (via exec), mount the env var as a secret,n then configure git inside the withExec step:

The configuration would look something like this:

AUTH="Authorization: Basic $(printf 'x-access-token:%s' "$GIT_AUTH_TOKEN" | base64 | tr -d '\n')"
git -c http.https://github.com/.extraheader="$AUTH" clone https://github.com/your-org/deploy.git work
cd work
# … mutate files …
git add -A && git commit -m "bump image tag"
git -c http.https://github.com/.extraheader="$AUTH" push origin HEAD:refs/heads/your-branch

@median prawn, does adding Push to Git make sense ? was there a reason to be read-only atm ?

[abstract nova]

as an example of this flow with the github app -> token, here's this in my demo repo https://github.com/kpenfound/greetings-api/blob/main/.github/workflows/test.yml#L10-L15

[median prawn]

auth in github actions

[median prawn]

cc @humble dragon 😇

[soft saffron]

Heh.. Thanks guys. Hugely helpful. I'll play around with it.

Wasn't aware of http.extraHeader

[median prawn]

@rapid dock are you saying that for read operations, the core git() API automatically supports PAT and other auth configuration on the host? similar to how Container.publish() supports host docker auth?

oh that's super nice. I thought it only worked when loading modules

[rapid dock]

Actually, let me double check, I think you're right, I misinterpreted -- sorry. But that would be nice

[humble dragon]

@rapid dock @median prawn welcome to https://github.com/dagger/dagger/issues/7202

[humble dragon]

yes it supports the host

it used to only be for modules, but i lifted all that logic out into git, it was a lot neater (and it's additional bonus functionality, so!)

[median prawn]

excellent!

(if we add support for push, which makes sense, we should think of the security implications btw)