Plugin Dev
604eb44127
Replicate the dsh-facet release stack: a Gitea Actions workflow (.gitea/workflows/release.yml) + .gitea/scripts/release.sh read the commit subjects since the last tag, bump package.json, prepend CHANGELOG.md, tag vX.Y.Z and publish the release via API. Agreed install ref is #semver:^0.1.0, and tags are what 'dsh plugin --profile web update' moves to, so the workflow is what makes updates work. Add the release.test.sh suite (43 checks), npm scripts (test:release / release:plan / release:notes), AGENTS.md with the commit conventions, CHANGELOG.md seed, and the README *Releases* rules.
2.8 KiB
Working in this repository
master releases itself. Every push runs .gitea/workflows/release.yml, which
reads the commit subjects since the last tag, bumps package.json, prepends
CHANGELOG.md, tags vX.Y.Z, and publishes the Gitea release with those
subjects as the body.
What this repository ships: a dsh bundle that auto-installs a Playwright
browser (npx playwright install chromium --with-deps, backgrounded when the
browser is missing) and bridges the installed binary onto PATH
(/usr/local/bin/google-chrome-stable + chromium) so dsh-ego-browser finds
it in root/Docker containers without manual env-var or wrapper steps. See
index.js for the mechanism and README.md for the config.
Commit subjects are release input
The subject is both the version decision and the sentence a user reads in the release notes. Write it for that reader:
feat: …— the change adds a capability. Minor bump:0.1.0→0.2.0.feat!: …orfix(x)!: …— the change breaks an existing install. Major bump:0.1.0→1.0.0, and the note lands under Breaking.[major]anywhere in the subject does the same when a!will not fit.fix: …,docs: …, or a plain sentence — everything else. Patch bump:0.1.0→0.1.1.[skip release]— this push publishes nothing.
feat has to be a word, so Fix the feature flag leak is a patch. Only the
subject line is read; the body is not.
Commit as the work lands
Commit each step as soon as it is finished rather than leaving it in the tree until the end. Two reasons, and the second is the one that bites:
- An uncommitted change has no release note at all. The subject is the sentence a user reads, so work that never becomes a commit never becomes a sentence.
- A tree carrying four unrelated changes cannot be split into four honest
subjects after the fact — the reasoning behind each one is only in the
transcript by then, and the range picks its bump from whatever subjects it
ends up with. One
feat:batched in with a handful of fixes is a minor bump for all of them.
Keep a subject to one change and the version follows from it.
A commit here is local. Pushing to master is what releases, so it stays a
separate, deliberate step.
The release job owns the version and the changelog
package.json's version and CHANGELOG.md are the job's to write, derived
from the commits. Pushing to master is the whole trigger — the tag and the
release come with it.
Checking before pushing
npm run release:plan # would this HEAD release? (yes/no)
npm run release:notes # the exact notes it would publish
npm run test:release # the checks behind the bump and the notes
The rules in full — the marker table, first-release behaviour, how prose commits are handled — are in the README under Releases.