Docker app preinit script settings


#1

Hello,
does anybody know if there is a safe way to access the user settings during the installation process at the stage when the preinit script is called?
From the appcenter logs I see that an UCR for my app is created after the preinit script has been called, but I would like to read and modify the user-submitted settings earlier, i.e. I need to access them in the preinit script.
Where are these settings temporarily stored?
Boris


#2

Hi @bheithecker,

yes I had a similar problem/observation in Why is preinst executed before the settings screen? (you also commented there). I feel like the only way to make this possible at the moment is to manually create ucr variables before the app installation.


#3

Hi,
okay, I can create ucr variables before the installation, but I want to do so only in case the installation-user has not set the variable (i.e. if the setting is “optional” and was left empty).
Boris


#4

Yes, this is not possible. The settings are not stored anywhere before the start of the App.

If you wish to use a default value for some setting, maybe it is possible to put this logic into the container (I assume you are talking about a Docker App)?

If you actually have UCR available in your container (i.e., your App uses appbox), you may use this in any script inside the container:

ucr set my/option?my_value_in_case_it_is_not_set_yet

Does this help?


#5

Yes, I have to generate missing settings in a pre-boot script inside the consider. The probleme is that there may be conflicting user settings or user inputs which can’t be processed. For example, one setting is supposed to be a valid host name. If the user has made an invalid input, perhaps inadvertently, all I can do is exit the container with non-zero status code and no meaningful message to the user about why the start-up has failed.
Perhaps in some future UCS version there could be an option to provide a simple javascript for validation of user inputs right in the frontend.


#6

Depending on the App, it may be possible to not stop immediately with a non-zero exit code. Maybe the App can (although incorrectly configured) live long enough to execute the setup script that any App may ship. If this script has a non-zero exit code, the App is removed, too.

The advantage is that setup also gets --error-file, which can be used to give the user a meaningful error message.

This is not as instant as a simple JS validation would be, yet it should work.