ci: publish to pub.dev automatically on version tags - #39
Open
theashraf wants to merge 1 commit into
Open
Conversation
Adds a tag-triggered workflow that publishes the package to pub.dev via
the official dart-lang/setup-dart reusable workflow. Authentication uses a
short-lived OIDC token minted per run, so there is no secret to store or
rotate; pub.dev only honours that token for tag-triggered runs, which is
why the trigger cannot be workflow_dispatch or release.
Requires a package admin to enable Automated publishing on pub.dev for
LottieFiles/dotlottie-flutter with tag pattern v{{version}}.
|
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 currently requires someone to hold pub.dev credentials locally and run
flutter pub publishby hand. This replaces that with a tag-triggered workflow.Push a
vX.Y.Ztag → the package publishes. That's the whole flow.There is no token to create
Worth stating up front, because it changes what we ask for: pub.dev automated publishing uses short-lived OIDC tokens minted per run, not a stored secret. Nothing to put in repo secrets, nothing to rotate, nothing to leak.
The trigger has to stay
push: tags— pub.dev only honours the OIDC token for tag-triggered runs, soworkflow_dispatchandreleasewould both fail auth. That constraint is commented in the file so nobody "simplifies" it later.One-time setup on pub.dev
pub.dev →
dotlottie_flutter→ Admin tab → Automated publishing → enable publishing from GitHub Actions:LottieFiles/dotlottie-flutterv{{version}}The package is under the
lottiefiles.comverified publisher, so this needs an admin of that publisher.Why the official reusable workflow
dart-lang/setup-dart/.github/workflows/publish.yml@v1is what dart.dev recommends, and it matters here that it sets up the Flutter SDK, not just Dart — this package hassdk: flutterdependencies, so a plaindart pub getwould fail version solving. The reusable workflow's inner actions are already SHA-pinned upstream. It runs a dry-run before publishing.Deliberately not included: automated version bumps
Considered
changesets, but it's@changesets/cli— npm-ecosystem, and adopting it means a Node toolchain in a Dart repo purely to manage a CHANGELOG. The Dart-native analogue isrelease-pleasewithrelease-type: dart, which bumpspubspec.yamland updatesCHANGELOG.mdfrom our conventional commits (we already writefix:/feat:/chore:).It's left for a follow-up because of a chaining problem worth solving on its own: GitHub does not trigger workflow runs from events created with the default
GITHUB_TOKEN, so a tag pushed by release-please would not fire this workflow. Fixing that needs a PAT — reintroducing exactly the long-lived secret OIDC just removed. Open question for that follow-up: whether pub.dev will authorise a run triggered by release-please's tag at all.Version bumps stay manual for now; everything after the tag is automated.
This does not apply retroactively to v0.1.6
Workflows for a
push: tagsevent are read from the tagged commit's tree, not from the default branch.v0.1.6points at826c8db, which predates this file, so that tag cannot be published by this workflow — re-pushing it would fire nothing.0.1.6was therefore published manually. This pipeline takes effect from the next version tag.(This is also why the trigger is commented as load-bearing: the workflow must exist in the commit being tagged.)