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

feat(mix): Support private hex repos/registries #29775

Closed

Conversation

bryannaegele
Copy link
Contributor

Changes

This adds support to the mix manager to add private hex repos/registries via registryAliases for mapping and hostRules for authentication.

Context

This is the companion to #29756 and dependent on that change. Splitting the manager and datasource work per request in #29756. When combined, this will enable support for private repos/registries such as oban pro.

Documentation (please check one with an [x])

  • I have updated the documentation, or
  • No documentation update is required

How I've tested my work (please select one)

I have verified these changes via:

  • Code inspection only, or
  • Newly added/modified unit tests, or
  • No unit tests but ran on a real repository, or
  • Both unit tests + ran on a real repository

Tested in combination with #29756. This will not fully work without that code.

@bryannaegele bryannaegele marked this pull request as draft June 20, 2024 15:27
@bryannaegele bryannaegele marked this pull request as draft June 20, 2024 15:27
@bryannaegele bryannaegele marked this pull request as ready for review June 24, 2024 17:23
@HonkingGoose HonkingGoose mentioned this pull request Jul 25, 2024
7 tasks
@epinault

This comment has been minimized.

lib/modules/manager/mix/artifacts.ts Outdated Show resolved Hide resolved
lib/modules/manager/mix/artifacts.ts Outdated Show resolved Hide resolved
lib/modules/manager/mix/artifacts.ts Outdated Show resolved Hide resolved
lib/modules/manager/mix/artifacts.ts Outdated Show resolved Hide resolved
@bryannaegele bryannaegele force-pushed the feat/29622-mix-repo-support branch from 36e3f93 to 6c293a1 Compare August 19, 2024 17:02
@bryannaegele
Copy link
Contributor Author

Feedback should be addressed 👍🏻

@rarkins rarkins requested a review from viceice August 21, 2024 09:38
lib/modules/manager/mix/artifacts.spec.ts Show resolved Hide resolved
lib/modules/manager/mix/artifacts.ts Outdated Show resolved Hide resolved
lib/modules/manager/mix/artifacts.ts Outdated Show resolved Hide resolved
lib/modules/manager/mix/utils.ts Outdated Show resolved Hide resolved
Comment on lines +51 to +53
registryAliases: {
oban: 'https://getoban.pro/repo',
},
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this should be scoped to mix manager, otherwise it will interferre with other managers using registry aliases

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So there needs to be a further nesting of the object? I didn't see any examples of that in other managers

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bryannaegele are you still working on this?
I have the same/very similar use case and I'd love renovate to support elixir correctly.

this particular change can be observed here https://github.com/renovatebot/renovate/blob/main/docs/usage/configuration-options.md#registryaliases
IMO this is what viceice is asking about.

Suggested change
registryAliases: {
oban: 'https://getoban.pro/repo',
},
{
"mix": {
registryAliases: {
oban: 'https://getoban.pro/repo',
},
}
}

Comment on lines +11 to +13
registryAliases: {
hexpm: 'https://hex.pm',
},
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is this needed

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need the URL for the hexpm registry, which is the default, so we put it into the default config. This is merged with anything the user has supplied, giving us a complete lookup of the URLs. This has an added benefit that if a company wished to host an internal proxy registry, no updates are needed to their mix files; they have a way to point someplace else.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you should not add a default url, the datasource has it already, so only set registry url if it's not the default

if (requirement?.startsWith('==')) {
dep.currentVersion = requirement.replace(regEx(/^==\s*/), '');
}

if (organization) {
dep.packageName = `org:${organization}:${app}`;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is used by the hex datasource, so needs changes there too

const [hexPackageName, organizationName] = packageName.split(':');

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is in the other PR. You requested to split them so neither PR will work on its own

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

then don't change package name in this PR, do the package name change in a separate refactor PR

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So neither PR is backwards compatible with the other. They are both dependent on the format change. If we don't change this here then your proposed refactor PR just pushes the change both need to make into a single PR that touches the datasource and manager.

@rarkins rarkins closed this Oct 25, 2024
@epinault
Copy link

epinault commented Nov 6, 2024

this MR is closed, what s the plan? is there a solution merged? what s the end result?

@rarkins
Copy link
Collaborator

rarkins commented Nov 7, 2024

The original author was not able to continue the work. You are welcome to pick it up where he left off and submit a new PR

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Dec 8, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants