Repository navigation
Fail headless fly launch when there is nothing to build - #5297
Conversation
In a directory with no Dockerfile and no runtime or framework a scanner recognizes, fly launch printed "Continuing with a blank app", created the app, wrote fly.toml, skipped the deploy (a blank app has nothing to deploy) and exited 0 without saying nothing was deployed. A coding agent or CI job running it without a terminal reads that exit 0 as a successful launch. Without a terminal and without --no-deploy, it now fails during source detection, before the app is created: "found nothing to build; add a Dockerfile, or pass --no-deploy to create an empty app". This reuses the check plan propose already makes for blank apps. --no-deploy still creates the empty app, runs with a terminal are unchanged, plan propose keeps its own error, and plan generate is unaffected because it defaults to --no-deploy.
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
--manifest encodes the plan and returns before anything is created or deployed, so the headless nothing-to-build failure only broke `fly launch --manifest > plan.json` for an empty directory.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
…o build --no-create-app creates no app, provisions nothing and doesn't deploy, so like --manifest it can't be mistaken for a launch. Check the canonical flag name: ApplyAliases copies --no-create into it, but not the reverse.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
firstDeploy lets --now override --no-deploy, so that pair asks for a deploy and would again create an empty app and exit 0.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
Launch read only the --no-create alias, and ApplyAliases copies an alias into the canonical flag but not the reverse, so --no-create-app created, provisioned and deployed anyway. Read both names everywhere; plan propose keeps its own --no-create flag. Also tell headless fly launch --now with nothing to build to drop --now: it overrides --no-deploy, so suggesting --no-deploy alone fails again.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
A CI job with a pseudo-TTY still made a blank app and exited 0; launch already treats CI as non-interactive elsewhere (canEnterUi, billing). noCreateApp now follows ApplyAliases: an explicit --no-create-app wins, so --no-create --no-create-app=false creates the app.
|
@codex review |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
setupGitHubActions fetched the uncreated app to mint a token, failing the config-only launch. The workflow files are still written.
|
@codex review |
|
Codex Review: Didn't find any major issues. Can't wait for the next one! Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
tomr-fly
left a comment
tomr-fly
left a comment
There was a problem hiding this comment.
LGTM! The only thing I thought of is whether the flag works for apps like Phoenix too. Do we need to cover those in this as well?
Phoenix (and other scanners) generate secrets such as SECRET_KEY_BASE and set them on the app before fly.toml is written. With no app, that failed the config-only launch. List the secrets to set later instead; generated values aren't printed, any fresh value works.
|
@tomr-fly good question. We maybe interested in it but I haven't checked how CLI behaves when we get a scanner hit. Do framework scanner check if app is deployable somehow? I don't know this part. Can be a follow up if we find any significant issues later. |
This comment was marked as low quality.
This comment was marked as low quality.
Sorry, something went wrong.
8bb99ec to
15d8be7
Compare
Resolve launch.go with the deferred provisioning error reading --no-create-app through noCreateApp (from #5297), and keep the tests from both sides.
2 participants
Change Summary
What and Why:
Without a terminal, in a directory where
fly launchfinds neither a Dockerfile nor a framework, it printed "Continuing with a blank app.", created the app, wrote fly.toml, skipped the deploy and exited 0, with no hint that nothing was deployed. A coding agent takes that exit 0 as a successful launch.Along the way:
fly launch --no-create-appcreated the app anyway. Launch only read the hidden--no-createalias, andApplyAliasescopies an alias into the canonical flag but not the reverse, so the canonical spelling was ignored: the app was created, provisioned and deployed.How:
In that case
fly launchnow fails before creating anything: "found nothing to build; add a Dockerfile, or pass --no-deploy to create an empty app". With--now, which overrides--no-deploy, it says to drop--nowas well.It still continues when nothing would be mistaken for a launch: with a terminal, with
--no-deploy(unless--now), with--manifest(only prints the plan) and with--no-create-app(only writes fly.toml).fly launch plan proposekeeps its existing error.Launch now reads
--no-create-appthrough one helper that also accepts--no-create, everywhere it decides whether to create, provision or deploy.plan proposekeeps its own--no-createflag.TestDetermineSourceInfoNothingToBuildcovers these cases, andTestNoCreateAppcovers both spellings.Related to: superfly/ui-ex#5643
Documentation