I am trying to build & deploy a forge app from a bitbucket pipeline and I notice that there is no --non-interactive flag on the forge install command. So, even though I pass through the --site, --environment, --product, --confirm-scopes, and --upgrade flags the install command still prompts me for confirmation.
I realize that the install is only needed in certain circumstances like new changes in scopes however I want the CI environment to be as automated as possible so I am simply always doing an upgrade install as part of the process.
Shouldn’t the install support the --non-interactive flag as well? Is there a better way to handle this?
The install command has been designed to be non-interactive, with all the available flags you have listed.
Would you be able to send through the exact command you are using, and the response from the CLI?
Edit: I think we’ve been able to reproduce with the --upgrade flag. This looks like unexpected behaviour and I will create a ticket for the team to fix this issue!
Great. Thanks @kchan for checking it out. I would actually like to see the --upgrade option also perform the initial install if it has not been done yet. The reason for this is that it would simplify execution of our CI pipelines. Currently we need to manually install the application on the CI test machines first so that the upgrade operation will succeed. This is a bit of a pain whenever we target a new site for deployment.
Thanks for the feedback, I’ll pass that onto the rest of the team.
In the meantime, is it possible to write a script which determines what error the --upgrade command failed with, and if it is not installed yet then run it without --upgrade?
Hi @kchan, I saw that the –non-interactive flag is now available on the install --upgrade command. Thanks for that! Unfortunately I still find install --upgrade to be rather frail. As mentioned previously, if the app is not already installed the command fails. In addition, if the app is already installed at the latest level it also fails. This means we’ve got to test for both of these error conditions in the CI script and code around it. It complicates install for every app developer. A non interactive install that installs the app to the latest version whether present or not (at current level or not) would be much nicer. Barring that, a way to do a delete --non-interactive would be a good alternative so we could always just do a fresh install.
Thanks for the feedback @jeffryan. I’ll make sure the team is aware of it.
The behaviour the CLI currently has assumes that if your app is at the latest version, there is no need to re-install or upgrade the app, which is why it fails. Could you shed some light as to why you want to re-install it instead?
The CLI’s behaviour also assumes that when it is used in CI, it knows when the app is installed or not, and therefore whether it needs the --upgrade flag or not. Could you also elaborate for us your use case for needing the behaviour you’ve requested?
It boils down to repeatability and resilience of the deploy pipeline. My goal is to get the latest version of the app onto that test system so I can run integration tests against it. If the app is already present on the test system I want it updated to its latest level. This is the normal case as the pipeline is running on a code checkin… However sometimes build steps are run manually and in this case the code might not have changed. I don’t want the deploy to fail just because the app was already current because that kills the rest of the pipeline which may include things that do need to be rerun.
Also, sometimes people remove apps from the test machine and in that case now the app is not present so it’s no longer an upgrade situation. So now do I need to add checks to my pipeline script determine if the app is present so I can tell if i should be using the upgrade option?
I just want be sure the app to be present at its latest level once the install step is done… I don’t care about the previous state of the app was and I don’t want to do a lot of work to figure it out. Does npm install fail when everything is already current? no… it just figures out what needs updating (if anything) and it just works. Thats how I’d like the forge install to work too. And if it can’t then please give us a delete --non-interactive that cleanly deletes the app no matter what level its at or if it is actually present or not. Then we can reliably install the app from scratch every time and avoid all the guesswork.