Migrating from v5 to v6

v6 drops the v5 always_on input and makes PullPreview strictly pull-request-centric. If you relied on always_on to keep a branch continuously deployed, your workflow needs an update. This guide covers what changed, what to edit, and how to reproduce always-on behavior with a long-lived PR.

What changed

The always_on input has been removed. v6 no longer supports v5 always-on behavior. Instead, the entire lifecycle revolves around pull requests:

• Adding the pullpreview label to a PR creates or updates a preview.
• Pushing to the PR branch redeploys.
• Removing the label destroys the preview.
• Closing or merging the PR destroys the preview.
• Optional schedule runs only clean up dangling deployments.

Importantly, running pullpreview/action@v6 directly on a branch push does not keep that branch deployed. Without a PR number, v6 falls back to branch cleanup and tears the deployment down. See issue #131 ↗ for background.

If you are new to v6, start with Getting started and How it works.

What to update

• Remove the always_on input.
• Do not use push to invoke pullpreview/action@v6 for deployments.
• Keep pull_request events for deploy, update, and destroy.
• Keep schedule only for periodic cleanup.

A typical v6 workflow looks like this:

name: PullPreview
on:
  schedule:
    - cron: "30 */4 * * *"
  pull_request:
    types: [labeled, unlabeled, synchronize, closed, reopened, opened]

jobs:
  deploy:
    if: github.event_name == 'schedule' || github.event.label.name == 'pullpreview' || contains(github.event.pull_request.labels.*.name, 'pullpreview')
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - uses: pullpreview/action@v6

The if: guard is the canonical one: it runs the job for scheduled cleanups, for the labeling event itself, and for any subsequent event on a PR that already carries the pullpreview label. For more patterns, see Workflow examples.

Keeping a long-lived branch preview

If you used always_on to keep main, master, or staging continuously deployed, reproduce that with a long-lived PR that mirrors the branch:

1. Create a dedicated branch such as preview-main.
2. Open a PR from preview-main into your default branch and keep it open.
3. Add your trigger label (pullpreview) to that PR.
4. Sync preview-main from your default branch on every push.

Each mirror push updates the PR head branch, which triggers a pull_request synchronize event, which redeploys the preview in v6. The PR stays open, so the deployment stays up.

Use a separate mirroring workflow for the sync:

name: Sync preview branch
on:
  push:
    branches: [main]

permissions:
  contents: write

jobs:
  sync-preview-branch:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
        with:
          fetch-depth: 0
      - run: |
          git config user.name github-actions[bot]
          git config user.email 41898282+github-actions[bot]@users.noreply.github.com
          git checkout -B preview-main origin/main
          git push --force origin preview-main

Keep this mirroring workflow separate from your PullPreview workflow, and trigger it only from the source branch you want to mirror to avoid loops. For multiple persistent environments, create one long-lived PR branch per environment, and see Multiple environments.

When to stay on v5 temporarily

If your setup depends on branch-based always-on deploys and you cannot move to the PR-based workaround yet, staying on v5 temporarily is a reasonable short-term stopgap. Plan to migrate once you can adopt the long-lived PR pattern above.