Dependabot can't fetch secrets from GitHub?

[ryanzidago]

dependabot.yml content

# To get started with Dependabot version updates, you'll need to specify which
# package ecosystems to update and where the package manifests are located.
# Please see the documentation for all configuration options:
# https://help.github.com/github/administering-a-repository/configuration-options-for-dependency-updates

version: 2
updates:
  - package-ecosystem: "mix" # See documentation for possible values
    directory: "/" # Location of package manifests
    schedule:
      interval: "weekly"

  - package-ecosystem: "npm" # See documentation for possible values
    directory: "/assets/" # Location of package manifests
    schedule:
      interval: "weekly"

  - package-ecosystem: "github-actions" # See documentation for possible values
    directory: "/" # Location of package manifests
    schedule:
      interval: "weekly"

What you expected to see, versus what you actually saw?

I expected that, once Dependabot's open up a PR for updating a package, Dependabot has access to GitHub Secrets.
Here's the problem however:
I'm using this action to fetch private repositories from GitHub that will then be used as private dependencies in my projects. In this action, each dependencies is fetched in order, based on a secret.

The problem is that, once Dependabot opens up a PR to update a dependency, the CI stops and returns the following error:

The ssh-private-key argument is empty. Maybe the secret has not been configured, or you are using a wrong secret name in your workflow file.

Which is false because I configured all the keys in my organisation's settings for Dependabot under https://github.com/organizations/MY-ORGANIZATION/settings/secrets/dependabot. I know that the keys are correct. I also explicitely gave Dependabot access to all of the private repositories that I which to be updated by Dependabot. Basically, I did what's mentioned in this blog post.

What did I tried to solve this issue?

• I told Dependabot to recreate the PR with @dependabot recreate => Didn't work
• I tried to overwrite the Organization's secrets with secrets configured at the repository level. => Didn't work either
• I manually restarted the failed workflow triggered by Dependabot's PR => It works, but is cumbersome.

Could it be that Dependabot has a problem with fetching secrets?

[jurre]

You'll still need to add configuration for those secrets to the config file, I think this should solve your problem: https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates#configuration-options-for-private-registries

[ryanzidago]

You'll still need to add configuration for those secrets to the config file, I think this should solve your problem: https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates#configuration-options-for-private-registries

@jurre thanks for the quick reply.

I added the following lines to the dependabot.yml file:

registries:
  github-octocat:
    type: git
    url: https://github.com
    username: x-access-token
    password: ${{ secrets.DEPENDABOT_ACCESS_TOKEN }}

I also created a GitHub Access Token from my profile and put it in my repo, under https://github.com/MYORGANIZATION/myrepo/settings/secrets/dependabot

However, I still get the same error 🤔

I also tried to add the registries key under the updates key:

updates:
  - package-ecosystem: "mix" # See documentation for possible values
    directory: "/" # Location of package manifests
    registries:
      - github
    schedule:
      interval: "weekly"

Without success. I still get the same error.

[asciimike]

Shouldn't these secrets be stored in the actions secrets not in the dependabot secrets? Is your action in response to a pull_request_target (which has access to secrets), or just a pull_request (which doesn't, due to #3253)?

[ryanzidago]

Shouldn't these secrets be stored in the actions secrets not in the dependabot secrets? Is your action in response to a pull_request_target (which has access to secrets), or just a pull_request (which doesn't, due to #3253)?

@asciimike

Those secrets are configured for both actions and dependabot. However, only PRs opened by dependabot fails the CI check due to dependabot not being able to fetch secrets.

How can I know if an action is a response to pull_request_target or pull_request?

[asciimike]

The action would say on: pull_request or on: pull_request_target. Given that it's failing, it sounds like it's using pull_request when it should be using pull_request_target (plus downscoped permissions).

[Roriz]

Up!
We have same issue here
Running based on: push

Falied workflow:

Success workflow:

Same pipe, same variables, same secrets, only a manually restarted make workflow pass

[asciimike]

only a manually restarted make workflow pass

This is because the github.actor is you, not dependabot[bot]. The actions team has decided that this is acceptable.

[Roriz]

Don't look acceptable to me, this workflow running is not free, developer time for running this workflow is not free.
Does not have any alternative for making this process work, similar to old dependabot?

[asciimike]

@Roriz see #3253 (comment). For push events, you have to use a workflow_run event following the original push.

The issue you have is clearly #3253, this issue appears to be related but not necessarily the same.

[jeffwidman]

As best I can tell, everything in here is already tracked or explained in the two following issues:

• Dependabot triggered Actions cant access secrets or use a writable token #3253 (comment)
• Dependabot PR's actions lost access to secrets #5464

So closing as a duplicate. If for some reason I misunderstand, please comment and we can reopen.