New machines being created on each push

[tylerhunt]

Each push to the PR is causing new Fly machines to be spun up and the old ones are never destroyed.

This shows a PR that has had 3 pushes. The expected behavior is to only have one app and one worker machine.

[tekknolagi]

I just hit this and only found out when my CI failed because I couldn't create any more machines. It would be cool if there was a way to create ephemeral machines, or automatically tear down on the PR closing.

[tekknolagi]

I fixed the lingering machines after PR close by manually destroying apps:

name: Deploy preview on fly.io

on:
  pull_request:
    branches: [ main ]
    types: [opened, reopened, edited, synchronize, closed]

jobs:
  staging_app:
    if: ${{ github.event.action != 'closed' }}
    runs-on: ubuntu-latest
    steps:
      # ...

  clean_up_app:
    if: ${{ github.event.action == 'closed' }}
    runs-on: ubuntu-latest
    steps:
      - name: Install flyctl
        run: curl -L https://fly.io/install.sh | sh
      - name: Clean up app
        run: ~/.fly/bin/flyctl app destroy --yes bernsteinbear-com-pr-${{ github.event.number }}
        env:
          FLY_API_TOKEN: ${{ secrets.FLY_API_TOKEN }}

[tylerhunt]

That functionality (destroying on closed PR) is already handled here when the type is closed:

on:
  pull_request:
    types:
      - closed

The problem described in this issue is that existing machines are not destroyed when pushing new commits to a PR.

[tekknolagi]

Oh wow, very slick. Ignore me then!

[michael-land]

@tylerhunt I'm experiencing the same issue. Do you have a solution or workaround?

[cwalton]

Same issue here.

I brute force fixed it and made a pull request.
#76

[jacobwegner]

For @cwalton and others encountering this issue, I believe I've tracked it down:

• The default input value for region is iad)(region can also be configured via FLY_REGION)
• If your app's primary_region is in a different region than the input value for region (or the default, iad), you will see input similar to:

--regions filter applied, deploying to 0/1 machines
This deployment will:
 * create 1 "app" machine

No machines in group app, launching a new machine

(You should be able to reproduce this by running fly deploy --regions=iad from your local environment, again, assuming that the primary_region is not iad).

IMHO, this seems like a bug with the Fly.io CLI; if there aren't any machines in the region being passed, the deploy should fail.

My suggested fix for users of this GitHub action is to make sure that the region input for this GitHub action is set to the same region as primary_region.

An alternative fix for the maintainers of the GitHub action would be to deprecate / remove the region input altogether and either allow users who understand the behavior to pass --regions or --primary-region using the launch_options input.