- Author
- Parham Hatanian
- Original publication
- LinkedIn · Sep 19
- Local republication
- 2026-10-20T21:54:16.942161Z
Passing tests doesn’t mean your Flutter package is ready to publish.
And publishing to pub.dev isn’t the whole release experience.
While building deeplink_x, I split the release automation into six focused GitHub Actions workflows not to add complexity, but to make each responsibility explicit.
I’ve written an article explaining the architecture, the decisions behind it, and the trade-offs:
🧪 Code quality vs. package readiness
Why tests, static analysis, Pana, and publish dry runs answer different questions.
🔐 Release verification and publishing identity
What a tag-ancestry check actually proves and how OIDC avoids a long-lived pub.dev publishing credential.
🌐 Making the package easier to try
Separate workflows for a live web demo and signed Android APKs, with different triggers and independent outcomes.
There are costs, too: more configuration to maintain, runner time, tool-version drift, and releases where one output succeeds while another fails.
The takeaway isn’t “every package needs six workflows.”
It’s this: a release pipeline should make clear what happened, what was checked, and what remains unproven.
📖 Read the article below for the approach, benefits, and limitations. The implementation is public, so you can explore and adapt it.
You can also try deeplink_x here:
A 👍 on pub.dev is appreciated if you find it useful. And connect with me here to exchange ideas about Flutter, open source, and developer tooling.
What part of your package release process is still manual—and is that intentional?
#flutter #githubactions #cicd #opensource