Private Hex packages

[kamilkowalski]

What would you like Renovate to be able to do?

I'd like Renovate to handle private Hex packages. We're using Renovate to maintain our services, but since we're using private Hex packages (not a self-hosted repository though) - all it can do for Elixir is to update the version range but not the lock file.

Did you already have any implementation ideas?

In Hex, private packages are hosted in a separate repository owned by an organization. One needs to sign in to each organization to be able to fetch packages from it. Hex guides on private packages suggest creating per-organization tokens to use in CI, instead of personal tokens. This means that if a project uses packages from multiple organizations's repositories, it would need multiple access tokens to be configured - one per organization. However, it's also possible to create a personal token that has access to multiple organizations.

Proposal 1: One personal Hex token or one organization

1. Extend the configuration with a hexToken value, similar to npmToken.
2. Modify the hex data source to use the organization name together with the hexToken when fetching package information.
3. Modify the mix manager to authenticate to Hex using the token before updating mix.lock. The list of organizations would be taken from the mix.exs file.

Limitations

The main limitation is that if a project uses packages from multiple organizations - users would need to generate a personal Hex token that allows access to repositories of all organizations used in the project. This isn't aligned with Hex guides on private packages, but it's possible to configure a token so that it has only access to those specific repositories and prevent anyone who obtained the token to impersonate the user (the repo permission is separate from API permissions) so I think it's a safe option.

On the other hand - if a project uses packages from one organization, they can simply use an organizational token. My assumption is this is the prevalent use case.

Proposal 2: Multiple organizational Hex tokens

1. Extend the configuration with a hexTokens dictionary that maps organization names to tokens.
2. Modify decryptConfig so that it decrypts values recursively if they're objects instead of strings.
3. Modify the hex data source to use the organization name together with the matching token from the hexTokens dictionary.
4. Modify the mix manager to authenticate to Hex using organization names and keys from hexTokens, before updating mix.lock.

My suggestion

I think Proposal 1 is good enough. I don't think it's a common use case to have packages from multiple organizations in one project, and there is a safe workaround if that's the case. This avoids the need to change the decryptConfig function - I don't know what would be the side effects of modifying it to be recursive.

Links

• How to authenticate to Hex on CI
• Hex API documentation on authentication

---

I'm happy to open a PR, but I might need some help testing the change.

[rarkins]

The way we prefer is to configure hostRules with token field populated. Then the artifacts updating code can search for all hostRules with matching hostType and pass them to the tool using either env, cli, or configuration file (depending on what the tool supports).

npmToken is a legacy approach from when Renovate was npm-only so it's not something we'd like to model after (or we'd end up with many new options rather than a shared hostRules approach).

Can you take a look at how hostRules are used in existing managers like bundler and composer and confirm if that would suit you too? It's possible that both PAT and keg tokens could be supported based on the matchHost URL

[kamilkowalski]

@rarkins sounds good, thanks for the clarification on npmToken. We could definitely do something similar to Bundler's artifacts update for the mix manager, and something like Docker's or Packagist's release fetching for hex - they all use hostRules to authenticate to the registry.

Can I take a whack at it? I've read the contributing guide and the local development guide. Anything else I should be familiar with?

[rarkins]

@kamilkowalski it would be wonderful if you can submit a PR! Feel free to ask back here if you encounter any decisions you need help on. We always have quite a few active PRs you can look at to get a feel of how we work, and we have a Slack developer channel too if you'd like to join.

[kamilkowalski]

@rarkins I've opened #11168 with an implementation proposal - I'd appreciate your feedback.

[kamilkowalski]

@rarkins I think this can be closed now?