Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Does Evergreen support Dependabot configuration for private registries? #199

Open
charliew33 opened this issue Aug 14, 2024 · 3 comments
Open
Labels
enhancement New feature or request keep do not mark as stale ready-for-work Issue is defined enough to begin implementation

Comments

@charliew33
Copy link

charliew33 commented Aug 14, 2024

Is your feature request related to a problem?

When setting up dependabot.yml files I typically need to set up at least one private registry, depending on the ecosystems being used. Is there a way to configure Evergreen to include the private registry config in the deployed dependabot.yml files?

Describe the solution you'd like

Ideally I'd like to be able to configure that for particular ecosystems, Evergreen should include the private registry config in the dependabot.yml, for example for npm:

version: 2
registries:
  npm-npmjs:
    type: npm-registry
    url: https://registry.npmjs.org
    username: octocat
    password: ${{secrets.MY_NPM_PASSWORD}}

updates:
  - package-ecosystem: "npm"
    directory: "/"
    registries:
      - npm-npmjs
    schedule:
      interval: "weekly"

Describe alternatives you've considered

No response

Additional context

No response

@charliew33 charliew33 added the enhancement New feature or request label Aug 14, 2024
@zkoppert
Copy link
Member

Great use case! Evergreen doesn't support this today but implementing this is feasible. Likely would need to specify a file to use to override specific package managers.

@zkoppert zkoppert added the ready-for-work Issue is defined enough to begin implementation label Aug 14, 2024
Copy link

github-actions bot commented Sep 5, 2024

This issue is stale because it has been open 21 days with no activity. Remove stale label or comment or this will be closed in 14 days.

@github-actions github-actions bot added the Stale label Sep 5, 2024
@zkoppert zkoppert added keep do not mark as stale and removed Stale labels Sep 15, 2024
@ricardojdsilva87
Copy link
Contributor

Just giving my input here.
I think that we would need to understand how to assign a private repo to a package type.
For example if on an organization there are several npm, maven, docker, etc repositories we would need to add a private repository configuration for each one of them.
Since evergreen is supposed to run for all repositories, maybe this could be some kind of yaml file that could be referenced as input on the action and then added to the generated dependabot.yml file, depending on the type of dependencies found on the repositories.
There are several private registries that can serve as a proxy mirror to public repositories for example.
The created file would be something similar to:

  npm:
    type: npm-registry
    url: https://yourrepository.com/npm/
    username: username
    password: ${{secrets.password}}
  maven:
    type: maven-repository
    url: https://yourrepository.com/maven/
    username: username
    password: ${{secrets.password}}
  docker:
    type: docker-registry
    url: https://yourrepository.com/docker/
    username: username
    password: ${{secrets.password}}

When building the dependabot.yaml the code would look into this created file with the private registries and try to match the found dependencies list with the first level on the yaml file adding the private registry in the key registries: under the dependabot.yaml file and on the detected registry configuration.

I will try to think on an update to add this change, let me know what you think

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request keep do not mark as stale ready-for-work Issue is defined enough to begin implementation
Projects
None yet
Development

No branches or pull requests

3 participants