How to allow dependabot to authenticate on Magento registry?

132 views Asked by At

I configured Dependabot on my Github repository but it can't authenticate on repo.magento.com.

I've configured the .github/dependabot.yml file like this:

version: 2
registries:
  adobe:
    type: composer-repository
    url: repo.magento.com
    username: XXXXXXXXXXXXXXX
    password: ${{secrets.DEPENDABOT_COMPOSER_PASSWORD}}
  github:
    type: composer-repository
    url: github.com
    username: XXXXXXXXXXXXXXX
    password: ${{secrets.DEPENDABOT_GITHUB_PASSWORD}}
updates:
  - package-ecosystem: "composer" # See documentation for possible values
    directory: "/magento/site" # Location of package manifests
    registries:
      - adobe
      - github
    schedule:
      interval: "weekly"
    target-branch: "develop"
    open-pull-requests-limit: 0

But I keep getting authentication errors in Dependabot logs:

  proxy | 2024/02/14 10:53:18 [067] GET https://repo.magento.com:443/packages.json
  proxy | 2024/02/14 10:53:18 [067] 401 https://repo.magento.com:443/packages.json
  proxy | 2024/02/14 10:53:18 [067] Remote response: {"warning":"You haven\u0027t provided your Magento authentication keys. For instructions, visit https:\/\/devdocs.magento.com\/guides\/v2.3\/install-gde\/prereq\/connect-auth.html"}
updater | 2024/02/14 10:53:19 INFO <job_786964504> Handled error whilst updating composer/composer: private_source_authentication_failure {:source=>"repo.magento.com"}
updater | 2024/02/14 10:53:19 INFO <job_786964504> Finished job processing
updater | 2024/02/14 10:53:19 INFO Results:
updater | Dependabot encountered '1' error(s) during execution, please check the logs for more details.
updater | +-----------------------------------------------------------+
updater | |               Dependencies failed to update               |
updater | +-------------------+---------------------------------------+
updater | | composer/composer | private_source_authentication_failure |
updater | +-------------------+---------------------------------------

Obviously i've double-checked my username and password is correct.

Thanks for your help.

1

There are 1 answers

6
VonC On BEST ANSWER

Check first if you have created a Dependabot secret

Dependabot secrets are encrypted credentials that you create at either the organization level or the repository level.
When you add a secret at the organization level, you can specify which repositories can access the secret.

You can use secrets to allow Dependabot to update dependencies located in private package registries. When you add a secret, it's encrypted before it reaches GitHub and it remains encrypted until it's used by Dependabot to access a private package registry.

Dependabot secrets also include secrets that are used by GitHub Actions workflows triggered by Dependabot pull requests. Dependabot itself may not use these secrets, but the workflows require them.

When a Dependabot event triggers a workflow, the only secrets available to the workflow are Dependabot secrets. GitHub Actions secrets are not available.

See also "Configuring Dependabot for Reusable Workflows in GitHub" from Josh Johanning, for granting Dependabot authorization to Dependabot to access your repository.


The discussion orgs/community discussion 109704 now includes the OP's conclusion:

Seems I found the issue.
The target-branch option seems to prevent security updates from using my registries as defined in this documentation.

When you use this option, the settings for this package manager will no longer affect any pull requests raised for security updates.

This doesn't makes any sense to me. Why such a limitation on the branch functionality?

Dependabot handles security updates separately from regular version updates. When you specify a target-branch in your Dependabot configuration, this setting redirects where Dependabot creates pull requests for version updates. However, this redirection does not apply to pull requests for security updates, which are handled with a preference for the default branch.

By targeting security updates to the default branch, Dependabot simplifies the workflow for managing critical vulnerabilities. That avoids the complexity that might arise from having security fixes spread across multiple branches, which could lead to missed patches or the need for additional merge operations to make sure all branches are secure.

The limitation reflects common branch management practices, where the default branch (often main or master) represents the "source of truth" for the project's current stable state. Feature development and non-critical updates might happen in other branches (develop, feature branches, etc.), but the default branch is typically where the final, production-ready code resides. Targeting security updates to this branch makes sure the most important fixes are applied to the codebase that is most likely to be deployed.

For teams and projects that might not closely monitor all active branches, making sure that security updates are automatically applied to the default branch helps in adopting a security-first approach without needing to configure additional workflows or monitoring tools.

So this limitation illustrates the balance Dependabot tries to maintain between automating dependency updates (including security patches) and aligning with common development practices. It is a design choice aimed at making sure that projects remain as secure as possible by default, even if it introduces some constraints on how updates are managed across different branches.

For projects that require a different approach, such as applying security updates to branches other than the default, manual intervention or additional CI/CD workflows might be necessary to make sure security patches are applied across all necessary branches.