Fly PR Review - error during flyctl launch

Trying to use GitHub - superfly/fly-pr-review-apps: Github Action for PR Review Apps on Fly.io to set up automated PR servers.

This line, which does fly launch, is failing before the “Detected a Rails app” message. If I run the same command locally, this is the output I get:

flyctl launch --no-deploy --copy-config --name frdm-pr-820-1 --region sea --org frdm --verbose
An existing fly.toml file was found for app frdm-production
Scanning source code
Detected a Rails app
Creating app in /home/leo/work/v2
We're about to launch your Rails app on Fly.io. Here's what you're getting:

# ...

However when that command is ran on GH Actions, this is the output:

+ flyctl launch --no-deploy --copy-config --name frdm-pr-820-1 --image --region sea --org frdm
[88](https://github.com/.../job/20283474997#step:4:89)An existing fly.toml file was found for app frdm-production
[89](https://github.com/.../job/20283474997#step:4:90)Scanning source code
[90](https://github.com/.../job/20283474997#step:4:91)Error: failure finding bundle executable: exec: "bundle": executable file not found in $PATH

So something is going on between “Scanning source code” and “Detected a Rails app”. flyctl launch blows up before reaching the latter.

Appreciate any support on this. Thanks.

Can you add “gem install bundler” to your action before this point?

I have; still getting the same output though. Here are the job steps:

  steps:
      - name: Checkout code
        uses: actions/checkout@v4
      - name: Install Ruby and gems
        uses: ruby/setup-ruby@v1
        with:
          bundler-cache: true
      - name: Install dependencies
        run: gem install bundler
      - name: Deploy
        id: deploy
        uses: superfly/fly-pr-review-apps@1.2.0
        with:
          secrets: SECRET_KEY_BASE=${{ secrets.PR_PREVIEW_SECRET_KEY_BASE }} HOST_DNS=${{ steps.deploy.outputs.url }} REDIS_URL=${{ secrets.PR_PREVIEW_REDIS_URL }}
          name: frdm-pr-${{ github.event.number }}-1
          postgres: frdm-db-staging
          region: sea # needs to be same region as postgres, redis
          org: frdm
          memory: 512 # prod default is 4G, which we don't need

Output:

Install dependencies
...
14368#step:5:1)Run gem install bundler
14368#step:5:7)Successfully installed bundler-2.5.4
14368#step:5:8)1 gem installed

Deploy
...
An existing fly.toml file was found for app frdm-production
Scanning source code
Error: failure finding bundle executable: exec: "bundle": executable file not found in $PATH

FWIW I added some echos for PATH and which bundle and they seem fine:

PATH=/opt/hostedtoolcache/Ruby/3.2.2/x64/bin:/opt/hostedtoolcache/node/18.19.0/x64/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
bundle=/opt/hostedtoolcache/Ruby/3.2.2/x64/bin/bundle

so I’m guessing something is wrong with the PATH being used here flyctl/scanner/rails.go at 9b3a129926d1a3b8d5f537493b1b25a58144dd8f · superfly/flyctl · GitHub

I think I figured it out.

GitHub - superfly/fly-pr-review-apps: Github Action for PR Review Apps on Fly.io seems to be fundamentally broken. It relies on flyctl launch to create an app and deploy later, but launch is ran in a separate Docker container, not the one used by the Github worflow.

So it doesn’t matter if I add gem install bundler or not in the steps of the action; the fly-pr-review-apps action uses a very slim Dockerfile with basically alpine + the fly.io install script and nothing else. Because that image doesn’t have bundler, fly launch will fail, rendering the rest of the script unusable. I’m using Rails but I suppose this affects all other frameworks.

Easiest workaround for this seems to be passing --dockerfile ./Dockerfile and -y to fly launch, which skips the framework detection thing. I see some people have similar forks already. I can open a PR for this later if needed.

Let me add to that: the functions that the Rails scanner uses bundler for don’t apply to the scenario of a PR review - this isn’t the first time the application was launched, so those steps can be skipped.

I’m exploring modifying the scanner to skip over those steps if bundler can’t be found rather than erroring out.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.