Deployments Hanging with Docker on Github Actions

Questions / Help
1

Hey team

We’ve had some great success moving one of our Node+React apps into Docker and onto Fly.io in the last couple of weeks. We’re building the images using the Fly Github action.

Yesterday, we tried moving a second of our Node+React apps onto Fly using a matching Dockerfile and config, and now both apps are having issues hanging during deployment.

We’re seeing this repeatedly in Github actions and are able to replicate it locally using act. Including some logs below, but it seems to hang after Building image with Docker - we’ve let it run for several hours on Github actions without it progressing past this step. Again, until this week we have been able to deploy successfully from Github Actions and we haven’t changed our config/scripts.

Run superfly/flyctl-actions@1.3
  with:
    args: deploy -c fly.staging.toml -r syd --build-arg ADDRESS_API_KEY="***" --build-arg ADDRESS_API_URL="***" --build-arg ADYEN_CLIENT_ENV="***" --build-arg ADYEN_CLIENT_KEY="***" --build-arg BASE_ASSET_URL="***" --build-arg CLIENT_API_URL="***" --build-arg MAPBOX_ACCESS_TOKEN="***" --build-arg ROLLBAR_ACCESS_TOKEN="***" --build-arg ROLLBAR_ENV="***"
  
  env:
    FLY_API_TOKEN: ***
/usr/bin/docker run --name a9e2ad96996b611450296c6998d959c657f_753543 --label 372a9e --workdir /github/workspace --rm -e FLY_API_TOKEN -e INPUT_ARGS -e HOME -e GITHUB_JOB -e GITHUB_REF -e GITHUB_SHA -e GITHUB_REPOSITORY -e GITHUB_REPOSITORY_OWNER -e GITHUB_RUN_ID -e GITHUB_RUN_NUMBER -e GITHUB_RETENTION_DAYS -e GITHUB_RUN_ATTEMPT -e GITHUB_ACTOR -e GITHUB_WORKFLOW -e GITHUB_HEAD_REF -e GITHUB_BASE_REF -e GITHUB_EVENT_NAME -e GITHUB_SERVER_URL -e GITHUB_API_URL -e GITHUB_GRAPHQL_URL -e GITHUB_REF_NAME -e GITHUB_REF_PROTECTED -e GITHUB_REF_TYPE -e GITHUB_WORKSPACE -e GITHUB_ACTION -e GITHUB_EVENT_PATH -e GITHUB_ACTION_REPOSITORY -e GITHUB_ACTION_REF -e GITHUB_PATH -e GITHUB_ENV -e GITHUB_STEP_SUMMARY -e RUNNER_OS -e RUNNER_ARCH -e RUNNER_NAME -e RUNNER_TOOL_CACHE -e RUNNER_TEMP -e RUNNER_WORKSPACE -e ACTIONS_RUNTIME_URL -e ACTIONS_RUNTIME_TOKEN -e ACTIONS_CACHE_URL -e GITHUB_ACTIONS=true -e CI=true -v "/var/run/docker.sock":"/var/run/docker.sock" -v "/home/runner/work/_temp/_github_home":"/github/hom...
==> Verifying app config
--> Verified app config
==> Building image
Waiting for remote builder fly-builder-polished-voice-5162...
Remote builder fly-builder-polished-voice-5162 ready
==> Creating build context
--> Creating build context done
==> Calculating build context size...
--> Finished calculating build context size.
Your build context is 2.2 MB
==> Building image with Docker
--> docker host: 20.10.12 linux x86_64

And it doesn’t make it any further. Results are the same if we include the --remote-only flag on the build. Let me know any suggestions or any other info I can provide!

Cheers

2

Can you try again with the previous flyctl release?

- uses: superfly/flyctl-actions/setup-flyctl@master
  with:
    version: 0.0.308
3

Thanks Michael, that’s worked nicely.

FYI we were using superfly/flyctl-actions@1.3 so I had to break out a second step in our Github Worklow. Including full change for context and if anyone else comes across this in future.

Previous Github action:

steps:
  - uses: actions/checkout@v2
  - uses: superfly/flyctl-actions@1.3
    with:
      args: >
        deploy
        -c fly.staging.toml
        -r syd
        --build-arg <BUILD ARGS OMITTED>

New, working Github action:

steps:
  - uses: actions/checkout@v2
  - uses: superfly/flyctl-actions/setup-flyctl@master
    with:
      version: 0.0.308
  - run: >
      flyctl
      deploy
      -c fly.staging.toml
      -r syd
      --build-arg <BUILD ARGS OMITTED>

Can we expect a fixed version of the flyctl-actions action we were previously using at some point?

4

This was fixed in release 0.0.310. You can use the old action style, but we recommend using setup-flyctl. It will generally be faster than the other one, which uses Docker to run commands.

5

Thanks, Joshua - we are actually seeing the opposite on our project (Node + React), the deployment using superfly/flyctl-actions was taking around 3 minutes, and the new runs using superfly/flyctl-actions/setup-flyctl are taking 9-10 minutes.

Any ideas on what we should look at to speed this up? The steps in our Github actions (both old and new) are as I indicated in my previous reply.

Cheers

6

Can you post the output of the two commands?

Is it possible that one is building with local Docker, and the other using a remote builder? It would be easier to compare if both explicitly use --remote-only. Builds using the local Github docker will be slower if you don’t have layer caching setup. And it’s not set up by default on Github Actions.