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

Open
thompson-tomo wants to merge 12 commits into
base: master
Choose a base branch
from
Open

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

Show file tree
Hide file tree
Changes from 8 commits
Commits
Show all changes
12 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
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
37 changes: 37 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,37 @@
name: Release package

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

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

- name: Use Node.js ${{ matrix.node-version }}
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() will create a GitHub release even if tests fail or npm publish fails. Consider using success() or removing the condition to only create releases when the build succeeds.

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

Copilot uses AI. Check for mistakes.
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.

This seems like a valid point, why would we publish the notes when the publish fails?

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.

Because the github release contain the artifact's which could be manually uploaded to npm.

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.

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