Remote machine build failure with Github Actions

Using the instructions from this article, I’m using GHA to execute my deployment. However, I receive an error that looks like some kind of connection issue with the release_command machine:

  Created release_command machine 6e82dd35f03087
  Waiting for 6e82dd35f03087 to have state: started
  Waiting for 6e82dd35f03087 to get exit event
Error release command failed - aborting deployment. error finding the release_command machine 6e82dd35f03087 exit event: error getting machine 6e82dd35f03087 from api: failed to get VM 6e82dd35f03087: Machine not found```

When I run the `flyctl deploy --remote-only` command on my local machine, it works fine. Thoughts?

Hey @dpurrington, thanks for the report. Would you mind sharing the flyctl versions in use (both on GHA and locally)?

Absolutely.

Local: flyctl v0.0.520 linux/amd64 Commit: 6494909a BuildDate: 2023-04-13T20:02:11Z
GHA: flyctl v0.0.521 linux/amd64 Commit: 4523084f BuildDate: 2023-04-14T15:35:03Z (via step: superfly/flyctl-actions/setup-flyctl@master)

I ran again in GHA using the same version (“0.0.520”) and still had the problem.

For completeness, here’s the GHA .yml file contents:

name: Fly Deploy

on:
  push:
    branches:
      - fly

env:
  MIX_ENV: main

jobs:
  deploy:
    runs-on: ubuntu-latest
    defaults:
      run:
        working-directory: ./backend
    steps:
      - uses: actions/checkout@v3
      - uses: superfly/flyctl-actions/setup-flyctl@master
        with:
          version: "0.0.520"
      - run: flyctl version
      - run: flyctl deploy --remote-only
        env:
          FLY_API_TOKEN: ${{ secrets.FLY_API_TOKEN }}

Hey @dpurrington, thanks for all the info! A change went into flyctl recently to improve its handling of release commands that finish very quickly (before flyctl can query their status), but I’m wondering if it’s introduced a new bug.

flyctl v0.0.513 predates that fix. Perhaps downgrading to it temporarily will work? If so, please let me know!

EDIT: one more update: we think this has to do with a record for your machine not getting propagated back to the API gateway fast enough, causing some deploy token code to fail. It might also work if you switch to standard API tokens for now.

1 Like

@dpurrington We just deployed a change that should prevent the issue so please let us know if it’s still happening!

1 Like

Works - thanks so much!

-Dave

2 Likes