Skip to content

infra: #197/#240 create release using workflows #289

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
AndrewSouthpaw merged 13 commits into from
Jan 29, 2026
Merged

infra: #197/#240 create release using workflows #289

Show file tree
Hide file tree
Changes from 12 commits
Commits
Show all changes
13 commits
Select commit Hold shift + click to select a range
d55234f
Auto create release on version tag
thompson-tomo Dec 6, 2025
f15fe70
Add package to release
thompson-tomo Dec 6, 2025
50a7993
feat: auto version and publish to registry
thompson-tomo Dec 6, 2025
30bdb97
feat: always run release step
thompson-tomo Dec 6, 2025
eda578f
linting
thompson-tomo Dec 6, 2025
2935046
Update release.yml
thompson-tomo Dec 6, 2025
e42c18b
Simplify npm publish command in release workflow
thompson-tomo Dec 8, 2025
dc354bf
typo fix
thompson-tomo Dec 26, 2025
07555c5
Update release.yml
thompson-tomo Dec 28, 2025
c379803
Update release.yml
thompson-tomo Dec 28, 2025
a7b934f
Update release.yml
thompson-tomo Dec 28, 2025
3020c35
Update release.yml
thompson-tomo Jan 14, 2026
9100857
Enhance release workflow with issue creation on failure
thompson-tomo Jan 29, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
42 changes: 42 additions & 0 deletions .github/workflows/release.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,42 @@
# config borrowed from: https://docs.npmjs.com/trusted-publishers#github-actions-configuration
name: Release package

on:
push:
tags:
- "v*.*.*"

permissions:
id-token: write # Required for OIDC
contents: write

jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v6

- name: Use Node.js 22.x
uses: actions/setup-node@v6
with:
node-version: 22.x
cache: 'npm'

- run: npm version ${{ github.ref_name }} --no-git-tag-version

- run: npm install

- run: npm test

- run: npm pack

- run: npm publish

- name: Release
if: ${{ always() }}
Copy link

Copilot AI Dec 28, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using always() condition means the release will be created even if npm tests fail or npm publish fails. This could result in GitHub releases for code that failed testing or wasn't successfully published to npm. Consider using if: success() instead to only create releases when all previous steps succeed.

Suggested change
if: ${{ always() }}
if: ${{ success() }}

Copilot uses AI. Check for mistakes.
Copy link
Contributor Author

@thompson-tomo thompson-tomo Dec 28, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree this should ideally be changed but will wait for after trusted publishing has been confirmed as we want for the time being that if npm upload fails the artifact's is still on the github release.

Copy link
Collaborator

@AndrewSouthpaw AndrewSouthpaw Jan 29, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good. Trusted publishing is confirmed.

Copy link
Contributor Author

@thompson-tomo thompson-tomo Jan 29, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great @AndrewSouthpaw now it is just a matter of the housekeeping tasks ie creating the missing tag and generating release notes. See pr body for details.

uses: softprops/action-gh-release@v2
with:
generate_release_notes: true
files: |
./doctoc-*.tgz
4 changes: 2 additions & 2 deletions package-lock.json
View file
Open in desktop

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

2 changes: 1 addition & 1 deletion package.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@
"author": "Thorsten Lorenz <[email protected]> (thlorenz.com)",
"name": "doctoc",
"description": "Generates TOC for markdown files of local git repo.",
"version": "2.2.0",
"version": "0.0.0-development",
Copy link
Collaborator

@PeterDaveHello PeterDaveHello Dec 28, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if this is a good idea, as based on my limited experience with Node.js app development, it doesn't appear to be a common practice.

Copy link
Contributor Author

@thompson-tomo thompson-tomo Dec 28, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For me it is better and more efficient to use a clear placeholder value rather than having to either manually maintain the version value or adding more advanced ci pipelines given low volume of releases. Note this value is used purely for informational purposes as the git tag value is used to ensure they are aligned.

Copy link
Collaborator

@AndrewSouthpaw AndrewSouthpaw Jan 14, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't love this either. It's standard practice for the "version" tag to accurately reflect the npm and git tags. Not having that can break standard expectations.

What would it take to include bumping the version tag here?

Copy link
Contributor Author

@thompson-tomo thompson-tomo Jan 14, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is still the case that the package version & git tags all match because at build time the value of the tag is set as the value. This means as a user they see no difference.

The difficulty is if we have the trigger of a release being that a tag is added, how can we get that value to be set in the source code so that it matches. It would mean the tag is 1 commit behind.

The common way to do it would be to raise a pr which bumps the version and when merged the release occurs. That would be a big change for such infrequent releases.

Copy link
Collaborator

@AndrewSouthpaw AndrewSouthpaw Jan 28, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, ok. I'm fine with it then as long as the end result has them match.

I would've gone the route of raising a PR to bump the version anyway, but this is good enough, and as you said the releases aren't that frequent.

Can you add some notes to the release.yml summarizing the tradeoffs and link to this discussion?

Copy link
Contributor Author

@thompson-tomo thompson-tomo Jan 28, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have added some comments and will add them here if happy.

"repository": {
"type": "git",
"url": "git://github.com/thlorenz/doctoc.git"
Expand Down