trusted-publish

trusted-publish

Every registry here is push-model: the registry never pulls or builds — a GitHub Actions workflow builds and uploads. Trusted publishing makes that upload tokenless: the workflow proves its identity over OIDC and the registry mints a short-lived, auto-expiring upload token. Setup is therefore three artifacts: a workflow in the repo, a trust entry on the registry, and a release to trigger the run.

The trust entry binds four identity fields — owner, repository, workflow filename, environment. The workflow file is the credential: these values must match the registry config character-for-character. This skill fixes them — workflow .github/workflows/publish-<registry>.yml, environment named after the registry — so every run produces the same names and the user types the same values.

Steps

1. Resolve the repo. The argument, when given, is the repo path; otherwise use the current directory. Record owner/repo from git remote get-url origin. Done when the path is a git repo with a github.com origin. A GitLab origin narrows provider support — check the reference file's provider line before continuing; any other host means trusted publishing is unavailable: report that and stop.

2. Detect every ecosystem. Walk the repo for package manifests and map each to its registry:

   Manifest	Registry	Reference
   pyproject.toml / setup.py	PyPI	references/pypi.md
   package.json without "private": true	npm	references/npm.md
   Cargo.toml with a [package] section and publish not disabled	crates.io	references/crates-io.md
   *.gemspec, *.nuspec, anything else	varies	references/other-registries.md

   Done when every manifest in the repo is either mapped to a registry or reported to the user as out of scope. Several matches (a monorepo) → run steps 3–6 once per registry.