taiki-e
Feature Request: Support for private cargo registries in cargo-binstall fallback
Summary
Currently, taiki-e/install-action uses cargo-binstall as a fallback for unsupported tools, but this fallback doesn't support custom cargo registries. This means tools published to private or alternative registries cannot be installed using the action and require separate installation steps.
Use Case
I have a tool published to a private registry hosted on Shipyard.rs. Currently, I need a separate installation step:
- name: Install my-tool
env:
CARGO_NET_GIT_FETCH_WITH_CLI: true
run: |
set -euo pipefail
VER="$(sed -e 's/^[v=]*//' -e 's/[[:space:]]*$//' app/tool-version.txt)"
cargo install --locked --registry my-private-registry my-tool --version "$VER" || true
It would be much cleaner to handle this through the action:
- uses: taiki-e/install-action@v2
with:
tool: [email protected]
registry: my-private-registry
Proposed Solution
Add support for a registry input parameter that gets passed to the cargo-binstall fallback command. When specified, the fallback would use:
cargo-binstall binstall --force --no-confirm --locked --registry <registry> "${unsupported_tools[@]}"
Alternative Solutions
-
Tool-specific registry configuration: Allow specifying registry per tool in the tool list:
tool: [email protected]:my-private-registry -
Environment variable support: Respect
CARGO_INSTALL_REGISTRYor similar environment variables in the fallback. -
Extend manifest system: Allow the action's manifest system to reference tools from custom registries.
Benefits
- Consolidates tool installation into a single action
- Maintains consistency with other cargo tools
- Reduces workflow complexity
- Better caching behavior (tools installed via the action benefit from better path management)
Current Workaround
I currently use a separate step with cargo install --registry <registry>, but this:
- Adds workflow complexity
- Doesn't benefit from the action's optimized installation and caching
- Requires manual version management
- Creates inconsistency in tool management
My initial thought is this approach has the biggest bang for buck:
Environment variable support: Respect CARGO_INSTALL_REGISTRY or similar environment variables in the fallback.
And I am surprised this doesnt already work.
If we can get this working for you, it also allows other people being able to control cargo-binstall to achieve other objectives.
I've started https://github.com/cargo-bins/cargo-binstall/pull/2297 to better under what cargo-binstall supports, but it doesnt show the env vars.
Looking at https://github.com/cargo-bins/cargo-binstall/blob/1c0f7dc22c321108967f5d9c8306c911123eeb87/crates/bin/src/args.rs , searching for "env ="
I dont see CARGO_INSTALL_REGISTRY there.
It looks like CARGO_REGISTRY_DEFAULT might be able to be used to achieve what you want, if you only need to install tools from your private registry.
If that doesnt work, maybe we can improve cargo-binstall to add envvars that allow you to do what you are trying to do.
If we go with something like tool: [email protected]:my-private-registry , I would suggest that we design this based on URIs , probably https://github.com/package-url/purl-spec , which means something like pkg:cargo/<private index>/[email protected]
In Node.js it's possible to configure both public and private registries in a single step, for example with actions/setup-node:
- name: Setup Node
uses: actions/setup-node@v5
with:
registry-url: https://npm.pkg.github.com
scope: @myorg
This tells the package manager that dependencies under the @myorg scope should be installed from GitHub Packages, while everything else is resolved from the default public registry (https://registry.npmjs.org).
The same can also be achieved via an .npmrc file:
# Configure GitHub Packages for @myorg scope only
@myorg:registry=https://npm.pkg.github.com
//npm.pkg.github.com/:_authToken=${NODE_AUTH_TOKEN}
I'd like to see similar functionality in a single taiki-e/install-action step, resolving crates from the default public registry (https://crates.io/) while allowing specific crates to be pulled from a private registry.
@garysassano ,
I'd like to see similar functionality in a single taiki-e/install-action step, resolving crates from the default public registry (https://crates.io/) while allowing specific crates to be pulled from a private registry.
Does https://github.com/cargo-bins/cargo-binstall/ support that?
Because taiki-e/install-action relies on cargo-binstall for installing from a Cargo registry. If cargo-binstall supports what you want, it is easy for taiki-e/install-action to also support this.