Official GitHub Actions patterns for Devflare

Devflare ships four reusable GitHub Actions for the repeatable parts. Use them directly rather than cloning shell logic into every workflow file.

The action source lives in this repository, but the contract is meant to be reused: workspace setup, impact detection, deploy execution, and GitHub feedback are separate on purpose.

Use devflare-setup-workspace once near the start of a job when later steps share the same checkout and dependency install. It installs Bun, restores the Bun cache, and runs the workspace install command from the chosen directory.

This action is intentionally target-agnostic. It prepares the workspace; it never decides what to deploy.

Use devflare-deploy-impact before any Cloudflare work. It compares the target package against the relevant git range and tells the workflow whether a deploy is actually needed.

Call it once per deployment target. In multi-package preview families, that means one impact decision per worker or app, not one giant yes-or-no for the whole job.

Use devflare-deploy for the actual Devflare deploy step. It can prepare Bun and dependencies for a standalone job, or it can reuse shared setup from an earlier devflare-setup-workspace step.

The action requires one explicit target. Use production: 'true' for --prod, or preview-scope: <name> for --preview <name>. working-directory selects which package-local devflare.config.ts and scripts are in play.

Its outputs are the hand-off point for the rest of the workflow: preview-url, version-id, verification-note, status, failure-stage, exit-code, and log-excerpt are all meant for later verification and GitHub feedback.

Use devflare-github-feedback to publish the result after deploy and verification have already been decided. It can update a PR comment, a GitHub deployment record, or both.

Keeping feedback separate from deploy execution matters. You can retry reporting, mark cleanup inactive, or change comment grouping without touching the Cloudflare deploy mechanics.

The repository currently demonstrates three workflow files and six supported lane types. You do not need to collapse them into one mega-workflow to be “official”; the official part is the clear contract between the workflow lane and the reusable actions.

workspace-ci.yml is the validation lane. It restores Bun and Turborepo caches, installs once, and runs bun run devflare:ci.

It intentionally does not choose a Cloudflare target or request Cloudflare secrets. That keeps repo-wide confidence separate from deploy intent.

Non-default branch pushes get a stable branch-named preview scope in preview.yml. The workflow resolves context once, sets up the workspace once, and then updates only the affected targets for that branch scope.

This is the supported pattern when you want a shareable branch preview that survives multiple pushes and can also coexist with a PR-scoped preview.

Pull requests targeting the default branch get a stable pr-<number> preview scope in the same preview.yml workflow. The workflow can update the branch preview, the PR preview, or both from the same checkout when that branch already belongs to an open PR.

PR preview reporting is grouped into one comment so documentation and testing results update in place instead of spraying the thread with duplicate status noise.

Some applications are really a family of workers. apps/testing is the reference pattern: auth service, search service, and main app deploy separately, but they share one preview scope and one workflow lane.

This is the supported strategy when previews need stronger isolation than same-worker uploads can provide, or when bindings across multiple workers must resolve together.

documentation-production.yml is the reference production lane: resolve impact, perform one explicit production deploy, verify the live site, and then publish a GitHub deployment.

This is the supported split for production automation: let the deploy action handle Cloudflare control-plane verification, then add one live check that proves the currently served app really matches the commit you just shipped.

Cleanup is a supported lifecycle lane, not an afterthought. preview.yml handles branch deletion, PR closure, and manual cleanup dispatches from the same policy surface as preview creation.

Each cleanup job checks out the default branch, reinstalls the shared workspace, runs devflare previews cleanup --scope <name> --apply, and then marks the matching GitHub deployment or PR comment section inactive.