Dependabot PRs and Workflow Secrets

I was not unfortunately. I was hoping someone from GitHub would respond.

Do you know if there’s a better place to ask this question?

I’ve also just run into this, I added some things to my build that needed an SSH key and now Dependabot is broken :frowning:

I’m going to try using pull_request_target to see if I can get it to work, as this will expose the secrets but comes with security compromises. Wish me luck!

From Events that trigger workflows - GitHub Docs

This event runs in the context of the base of the pull request, rather than in the merge commit as the pull_request event does.

It will exclude commits that were added in the PR. Not too useful for a significant set of workflows. It’s reserved for things like auto-labelling the pull request.


Hi @andreagriffiths11. Not sure if you’re the right person to ask, but do you know how we can provide feedback for the changes outlined in GitHub Actions: Workflows triggered by Dependabot PRs will run with read-only permissions - GitHub Changelog, specifically how secrets are no longer available in pull requests created by Dependabot?


pull_request_target doesn’t work for me.

I tried to split my workflows into the one that builds the project and the one that runs sonarcloud or updates the assets manifest on a dependabot branch see Dependabot doesn't see GitHub actions secrets - #2 by dertobsch but that does not work, because the context of the ‘workflow_run’ workflow is also that from dependabot and cannot access my secrets.

This seems like a pretty critical issue for folks using dependabot with projects that happen to use private packages. A common CI test for a dependency update in a node project would be “does npm install still work?”.


I agree that this is a major issue. Dependabot builds may legitimately need secrets, for example to run automated tests against an external service for which you need credentials, and those credentials can’t be stored anywhere else but secrets.

In our case, we are using a custom GitHub action to automatically approve and merge Dependabot PRs and the now-readonly permissions of the GITHUB_TOKEN secret hit us as well. We had to switch to using an external application to do that instead.

1 Like

I may have run into essentially the same issue as you, but just to add a bit more detail that’s relevant in my case:

Even for public repos, I cannot use the “@dependabot merge” feature with Github Actions as CI. When Dependabot merges, the on: push workflows will not run. To get around this I’ve added a workflow that auto-merges PRs once they have a “ready” label using my Github token but now that doesn’t work since the Github token is a secret.

Ironically all this wouldn’t be a non-issue if I used a third-party service for CI, but I can’t imagine that’s the workflow Github intends for Dependabot users.

1 Like

I haven’t tried it yet but in the GitHub Blog there’s an example for Scripting with GitHub CLI and Using gh in GitHub Actions to “enable auto-merge for new PRs”. This is more general than Dependabot PRs but could be conditional based on author. Would that work?

1 Like

Thanks for sharing that article, I didn’t know about the gh CLI and that looks super useful!

To be fair, I haven’t tried it yet but my intuition is that this wouldn’t solve the problem described here unfortunately. I think the crux of the issue is that when Dependabot kicks off the workflow, it won’t have access to a GITHUB_TOKEN that can perform the merge.

This is a major bummer for us. Does anybody know (or happen to work with the Github Actions team) whether Github will be fixing this somehow? The current workaround is a pretty major hack and it doesn’t make much sense to have to do so much work just to make Github able to access secrets it already has.

Our current workaround is to just manually re-run workflows for dependabot PRs. Then the actor becomes you and the limitation doesn’t apply anymore.


This is affecting us too and its a major pain

Looks like there is now a way of (separately) storing secrets just for dependabot.

I haven’t tried it myself yet, so I don’t know if there are any limitations etc, but just saw the blog post mentioning it.

This seems to only affect dependabot.yml, but does not affect workflows. At least it didn’t work for me.

I was able to get pull_request_target working, it appears that the actual issue was related to a GitHub Action that I updated and it started working after that, so it’s possible that the issue could be around the code in the GitHub Action scripts that are used and not with the trigger itself.

I’m about ready to migrate away from Dependabot in favor of a hand-rolled Action that runs with a proper token because of all the noise from failed builds. Are there any plans to make this a nicer experience?


Running into the same issue, we have test and branch-deploy actions that we want to execute on dependabot PRs that are no longer working due to their lack of access to these secrets.