Problem Statement:
When using this action with Rails applications (or other framework-based apps) without providing a pre-built image parameter, the deployment fails during the app creation phase.
The action's entrypoint.sh script runs flyctl launch at line 57. When no image is provided, this command attempts to auto-detect the application framework by scanning the source code. For Rails applications, this means looking for a Gemfile and attempting to run bundle to confirm the framework.
However, the action runs inside a minimal container that only includes flyctl and basic tools - it doesn't have for eg: in my case Ruby runtimes installed. This causes the framework detection to fail.
Current Flow:
- Action receives no image parameter
- Attempts
flyctl launch --no-deploy --copy-config --name $app --image --region $region --org $org
- flyctl scans source code and finds Gemfile
- Tries to execute bundle (or npm, pip, etc.) to verify framework
- Fails with:
exec: "bundle": executable file not found in $PATH
This affects any framework that requires language-specific tools for detection for Rails apps requires bundle.
Potential Solutions:
- Add a
--skip-scan or similar flag to flyctl launch when the image parameter is empty, to bypass framework detection.
- Check for Dockerfile presence - if a Dockerfile exists and no image is provided we can launch the app and it will build the image from the dockerfile path.
- Use
flyctl apps create only when image is provided, keeping current flyctl launch behavior for simpler apps that don't need framework detection.
Note: I feel we should document the limitation clearly so users know to provide pre-built images for framework apps.
Suggested enhancement for dockerfile path: #79
Current Workaround:
Adding extra 3 steps
- create the app first
- Build and push the docker image to fly registry
- Use that image
- name: Setup flyctl
uses: superfly/flyctl-actions/setup-flyctl@master
- name: Create Fly app if needed
run: |
flyctl apps create pr-${{ github.event.number }}-some-name --org example-org || echo "App already exists"
env:
FLY_API_TOKEN: ${{ secrets.FLY_API_TOKEN }}
- name: Login to Fly Registry
uses: docker/login-action@v3
with:
registry: registry.fly.io
username: x
password: ${{ secrets.FLY_API_TOKEN }}
- name: Build and push rails image to Fly Registry
run: |
docker build -t registry.fly.io/pr-${{ github.event.number }}-some-name:latest -f Dockerfile .
docker push registry.fly.io/pr-${{ github.event.number }}-some-name:latest
- name: Deploy PR app to Fly.io
id: deploy
uses: superfly/fly-pr-review-apps@1.2.1
with:
image: registry.fly.io/pr-${{ github.event.number }}-some-name
cpu: 1
cpukind: shared
secrets: EXAMPLE_SECRET=${{secrets.EXAMPLE_SECRET}}
Problem Statement:
When using this action with Rails applications (or other framework-based apps) without providing a pre-built image parameter, the deployment fails during the app creation phase.
The action's entrypoint.sh script runs flyctl launch at line 57. When no image is provided, this command attempts to auto-detect the application framework by scanning the source code. For Rails applications, this means looking for a Gemfile and attempting to run bundle to confirm the framework.
However, the action runs inside a minimal container that only includes flyctl and basic tools - it doesn't have for eg: in my case Ruby runtimes installed. This causes the framework detection to fail.
Current Flow:
flyctl launch --no-deploy --copy-config --name $app --image --region $region --org $orgexec: "bundle": executable file not found in $PATHThis affects any framework that requires language-specific tools for detection for Rails apps requires bundle.
Potential Solutions:
--skip-scanor similar flag to flyctl launch when the image parameter is empty, to bypass framework detection.flyctl apps createonly when image is provided, keeping current flyctl launch behavior for simpler apps that don't need framework detection.Note: I feel we should document the limitation clearly so users know to provide pre-built images for framework apps.
Suggested enhancement for dockerfile path: #79
Current Workaround:
Adding extra 3 steps