Summary
Set up a secure, transparent, repeatable npm release pipeline for Primajin/Gyros so the package can be published and maintained with confidence.
Problem
We want to publish Gyros to npm and get it into users' hands, but the package namespace gyros is already taken. We also need a release process that raises trust and makes it clear that the published package is built directly from this repository's source rather than from an opaque or manually-driven process.
Today, we have an NPM_TOKEN secret configured for Actions with a 90-day token lifetime, and it is not available to Copilot agents or Dependabot. However, we still need to design and implement the release automation around it.
Proposed work
- Determine the package publishing strategy:
- evaluate an alternative available npm package name, or
- publish under the user scope if that is the preferred path.
- Copy/adapt the release and commit lint workflows from the sibling project
Primajin/webapp-console-log-action.
- Use conventional commits plus Release Please to create a repeatable, auditable release flow.
- Add npm publishing automation that runs after a GitHub Release is created.
- Ensure the publish pipeline is secure and transparent so consumers can verify that the npm artifact corresponds to the source in this repository.
Requirements
- Release automation should be based on GitHub Actions.
- The pipeline should use the existing
NPM_TOKEN Actions secret.
- Publishing must not rely on manual local steps.
- The process should make the provenance of the published package easy to understand and inspect.
- The workflow should be modeled after
Primajin/webapp-console-log-action where appropriate.
Acceptance criteria
- A package name decision is documented and implemented (
new unscoped name or @Primajin/<name> style publishing).
- the users profile is https://www.npmjs.com/~primajin
- Conventional commits and Release Please are configured in
Primajin/Gyros.
- A release workflow exists that creates or updates releases in a repeatable way.
- An npm publish workflow exists and runs only after the GitHub release step succeeds.
- The npm publish job uses the
NPM_TOKEN secret from GitHub Actions.
- The workflow design clearly demonstrates that published artifacts are generated from the repository source in CI.
- Documentation is added describing how releases are cut and how trust/transparency are maintained.
Implementation notes
Potential implementation details to consider:
- use GitHub Releases as the gate for npm publication;
- ensure package versioning is driven by Release Please;
- consider npm provenance / trusted publishing support if compatible with the repository and package setup;
- document the exact workflow chain so maintainers and users can audit the process.
Reference
Sibling project to mirror/adapt:
Summary
Set up a secure, transparent, repeatable npm release pipeline for
Primajin/Gyrosso the package can be published and maintained with confidence.Problem
We want to publish Gyros to npm and get it into users' hands, but the package namespace
gyrosis already taken. We also need a release process that raises trust and makes it clear that the published package is built directly from this repository's source rather than from an opaque or manually-driven process.Today, we have an
NPM_TOKENsecret configured for Actions with a 90-day token lifetime, and it is not available to Copilot agents or Dependabot. However, we still need to design and implement the release automation around it.Proposed work
Primajin/webapp-console-log-action.Requirements
NPM_TOKENActions secret.Primajin/webapp-console-log-actionwhere appropriate.Acceptance criteria
new unscoped nameor@Primajin/<name>style publishing).Primajin/Gyros.NPM_TOKENsecret from GitHub Actions.Implementation notes
Potential implementation details to consider:
Reference
Sibling project to mirror/adapt: