Feature/fix tag - #22
Merged
Merged
Conversation
Releases were automatic. Every push ran tagtest, which read the version out
of pubspec.yaml and pushed `release-<version>` (master) or `beta-<version>`
(any other branch); the matching entrypoint then deployed GitHub Pages and/or
Google Play. That left no way to hold a release back - merging was releasing -
and the Play half is no longer wanted at all.
Now a release is a tag you cut yourself:
bump version: in pubspec.yaml, commit, then
git tag v1.6.12 && git push origin v1.6.12
The new release.yml is the only thing that deploys, and its first step
settles the pubspec question by refusing the mismatch: the tag must be
v<X.Y.Z> and must equal `version:` in pubspec.yaml, or the run fails before
anything is built. The build then takes its name from the tag and its build
number from the run number, so the version that ships is the version that
was released and no `+build` suffix has to be remembered.
Removed with the Play deployment: the AAB build, the keystore and service
account decoding, the Gradle cache, flutter_launcher_icons (its config is
android/ios only, so the web bundle never needed it), the publish-android
and google-play-track inputs, and the beta caller that existed to feed the
Play internal track. tagtest's other job - coverage - moves to test.yaml,
which now also runs on pushes to master so the master badge stays live.
android/, ios/ and scripts/generate_build_config.sh are untouched, so a
native target can come back later as its own job without resurrecting any of
this.
Verified: actionlint 1.7.12 clean over .github/workflows; the tag/pubspec
check was exercised as extracted from the workflow against a matching tag, a
mismatch, `+build` and `-beta` suffixes, an unreadable pubspec, an
indented dependency `version:` key, and tags carrying shell metacharacters.
…bspec Two changes to how a release is made, both aimed at the same friction: the version used to need hand-keeping. The trigger is now `on: release` (types: [published]) instead of a tag push. Publishing a GitHub Release - `gh release create v1.6.12 --generate-notes` - is the whole release. `edited` is deliberately left out so that fixing a typo in the notes of something already shipped cannot silently redeploy it, and a draft release stays inert until it is published. A tag pushed on its own no longer deploys either: the release is the event, the tag is where the version comes from. The version now flows tag -> pubspec.yaml rather than pubspec.yaml -> tag. Instead of failing the run when the file disagrees with the tag, the job stamps the tag's version into pubspec.yaml in its own checkout before resolving or building, and prints a notice naming both values when they differed. Releasing stops being two actions that can be done in the wrong order, and a stale pubspec can no longer reach production because the tag overwrites it. The stamp is build-tree only and nothing is pushed back, which is the part worth arguing with. A bump committed by the release job would land on the branch as a commit that is not inside the release it just cut - the tag points at the commit before it - so it relocates the drift instead of removing it, at the cost of a contents: write credential and a push that can conflict. The job therefore runs contents: read. The rewrite is anchored at column 0 so an indented `version:` under a dependency is never touched, inserts after `name:` when the key is missing entirely, and re-reads the file to confirm it now says what it should - a substitution that silently did nothing is exactly the failure that would ship the wrong version. Resolution moved behind the stamp so the single `pub get` this run performs sees the final file. A manual `workflow_dispatch` with a `tag` input was added alongside: a published release cannot be re-published, so without it a runner hiccup has no clean retry. That is why the tag is resolved before checkout rather than taken from the event ref. Verified: actionlint 1.7.12 clean; resolve and stamp run as extracted from the workflow across 19 cases - release vs dispatch tag precedence, empty tag, v1.6 / -beta / +build / latest / release-1.6.11 rejected, tags carrying `;rm -rf /` and `$(id)` refused, the repo's own pubspec stamped and re-parsed, a pubspec with no `version:` key inserted after `name:`, one with neither `version:` nor `name:` failing loudly, dependency-level `version:` left alone, comment lines preserved 34 -> 34, and a second stamp byte-exact.
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.
No description provided.