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 }}

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!