Release on merge to main#5
Merged
Merged
Conversation
Publishing needed a version tag, so merging a pull request did nothing: four merges landed and the Release workflow never ran once. Merging now publishes. - push to main triggers a release, filtered to paths that actually affect the bundle — src, scripts, entry document, manifest, lockfile, build config. A README fix must not raise a pull request on the site. - the tag is v<version>-build.<run> and the release is marked prerelease, so hand-cut versions stay visible among the automatic ones. The run number supplies uniqueness because committing a version bump back to main would retrigger the workflow. - releases are pinned to the commit that was built via --target, not to wherever the default branch has moved by the time the job runs. - version bumped to 0.2.0; it had been left at 0.1.0-prototype across four merged pull requests. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Caution The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased. |
YurMil
added a commit
to YurMil/cadautoscript.com
that referenced
this pull request
Jul 22, 2026
The source repository is switching to publishing on every merge to main (YurMil/ws-speech-text#5). A branch per release would then leave a queue of near-identical pull requests here, each superseded by the next before anyone looked at it. One branch, updated in place: it always carries the newest artifact that has not been merged yet. - push with --force rather than --force-with-lease. The branch is rebuilt from main on every run and owned by the workflow, and a freshly created local branch has no remote-tracking ref, so --force-with-lease would fail outright. - the pull request title is updated as well as the body, since the open request now stands for whichever release is newest rather than the one that opened it. Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Publishing required a version tag, so merging a pull request did nothing: #1–#4 all landed and the Release workflow never ran once. That is why the site is still serving a build from before #4 — no large models, none of the transcript fixes.
Merging now publishes.
What triggers a release
A push to
mainthat touches the application:src/,scripts/,index.html,package.json,pnpm-lock.yaml,vite.config.ts,tsconfig*.json.Deliberately not everything. Without the path filter every README or workflow edit would run the full chain and raise another pull request on the site — the noise problem that made me argue for tags in the first place. This keeps the convenience and removes the noise.
How builds are versioned
Automatic builds are tagged
v<version>-build.<run>and marked as prereleases, so hand-cut versions stay easy to spot among them. The run number supplies uniqueness rather than a version bump committed back tomain— writing tomainfrom the workflow would retrigger the workflow.Explicit tags still work for named versions:
git tag v0.3.0 && git push origin v0.3.0Releases are pinned with
--target "$GITHUB_SHA"to the commit that was actually built, instead of wherever the default branch has moved by the time the job runs.Companion change
YurMil/cadautoscript.com switches the sync to a rolling
chore/whisper-transcriber-syncbranch, so successive releases update one pull request instead of queueing up as separate ones. Merge that first, or the first few auto-releases will each open their own.Housekeeping
Version bumped
0.1.0-prototype→0.2.0. It had not moved across four merged pull requests, and the tag must mean something.What happens when this merges
This pull request touches
package.json, so merging it is itself the first release —v0.2.0-build.<n>— which carries the larger models and the transcript fixes from #4 to the site as a reviewable pull request.pnpm testpasses (12 tests); the workflow YAML parses.🤖 Generated with Claude Code