Ideal GitHub Action for Fly preview w/ Neon database

preview.yml

name: PR Review
on:
  # Run this workflow on every PR event. Existing review apps will be updated when the PR is updated.
  # Neon branches are created and removed according to PR updates
  pull_request:
    types: [opened, reopened, synchronize, closed]

jobs:
  pr-preview:
    runs-on: ubuntu-latest
    outputs:
      url: ${{ steps.deploy.outputs.url }}
    # Only run one deployment at a time per PR.
    concurrency:
      group: pr-${{ github.event.number }}

    environment:
      name: review
      url: ${{ steps.deploy.outputs.url }}

    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4

      - run: npm install

      # exports DATABASE_URL to use in next steps
      - uses: neondatabase/pr-review-branch@v1

      - run: npm run db:migrate

      - id: deploy
        uses: superfly/fly-pr-review-apps@1.2.0
        with:
          secrets: DATABASE_URL=${{ env.DATABASE_URL }}
        env:
          FLY_API_TOKEN: ${{ secrets.FLY_API_TOKEN }}

This creates a single (no longer do you need a delete-database action) action to manage the lifecycle of Fly and Neon previews.

How would it be possible to achieve that?

By listening to all the PR events and running different options within the action.

  pull_request:
    types: [opened, reopened, synchronize, closed]

You can then create a branch on open and then delete a branch on close. The cleanup preview is simply listing for a single [closed] event and deleting a branch.

I think it works out like this:

• opened = create
• closed = delete
• synchronize = noop?
• reopened = create

As for the inputs...

There are two core ones required:

• NEON_PROJECT_ID should come from the GitHub App
• NEON_API_KEY should also come from the GitHub App
  • For this one, initially we want it loaded into secrets and so it'll need to be passed as an input
  • But eventually you could create more ephemeral API keys and then inject them into the environment without worry
    • The API key only needs to live for the duration of the PR anyway

I think we can make assumptions about all the other inputs. (1 database, 1 role) And if it's more complex we complain and ask people to add the necessary inputs to let us know which role and which database etc.

Ok, nice, got it, thanks!