Skip to content

Instantly share code, notes, and snippets.

@clarkbw
Last active May 15, 2024 06:19
Show Gist options
  • Save clarkbw/1ccae701bf3d2e34dbd829d34a70767e to your computer and use it in GitHub Desktop.
Save clarkbw/1ccae701bf3d2e34dbd829d34a70767e to your computer and use it in GitHub Desktop.
Ideal GitHub Action for Fly preview w/ Neon database
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 }}
@clarkbw
Copy link
Author

clarkbw commented May 7, 2024

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

@duskpoet
Copy link

duskpoet commented May 9, 2024

How would it be possible to achieve that?

@clarkbw
Copy link
Author

clarkbw commented May 9, 2024

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

@clarkbw
Copy link
Author

clarkbw commented May 9, 2024

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.

@duskpoet
Copy link

Ok, nice, got it, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment