Dart release workflow - #1820
Draft
spacebear21 wants to merge 6 commits into
Draft
Conversation
Every registry publish job must refuse to push an artifact whose version differs from what the pushed tag calls for. The check was written inline in the NuGet publish job; the upcoming npm, pub.dev, and PyPI publish jobs would each duplicate it. Move the prefix-strip-and-compare into a verify-tag-version composite action taking the tag prefix and the actual packed version. The NuGet job keeps its locate step (exactly one .nupkg, version parsed from the filename) and hands the result to the action. Local actions resolve from the workspace, so the job gains a checkout step it previously avoided; its contents: read permission already covers it.
The annotated, trusted-signature, and ancestor-of-master checks in verify-tag.sh apply to any release tag, not only crate release tags. Move them into verify-tag-hygiene.sh so tag-triggered publishing workflows for language bindings can enforce the same authenticity gate without taking on the crate-specific checks (manifest version, release invariants, sibling crates.io dependencies), which stay in verify-tag.sh. Pure code move; verify-tag.sh behavior is unchanged.
2 tasks
Collaborator
Coverage Report for CI Build 32181107886Warning Build has drifted: This PR's base is out of sync with its target branch, so coverage data may include unrelated changes. Coverage remained the same at 86.718%Details
Uncovered ChangesNo uncovered changes found. Coverage RegressionsNo coverage regressions found. Coverage Stats
💛 - Coveralls |
spacebear21
force-pushed
the
dart-release-workflow
branch
from
August 18, 2026 19:58
9776695 to
33eb6dc
Compare
Publishing ends the same way for every binding: download the packed artifact, generate SHA256SUMS, and attach both to the GitHub release for the pushed tag. Move the job to release-assets.yml as a workflow_call and point the C# github-release job at it. The artifact-pattern input downloads and merges multiple artifacts for workflows that build one per platform. Two behavior notes: the job now runs on ubuntu-26.04 like the rest of the repo instead of ubuntu-latest, and pre-release detection derives from a SemVer hyphen in the tag's version (ignoring + build metadata) instead of matching only -preview and -rc, which classifies all existing tags identically.
The script hardcoded --features dart,_test-utils --profile dev, so every published release shipped bindings declaring test-only APIs whose symbols are absent from consumer builds, a limitation CONTRIBUTING.md called out. Adopt the PAYJOIN_FFI_FEATURES / PAYJOIN_FFI_PROFILE convention the C# generate_bindings.sh already uses: defaults are unchanged for tests, and a release build sets PAYJOIN_FFI_FEATURES= (empty) to emit bindings with no test-only declarations.
Add the tag-gated publishing path to the Dart workflow, following the NuGet flow in csharp.yml adapted to a source-only registry: pub.dev ships Dart source plus the native/ wrapper crate and consumers compile the Rust through hook/build.dart, so there is no artifact to pack, smoke test, or attach to a GitHub release. Every run regenerates the production bindings and validates the archive with a publish dry run (contrib/prepare-publish.sh). The dry run tolerates only the known analyzer warning that generated bindings unavoidably carry; any other validation finding fails the job, since the real publish runs with --force, which would proceed over a new warning. Pushing a payjoin-dart-<version> tag reruns tests and verification at the tagged commit, then publish-pub checks the tag against pubspec.yaml, regenerates the bindings, and publishes through pub.dev automated publishing (OIDC), so no long-lived credential exists anywhere. The job runs in the release environment for a required-reviewer gate. A verify-tag job calls the shared verify-tag-hygiene workflow, so publishing requires a tag that is annotated, signed by a maintainer key in contrib/release/keys/, and an ancestor of master, and a bad tag fails before the release environment asks for approval. CONTRIBUTING.md's releasing section now documents the CI flow, the one-time pub.dev automated-publishing setup, and the manual fallback.
spacebear21
force-pushed
the
dart-release-workflow
branch
from
August 18, 2026 20:13
33eb6dc to
2e513dc
Compare
spacebear21
marked this pull request as ready for review
August 18, 2026 20:21
spacebear21
marked this pull request as draft
August 18, 2026 20:22
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
2 participants
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.
Builds on top of #1819
Add trusted publishing release workflow for Dart bindings.
Co-authored by Claude Fable 5
Pull Request Checklist
Please confirm the following before requesting review:
AI
in the body of this PR.