Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Throwing exception in --no-interaction mode when some params are missing #63

Open
fduch opened this issue Aug 26, 2014 · 4 comments
Open

Comments

@fduch
Copy link

fduch commented Aug 26, 2014

In my build process i am using composer install --no-interaction command to set up the application.
Every application has composer.json file that contains
Incenteev\\ParameterHandler\\ScriptHandler::buildParameters handler set for
post-install-cmd event.

The problem is that if parameters.yml file has some parameters missing ParameterHandler automatically provides default values for them. It's ok for development but not for stage level.
In my case it would be cool if i can tell ParameterHandler somehow to throw an exception in --no-interaction mode if parameters file is not valid in order to explicitly abort the build/deploy of the potentially inconsistent application.

May be it would be reasonable to have some option / environment variable for this use case?

@stof
Copy link
Member

stof commented Aug 26, 2014

The documented behavior is that the values of the dist file are used as default value.

Tis also what we do in interactive mode if you hit enter directly for each question being asked. Note that in recent versions of Symfony Console, the DialogHelper handles non-interactive inputs properly (returning the default directly). With such versions, the check for the interactive mode could be removed from the ParametersHandler with exactly the same behavior: using the default values of the dist file (just slower because it would still iterate to find missing ones).

we cannot add an option to handle it (it would require changing the signature of composer commands, which is not possible). And using an environment variable would be inconsistent with the other configuration which is provided in the composer.json file.

Thus, if your dist file provides sensible defaults, you may not need to overwrite all of them through environment variables in your deployed app (the overwrite might be done locally instead for instance)

@fduch
Copy link
Author

fduch commented Aug 26, 2014

if your dist file provides sensible defaults, you may not need to overwrite all of them through environment variables in your deployed app

No, the problem is a little bit different: i do not want to have silently deployed application using default parameters in case parameters.yml file does not contain all the required params (mainly due to human errors during parameters.yml filling). It is important because my dist file is tracked by vcs and does not contain default's for production stage

@fduch
Copy link
Author

fduch commented Sep 2, 2014

Any thoughts?

I think validation of parameters list from parameters.yml is that ParameterHandler can (and should) do.
But now it performs only half of the work. If ParameterHandler become facility to report validation failure and abort installation process in case of failure it will make possible to use it very wide in build/deploy processes.

@ZeeCoder
Copy link

I have the same problem.
I need deployment to fail if there are missing parameters, instead of it succeeding with default values.

Here's an example for why this is an issue for me.
Imagine, that you didn't need any kind of e-mail handling in the first couple of releases of your application, but in the newest one, you add a contact form, which can send out e-mails.
Now the e-mail configuration depends on the server (The parameters will change whether the application runs locally, in a staging or the production server.), so in this case, when I deploy to a staging or production server, I don't want to deploy with the default values, since that will cause errors in the contact form.
Optionally throwing an error in such case would remind me to add the new server-specific keys to the parameters file.

I think for the time being I will remove the post-* commands on deployment from the composer.json file, and then run a custom symfony command, which only throws an exception if the parameters.yml file misses keys compared to the *dist version.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants