You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
ci: Create a GitHub release on publish and drop the testing branch - #252
Publishing now creates a GitHub release with generated notes, grouped by the conventional-commit prefix of each pull request title.
The testing branch and beta publishing are gone from the workflows.
The README explains how to release and how the notes come about, and AGENTS.md states the pull request title convention. The README's type generation section is corrected too: it named generate-types.js and a develop branch that does not exist.
Why
Publishing put a version on npm and a tag in the repo, but no GitHub release, so there was nowhere to read what changed. There are 66 version tags and no releases.
The testing branch no longer exists and npm has no beta dist-tag, so its triggers, the job condition and the beta publish step were dead.
How
deploy.yml stays in charge: the #patch / #minor / #major markers, OIDC trusted publishing and the bot push are unchanged. One step is added after npm publish, so a release only ever exists for a version that npm accepted.
.github/release.yml groups the notes into Breaking changes, New features, Fixes and Other changes, and leaves out pull requests labeled internal or release.
.github/workflows/label-pr.yml sets that label from the title prefix: feat to feature, fix and perf to fix, a ! to breaking, and build, chore, ci, docs, refactor, style and test to internal. Titles without a prefix get none of these labels and land under Other changes, so outside contributions stay visible. A pull request into production gets release. The labels follow the current title and base branch alone: to move a pull request, retitle it. It uses pull_request_target so forks get a token that can label; it never checks out pull request code.
The release step starts from the previous release rather than the previous tag. A publish that fails after the version bump leaves a tag behind without a release (that happened to v2.7.0, v2.7.1 and v3.1.0), and starting from such a tag would drop its changes from the next notes. It also strips the prefix from each line, since the heading above it already says it.
Released directly, not as a draft: by the time this step runs the version is already on npm, and the pull request into production is where the release gets reviewed.
The next release from the current history, generated by GitHub from this branch's release.yml with the real labels and run through the release step:
## What's Changed### New features* Emit the transaction sequence number with attribute reports by @TedTolboom in #240### Fixes* Share one random-start TSN counter per node by @RobinBol in #235* Only skip responses for global Default Response frames by @RobinBol in #236* Send UNSUP_COMMAND and UNSUPPORTED_CLUSTER in Default Response by @RobinBol in #239* Skip default responses to broadcast frames by @RobinBol in #238* Match pending responses by command, not only by TSN by @RobinBol in #237
The eleven internal pull requests in that range, the Prettier and eslint work among them, are left out. Without release.yml GitHub lists all of them ungrouped.
Before the first release
Create the labels breaking, feature, fix, internal and release.
Label the pull requests merged since v3.8.0, and the open ones, with the same title logic. The labeler only acts on pull requests opened or retitled after it lands, so without this they would all end up under Other changes.
Label the first release pull request into production with release by hand. pull_request_target runs the workflow from the base branch, so the labeler reaches production pull requests only once it is on production itself.
Testing
All workflow YAML parses, and prettier --check and npm run lint are clean.
The labeler script, run as-is from the YAML with a stubbed github and context, against 22 cases: each prefix, a scope, !, a title without a prefix, a label replaced on retitle, a pull request into and out of production, a prefix that disappears, a body-only edit ignored, other labels left alone, and two races between runs on a shared label state.
The release step's run script, unchanged, with gh and git stubbed: the fallback to git describe when there is no release yet, and the prefix strip on real notes and on feat, feat(scope)!, fix(scope) and perf titles.
The grouping with real labels, through GitHub's generate-notes API reading release.yml from this branch: the output above.
Not verifiable without a real pull request or release: the labeler running on GitHub, and gh release create itself.
Publishing put a version on npm and a tag in the repository, but no
GitHub release, so there was nowhere to read what changed.
The deploy job now creates one once npm has accepted the version, from
GitHub's generated notes. It starts from the previous release rather
than the previous tag, because a publish that fails after the version
bump leaves a tag behind without a release, and starting from that tag
would leave its changes out of the next notes.
.github/release.yml groups the notes into breaking changes, new
features, fixes and other changes, and leaves internal work out. The
groups key off labels, which label-pr.yml sets from the conventional
commit prefix of each pull request title: feat, fix and perf, a
breaking marker, and build, chore, ci, docs, refactor, style and test as
internal. Titles without a prefix land under other changes, so outside
contributions stay visible. The release pull request into production is
labeled too and excluded.
The notes keep each pull request title as is, so the prefix is stripped
from every line: the heading above it already says it.
The deploy workflow published betas from a testing branch, and Lint,
Test and Generate TypeScript Types listed it as a trigger. That branch
no longer exists and npm has no beta dist-tag, so the triggers, the job
condition and the beta publish step go. The deploy job now runs on
production only, which also makes the per-step production checks on
Publish and on the release step redundant.
Publish also stops writing package_version to the job environment;
nothing read it.
Adds GitHub releases to the existing npm publishing workflow, with categorized release notes, and removes obsolete testing branch and beta-publishing support.
Changes:
Creates a release after successful npm publication, using the previous release as the notes baseline.
Labels pull requests by title and target branch to group or exclude release-note entries.
Removes testing branch handling from CI and deployment workflows.
File
Description
.github/workflows/test.yml
Removes the testing push trigger.
.github/workflows/lint.yml
Removes the testing push trigger.
.github/workflows/label-pr.yml
Adds automatic release-note labeling.
.github/workflows/generate-types.yml
Removes the obsolete testing branch exclusion.
.github/workflows/deploy.yml
Adds release creation after npm publication and removes beta publishing.
.github/release.yml
Defines release-note categories and excluded labels.
Without an explicit shell, Actions runs a step with bash -e but no
pipefail. When the generate-notes call failed, the Node filter after it
still exited cleanly on empty input, so the step published a release
with empty notes and reported success. That release then became the
starting point for the next release's notes, which lost these changes
too. shell: bash adds pipefail, so the step now stops instead.
The labeler only reacted to title edits, so retargeting a pull request
into or out of production kept its old label: a feature moved into
production was not marked as a release, and one moved out stayed
excluded from the notes. It now also reacts to base branch edits.
A title that lost its conventional prefix kept the label the prefix had
set, so a chore that became a user-facing change stayed hidden. That
label is now removed. Labels a maintainer set by hand on a pull request
without a prefix are still left alone.
The reason will be displayed to describe this comment to others. Learn more.
🔵 Needs a closer look
The first-release fallback and stale labeling events can omit relevant changes from release notes.
No open issues 🎉
2 previously missed issues
In code that hasn't changed since last review
Bootstrap release notes from the last successfully published version
.github/workflows/deploy.yml:132
Until the first GitHub release exists, the nearest-tag fallback can still select a tag from a failed publish. For example, if v3.9.0 is pushed but npm rejects the publish, the next successful publish of v3.9.1 uses v3.9.0 as its baseline and omits those unpublished changes from the notes. Bootstrap from a known successfully published version, such as v3.8.0, rather than the nearest tag.
Refresh PR metadata and serialize label updates before classification
.github/workflows/label-pr.yml:42
The webhook's labels reflect when the event fired, not when this job runs. If a PR opens as chore: and is retitled to feat: before the first job adds a label, both payloads have an empty label list. Even if the jobs then run in order, this script adds both internal and feature without removing internal, so the feature is excluded from release notes. Serialize labeling runs per PR and fetch the current title, base branch and labels inside that job before calculating updates; serialization alone does not refresh the payload.
Until the first GitHub release exists, the release step fell back to
the nearest earlier tag. A publish that fails after the version bump
leaves such a tag behind without an npm version, and this repository
has three of them. For v3.1.1 the fallback picked v3.1.0, an orphan, so
the notes would have left out everything between v3.0.2 and v3.1.0.
The fallback now asks npm for the highest version below the one being
released, which only counts versions that were really published.
The event payload holds the labels as they were when the event fired.
A pull request opened as chore: and retitled to feat: before the first
run finished produced two runs that both saw no labels: the first added
internal, the second added feature without removing internal, and since
internal is excluded from the notes, the feature disappeared from them.
Each run now reads the pull request as it is when the run starts, and
runs for the same pull request are serialized, so a later run sees the
labels an earlier one added.
The README's release section was a single line. It now covers the
master to production pull request with its version marker, why it has
to be merged with a merge commit or a squash merge, what the Deploy
workflow then does, and how the release notes are grouped by the
conventional commit prefix of each pull request title.
A Changelog section near the top points users to the GitHub releases.
The contributing notes mention Prettier and the pull request title
convention, and AGENTS.md states that convention and links to the
release section, since the title now decides where a change appears.
It named scripts/generate-types.js, which is generate-types.mts, and
said types regenerate on pushes to develop, a branch this repository
does not have. The workflow runs on any branch other than production,
for a wider set of paths than listed, and commits back to that branch.
The labeler kept a label set by hand on a pull request without a
conventional prefix, and to tell that apart from one it had set itself,
it worked out the label the previous title implied. When runs overtook
each other that went wrong: a pull request opened as chore: and retitled
twice within one run could keep internal, and with it drop out of the
release notes.
The five managed labels now follow the current title and base branch
and nothing else, so the last run always leaves them right, whichever
runs before it were skipped. A title without a prefix gets none of
them. To move a pull request to another section, retitle it, which is
what the README already said. Other labels are left alone.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
internalTooling, CI or docs, left out of the release notes
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
testingbranch and beta publishing are gone from the workflows.AGENTS.mdstates the pull request title convention. The README's type generation section is corrected too: it namedgenerate-types.jsand adevelopbranch that does not exist.Why
Publishing put a version on npm and a tag in the repo, but no GitHub release, so there was nowhere to read what changed. There are 66 version tags and no releases.
The
testingbranch no longer exists and npm has nobetadist-tag, so its triggers, the job condition and the beta publish step were dead.How
deploy.ymlstays in charge: the#patch/#minor/#majormarkers, OIDC trusted publishing and the bot push are unchanged. One step is added afternpm publish, so a release only ever exists for a version that npm accepted..github/release.ymlgroups the notes into Breaking changes, New features, Fixes and Other changes, and leaves out pull requests labeledinternalorrelease..github/workflows/label-pr.ymlsets that label from the title prefix:feattofeature,fixandperftofix, a!tobreaking, andbuild,chore,ci,docs,refactor,styleandtesttointernal. Titles without a prefix get none of these labels and land under Other changes, so outside contributions stay visible. A pull request intoproductiongetsrelease. The labels follow the current title and base branch alone: to move a pull request, retitle it. It usespull_request_targetso forks get a token that can label; it never checks out pull request code.v2.7.0,v2.7.1andv3.1.0), and starting from such a tag would drop its changes from the next notes. It also strips the prefix from each line, since the heading above it already says it.Released directly, not as a draft: by the time this step runs the version is already on npm, and the pull request into
productionis where the release gets reviewed.The next release from the current history, generated by GitHub from this branch's
release.ymlwith the real labels and run through the release step:The eleven internal pull requests in that range, the Prettier and eslint work among them, are left out. Without
release.ymlGitHub lists all of them ungrouped.Before the first release
breaking,feature,fix,internalandrelease.v3.8.0, and the open ones, with the same title logic. The labeler only acts on pull requests opened or retitled after it lands, so without this they would all end up under Other changes.productionwithreleaseby hand.pull_request_targetruns the workflow from the base branch, so the labeler reachesproductionpull requests only once it is onproductionitself.Testing
prettier --checkandnpm run lintare clean.githubandcontext, against 22 cases: each prefix, a scope,!, a title without a prefix, a label replaced on retitle, a pull request into and out ofproduction, a prefix that disappears, a body-only edit ignored, other labels left alone, and two races between runs on a shared label state.runscript, unchanged, withghandgitstubbed: the fallback togit describewhen there is no release yet, and the prefix strip on real notes and onfeat,feat(scope)!,fix(scope)andperftitles.release.ymlfrom this branch: the output above.gh release createitself.