👷 Add workflow to sync Dart SDK pin on PRs - #491
Conversation
Wires up flutter-workflow's new reusable workflow (RubberDuckCrew/flutter-workflow#105, released in v1.3.0) so GitDone's pubspec.yaml/pubspec.lock Dart SDK pin stays in sync with the Flutter version whenever mise.toml, pubspec.yaml or pubspec.lock change in a PR. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MK7vVSoDu3mGJ9jUokXT58
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (1)
Included review availability: This review used your included allowance. Your plan provides up to 1 included review per hour; 0 remain after this review. WalkthroughA new GitHub Actions workflow monitors pull requests that change Dart SDK configuration files. For pull requests from the same repository, it invokes a pinned reusable workflow with the PR head SHA, repository root, and bot credentials. ChangesDart SDK sync
Priority: ⬇️ Low Estimated code review effort: 2 (Simple) | ~8 minutes Change: Feature Merge Risk: ⚪ Minimal · up to The SDK sync workflow is ready to merge after normal checks. Architecture SummaryArchitecture risk: 🔵 Low · up to The changed surface does not map to a changed system, dependency edge, entrypoint, or external dependency. Changed systems: None identified. Architecture concerns Review detailsBefore / after behavior
🚥 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. A rabbit checks the pull request, Comment |
Bootstraps the exact-pin convention the new sync-dart-sdk workflow maintains going forward (it only rewrites this line on PRs that touch mise.toml/pubspec.yaml/pubspec.lock, so the existing range wouldn't have been converted automatically until the next such PR). 3.13.4 is the Dart SDK bundled with Flutter 3.47.5, matching flutter-workflow's test_app. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MK7vVSoDu3mGJ9jUokXT58
Summary
Wires up flutter-workflow's new reusable "Sync Dart SDK" workflow (RubberDuckCrew/flutter-workflow#105, shipped in v1.3.0) for GitDone, mirroring how flutter-workflow's own
test_appuses it..github/workflows/sync-dart-sdk.yml, triggered on PRs that touchmise.toml,pubspec.yamlorpubspec.lock.RubberDuckCrew/flutter-workflow/.github/workflows/workflow-sync-dart-sdk.yml@e94cc10(v1.3.0) withworking-directory: '.'since GitDone'spubspec.yamllives at the repo root (unliketest_app's subdirectory).pubspec.yaml, and pushes a sync commit updating thesdk:pin (+pubspec.lock) when it drifts — same GitHub App token pattern (RUBBERDUCKCREW_BOT_APP_ID/RUBBERDUCKCREW_BOT_APP_PRIVATE_KEY) already used intest-build-release.yml, so the push re-triggers CI.head.repo.full_name == github.repository), since the job needs push access.sdk: ">=3.13.0 <3.14.0"→sdk: 3.13.4(the Dart SDK bundled with Flutter 3.47.5) inpubspec.yaml/pubspec.lock. The workflow only rewrites this line on a PR that touches those files, so without this the existing range would have stayed untouched until the next such PR (e.g. the next Renovate Flutter bump).Test plan
mise.toml's Flutter version (or touchespubspec.yaml/pubspec.lock) and confirm the "Sync Dart SDK" check runs and pushes a sync commit when the pin drifts🤖 Generated with Claude Code
https://claude.ai/code/session_01MK7vVSoDu3mGJ9jUokXT58