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.
Check first if you have created a Dependabot secret
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: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
ormaster
) 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.