ci: automated pub.dev release pipeline - #69
Merged
Conversation
Add a version-gated, tag-driven release/publish pipeline: - release.yml: on merge to master, push v<version> tag (via PUB_RELEASE_TOKEN so publish.yml fires) and create a GitHub Release. - publish.yml: on v* tag, publish to pub.dev via the official dart-lang reusable workflow (OIDC, validated, no --force). - version-check.yml: PR gate requiring pubspec version to exceed the highest released version (pub.dev + tags) and a matching CHANGELOG entry. - web.yml: keep the Pages demo deploy resilient by not failing on info/style lints and grant contents: write for the gh-pages push. - CHANGELOG.md: add a 3.1.1 entry for this release.
github-actions
Bot
added
documentation
📝 WalkthroughWalkthroughThis PR introduces an automated pub.dev release pipeline: a new tag-triggered publish workflow, a rewritten release workflow with conditional tag push/release creation, stricter version-check logic against actual released versions plus a CHANGELOG requirement, minor web workflow permission/lint changes, and a corresponding changelog entry. ChangesAutomated pub.dev release pipeline
Estimated code review effort: 3 (Moderate) | ~25 minutes Sequence Diagram(s)sequenceDiagram
participant ReleaseJob
participant GitRemote
participant GitHubRelease
participant PublishWorkflow
ReleaseJob->>ReleaseJob: derive tag=v<version>
ReleaseJob->>GitRemote: check if tag exists
alt tag does not exist
ReleaseJob->>GitRemote: push tag using PUB_RELEASE_TOKEN
GitRemote->>PublishWorkflow: trigger on tag push
ReleaseJob->>GitHubRelease: gh release create (created=true)
else tag exists
ReleaseJob->>ReleaseJob: skip tag push (created=false)
end
Related issues: None specified. Related PRs: None specified. Suggested labels: ci, github-actions, release Suggested reviewers: nixrajput PoemA rabbit taps the tag with care, 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (3)
.github/workflows/release.yml (1)
46-50: 🩺 Stability & Availability | 🔵 Trivial | ⚡ Quick winExistence check can misbehave under
pipefail.GitHub's default shell runs with
-eo pipefail. In thegit ls-remote ... | grep -q .pipeline, a transientls-remotefailure (orgrep -qclosing the pipe early) can yield a non-zero pipeline status, evaluating the condition as "tag absent" and proceeding to create/push. A command-substitution test is more robust here.♻️ Suggested robustness tweak
- if git ls-remote --tags origin "refs/tags/$TAG" | grep -q .; then + if [ -n "$(git ls-remote --tags origin "refs/tags/$TAG")" ]; then🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/release.yml around lines 46 - 50, The tag existence check in the release workflow can give a false “tag absent” result under pipefail in the existing `git ls-remote ... | grep -q .` guard. Update the conditional in the release job to use a command-substitution-based check instead of a pipeline, and keep the surrounding logic that sets `created=false` and exits early when the tag already exists. Refer to the existing tag creation block around the `git ls-remote` check in the workflow..github/workflows/version-check.yml (2)
37-41: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick winpub.dev fetch treats all curl failures as "unpublished".
Any
curlfailure (timeout, DNS issue, rate limiting) — not just a genuine 404 for a brand-new package — silently falls back topubdev=0.0.0. This weakens the gate's accuracy during transient pub.dev/network issues, though the eventualdart pub publishstep would still reject a duplicate/non-incrementing version as a safety net.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/version-check.yml around lines 37 - 41, The version-check step is treating every pub.dev fetch failure as if the package were unpublished, which can mask real network or API problems. Update the pub.dev lookup in the version-check workflow so only a genuine 404/new-package case falls back to 0.0.0, and let other curl failures surface or fail the check instead of silently using the fallback. Keep the logic localized around the pubdev retrieval in the version-check job.
81-88: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick winCHANGELOG check doesn't verify the match is a heading.
The whole-token regex correctly avoids matching
3.1.1as a substring of3.1.10, but it will match the version string anywhere in the file — e.g. an unrelated SDK constraint likesdk: '>=3.1.1 <4.0.0'would satisfy this check even without a real changelog entry for the release.♻️ Proposed tightening (anchor to a heading line)
- if grep -qE "(^|[^0-9.])${PR//./\\.}([^0-9.]|$)" CHANGELOG.md; then + if grep -qE "^##+[[:space:]]*\[?${PR//./\\.}\]?([^0-9.]|$)" CHANGELOG.md; then🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/version-check.yml around lines 81 - 88, The CHANGELOG validation in the version-check workflow only checks for a whole-token version match anywhere in CHANGELOG.md, so unrelated text can satisfy it. Tighten the grep in the version-check job so it only matches actual changelog headings for the release, using the existing PR version variable and the CHANGELOG.md check block; anchor the pattern to heading syntax like the "## $PR" entry mentioned in the error message, while still avoiding substring matches such as 3.1.1 inside 3.1.10.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/publish.yml:
- Around line 3-6: The workflow documentation in the publish job references the
wrong secret name for tag creation; update the comment in the publish workflow
to match the actual secret used by release automation. Use the existing
publish/tag trigger context in the workflow and align the wording with the token
name referenced by release generation so setup instructions are consistent.
In @.github/workflows/version-check.yml:
- Around line 43-46: The tag lookup pipeline in the version-check workflow can
both fail the step and select peeled annotated-tag entries as the “highest” tag.
Update the git tag extraction around the tag assignment to use only real tag
refs from git ls-remote (so peeled `^{}` entries are excluded), make the version
match end-anchored in the grep used before sort -V, and ensure the no-match case
does not trip bash pipefail/errexit so the existing `tag=${tag:-0.0.0}` fallback
in the version-check logic can still run.
---
Nitpick comments:
In @.github/workflows/release.yml:
- Around line 46-50: The tag existence check in the release workflow can give a
false “tag absent” result under pipefail in the existing `git ls-remote ... |
grep -q .` guard. Update the conditional in the release job to use a
command-substitution-based check instead of a pipeline, and keep the surrounding
logic that sets `created=false` and exits early when the tag already exists.
Refer to the existing tag creation block around the `git ls-remote` check in the
workflow.
In @.github/workflows/version-check.yml:
- Around line 37-41: The version-check step is treating every pub.dev fetch
failure as if the package were unpublished, which can mask real network or API
problems. Update the pub.dev lookup in the version-check workflow so only a
genuine 404/new-package case falls back to 0.0.0, and let other curl failures
surface or fail the check instead of silently using the fallback. Keep the logic
localized around the pubdev retrieval in the version-check job.
- Around line 81-88: The CHANGELOG validation in the version-check workflow only
checks for a whole-token version match anywhere in CHANGELOG.md, so unrelated
text can satisfy it. Tighten the grep in the version-check job so it only
matches actual changelog headings for the release, using the existing PR version
variable and the CHANGELOG.md check block; anchor the pattern to heading syntax
like the "## $PR" entry mentioned in the error message, while still avoiding
substring matches such as 3.1.1 inside 3.1.10.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: bb5b7124-635b-43f1-8f70-c4691ffeaf37
📒 Files selected for processing (5)
.github/workflows/publish.yml.github/workflows/release.yml.github/workflows/version-check.yml.github/workflows/web.ymlCHANGELOG.md
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.
Adds a version-gated, tag-driven release and publish pipeline to pub.dev.
What changed
master, push thev<version>tag (viaPUB_RELEASE_TOKENsopublish.ymlfires) and create a GitHub Release.v*tag push, publish to pub.dev using the officialdart-lang/setup-dartreusable workflow (OIDC, validated, no--force).CHANGELOG.mdentry.flutter analyze --no-fatal-infos --no-fatal-warningsandcontents: writefor the gh-pages push. Repo-specificbaseHref: /flutter_carousel_widget/,workingDir: example, andflutter-version: 3.24.xpreserved.3.1.1entry for this release.Version
Master pubspec is
3.1.1; pub.dev latest and highest tag are3.1.0, nov3.1.1tag exists, so3.1.1is unreleased and shippable - kept as-is.Summary by CodeRabbit
New Features
Bug Fixes