CI: add semver tag release workflow for npm publish #6

New Issue

2026-05-05T22:32:50Z

mahseiah_ai commented

2026-05-05 22:32:50 +00:00

Problem

The repository now has Bun-based tests and a Gitea Actions validation workflow, but the release path is not yet exercised end-to-end. For a library intended to be published, we should have a dedicated release workflow that runs on version tags and validates the actual release path instead of relying entirely on ad hoc manual steps.

The target behavior is a Gitea Actions workflow that runs when a tag matching x.y.z is pushed, performs the normal release checks, and exercises npm publish. The main unresolved detail is how npmjs.com authentication should be handled from Gitea Actions.

Goals / scope

Add a dedicated Gitea Actions workflow for releases triggered by pushed tags matching x.y.z
Re-run the project's normal validation in the release workflow, including Bun-based tests and any package/build checks the repo already uses
Validate the package that would be published (for example via npm pack and/or equivalent package-content checks)
Include an npm publish step targeting npmjs.com
Ensure publishing happens only for intended release tags, not for branches or pull requests
Keep the workflow small and understandable; avoid unnecessary matrix or orchestration complexity

Out of scope / non-goals

Automated version bumping
Changelog generation or release notes automation
Publishing to multiple registries
Pre-release channel support (alpha, beta, rc) in the initial version
Complex approval gates, rollback automation, or a broader release-management system

Acceptance criteria

A workflow file exists for releases and is triggered only by tags matching the intended x.y.z pattern
The workflow runs the repo's standard validation using the current tooling, including Bun-based tests
The workflow validates package contents before attempting publish
The workflow includes an npm publish step to npmjs.com that is gated to release tags only
The required authentication mechanism is documented clearly enough for a maintainer to configure it in Gitea
If authentication is missing or misconfigured, the workflow fails in a clear and diagnosable way

Open questions / notes

What is the right npmjs.com authentication approach for this repo in Gitea Actions?
- Likely candidate: an automation token stored as a repository or organization secret such as NPM_TOKEN
- We should confirm that this works cleanly in the current Gitea Actions environment
Which npm account or org should own publishing rights for the package?
Should this workflow also create or update a Gitea release entry, or should that remain out of scope for the first pass?
It may make sense to land the README operational-guidance issue first so the documented manual process and automated process stay aligned.

## Problem The repository now has Bun-based tests and a Gitea Actions validation workflow, but the release path is not yet exercised end-to-end. For a library intended to be published, we should have a dedicated release workflow that runs on version tags and validates the actual release path instead of relying entirely on ad hoc manual steps. The target behavior is a Gitea Actions workflow that runs when a tag matching `x.y.z` is pushed, performs the normal release checks, and exercises `npm publish`. The main unresolved detail is how npmjs.com authentication should be handled from Gitea Actions. ## Goals / scope - [ ] Add a dedicated Gitea Actions workflow for releases triggered by pushed tags matching `x.y.z` - [ ] Re-run the project's normal validation in the release workflow, including Bun-based tests and any package/build checks the repo already uses - [ ] Validate the package that would be published (for example via `npm pack` and/or equivalent package-content checks) - [ ] Include an `npm publish` step targeting npmjs.com - [ ] Ensure publishing happens only for intended release tags, not for branches or pull requests - [ ] Keep the workflow small and understandable; avoid unnecessary matrix or orchestration complexity ## Out of scope / non-goals - [ ] Automated version bumping - [ ] Changelog generation or release notes automation - [ ] Publishing to multiple registries - [ ] Pre-release channel support (`alpha`, `beta`, `rc`) in the initial version - [ ] Complex approval gates, rollback automation, or a broader release-management system ## Acceptance criteria - [ ] A workflow file exists for releases and is triggered only by tags matching the intended `x.y.z` pattern - [ ] The workflow runs the repo's standard validation using the current tooling, including Bun-based tests - [ ] The workflow validates package contents before attempting publish - [ ] The workflow includes an `npm publish` step to npmjs.com that is gated to release tags only - [ ] The required authentication mechanism is documented clearly enough for a maintainer to configure it in Gitea - [ ] If authentication is missing or misconfigured, the workflow fails in a clear and diagnosable way ## Open questions / notes - What is the right npmjs.com authentication approach for this repo in Gitea Actions? - Likely candidate: an automation token stored as a repository or organization secret such as `NPM_TOKEN` - We should confirm that this works cleanly in the current Gitea Actions environment - Which npm account or org should own publishing rights for the package? - Should this workflow also create or update a Gitea release entry, or should that remain out of scope for the first pass? - It may make sense to land the README operational-guidance issue first so the documented manual process and automated process stay aligned.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: jdb/js-logging#6