Some flyctl commands do not provide a flag to confirm prompts in advance

[3x071c]

trafficstars

Describe the bug Most flyctl commands provide a flag to skip the warning/confirmation prompt that comes up when running a command with a different --app than that in the fly.toml configuration file, such as --yes. I have found that all flyctl secrets sub-commands do not have this option, making them harder to use in automated environments such as CI.

• Operating system: -
• fly version: v0.0.320

** Command output: **

$ fly secrets set --app <some other app> AUTH_SECRET=$(openssl rand -base64 40) # ...
WARN app flag '<other app>' does not match app name in config file '<current app>'
? Continue using '<other app>' (y/N) ...

[3x071c]

This is harder than I expected. Most ways of simulating user input (by piping echo, possibly in a subshell, or a here docstring) result in fly complaining about an EOF in the input. Is there a temporary workaround for this?

[3x071c]

This appears to be a general problem. I just noticed that fly postgres attach might also prompt you if the database already exists, which I haven't found a way to work around in automation. Why do some commands (deploy, move, etc) accept --yes and others do not?

[jsierles]

The answer here is that each command has developed organically. We haven't put a ton of work into generalizing things like --yes, but it's definitely something we have on the radar when we can devote more resources to flyctl.

[3x071c]

Is there something I can do to make workflow runs like this one work in automated environments for commands that don't provide the requested flags, such as fly postgres detach? As mentioned above, my tries with printf '%s' '...' | fly ..., echo -ne '...' | fly ..., fly ... <<EOF ... EOF have gotten me nowhere. @jsierles

[ignoramous]

See also: https://community.fly.io/t/5417

[jgnieuwhof]

Running into this issue as well. Tried all the same approaches as @3x071c, in addition to yes | flyctl ..., all resulting in the EOF behaviour.

Unfortunately this renders a number of the commands unusable for automated deployments.

[Fenntasy]

See also https://community.fly.io/t/dealing-with-flyctl-interactive-prompt-in-a-ci-environment/7342

flyctl scale count is also problematic

[brev]

Also for flyctl wireguard commands. This is complete blocker for my use case, unfortunately.

[redjonzaci]

@jsierles I could work on this for:

• fly secrets
• fly scale count
• fly wireguard

What other commands do you think we should include?

[jsierles]

We want any command that asks for confirmation to do this. I can't say which anecdotally, so worth digging in code for usage of survey.Confirm prompt.Confirm, confirm etc.

[redjonzaci]

@3x071c as for fly secrets set, the command seems to have changed and I couldn't find that prompt.

[redjonzaci]

@Fenntasy fly scale count now has a --yes flag. It has had it for the past ~5 months.

[redjonzaci]

@brev I couldn't find any prompt in the fly wireguard commands. You can let me know if you still need help related to this issue!

[redjonzaci]

Made an initial implementation, but I have to test tomorrow and get some feedback on the solution. Gotta end the day so as not to ruin the initial implementation by sleeping on my keyboard.

[madhavdutta]

I wanted to share a solution that I've implemented for automating the confirmation prompt during deployment with flyctl and extracting the deployed URL using my REST API. This solution may be useful for cases where you want to automate the deployment process and retrieve information, such as the deployed URL, for further use.

Here's a sample bash code snippet which i called using child_process and regular expressions in my REST API:

echo "y" | flyctl launch --now --copy-config -y --yes

it worked for me, --copy-config bypassed first confirmation and -y --yes bypassed second confirmation for region and config.