support configurable quickstarter provisioning

[cschweikert]

This is about providing a configuration possibility during provisioning of a quickstarter with the provisioning app:

• a quickstarter can provide some kind of schema file with possible config parameters each consisting e.g. of key/name and short description
• provisioning app shows depending on this schema file additional elements with key and description
• a quickstarter provisioning can then act depending on the user input

[rattermeyer]

interesting idea. but currently, i see no possibility. it might be worth considering this option when adressing opendevstack/ods-project-quickstarters#68

[ManuelFeller]

/subscribe ;-)

This could be helpful to give users some freedom how to set up their Ionic project (Cordova/Capacitor, Angular/React/VueJS, ...) and maybe also some other configuration topics.

Let's gather the use cases here to come up with implementation possibilities.

[ManuelFeller]

Idea / suggestion to discuss:

We add another field to the context object (that already contains .projectId, .componentId and .group) named .userParams. In there we pass a string that contains key/value pairs. It has to be generated by the provisioning app, passed by the context object and then processed by the init.sh (or maybe even in the Jenkinsfile that executes the creation of the project).

To make sure that the provisioning app does not pass invalid / unknown keys and values as well as nice usability we could define a userParams.conf file containing the available parameters. Presence of the file could indicate that the Quickstarter has user parameters; if it is not present indicates that there is no support for that

And maybe we could also include value-types or possible values to allow the correct input fields to be displayed in the provisioning app.

Suggestion for the stringified parameter: [key1:'value1',key2:'value2']

Suggestion for the file content:

key1 string
key2 number
keyN select:'value a','value b','value c'

What are your thoughts? Do we need the encapsulation via 'value a'or can we skip that? I included that since we may have numerical values that contain that char. We could go for ; instead of , though...

[cschweikert]

I like the idea :) What I'm not so sure of is the way the userParams parameter can be stored and made accessible on the context object during both situations: provisioning and building Does anybody know, how this can be baked into the context? I guess it will touch https://github.com/opendevstack/ods-jenkins-shared-library/blob/master/src/org/ods/component/Context.groovy, right?

[michaelsauter]

Cool, nice suggestion! Do we actually need it during building? I think during provisioning is easy - during building is way harder. There one would need to write those params into a file in the repo or so, in order to surface them again in subsequent runs.

[ManuelFeller]

I would focus on the provisioning - since we could then allow customisation of cli-tools that set up things (e.g. using Angular or React in Ionic). And if I understand the original request that was also the intention, not for build time.

At least I have no use cases during build time; until now I could solve things like using a specific config or similar things with specialised branches and / or environments...

[michaelsauter]

Yep, I think focusing on just provisioning makes sense for me. Also, as you mention, the provision job can do anything, so it can write the params somewhere where the build jobs collects them again.

As to your proposal, I have two comments that I think we need to explore:

1. the available quickstarters are read from a ConfigMap, see https://github.com/opendevstack/ods-core/blob/master/ods-provisioning-app/ocp-config/cm.yml#L273. There is nothing reading the actual repository at that stage. It doesn't seem ideal to me to define the params in the ConfigMap, as that just duplicates work and is error-prone. Would that mean we would need to read the repo to collect available params? Hmm ... something to think about.

2. Maybe we can re-use an existing format to define params. There are already schema definition options for XML/JSON ... most of them would probably be overkill, but it would be nice to use sth that already exists is possible ... what do you think?

[ManuelFeller]

I will look a bit more into the way to define the params - the file was just a first thought, will check this a bit more in detail. Thanks for the hint where the ConfigMap is currently coming from.

Regarding the format: I am happy to use something existing (especially JSON could be nice since the available params file / definition will mostly be used by the provisioning app) - but since we are not sure where to store that definition yet I will keep that open until we found that place - and then use what fits in nicely there (I want to avoid crazy character-escaping needs as much as possible ;-) )

[cschweikert]

Just on more thought on this: If we keep the param config as part of the QS code, the QS remains "portable". What do I mean by portability? Let's imagine we have a feature within the provisioning app, that allows us to point to paste the link to a repository+branch that contains code for a QS. This would be a nice thing to have for testing new QSs from development branches ;-)

[michaelsauter]

@cschweikert Yes, that would be super nice. We have to figure out the security implications of this though. For ODS 2, we locked it down pretty much by design ... right now, only an admin can configure quickstarter repositories, and those repos need to be within the opendevstack Bitbucket project. It would be very convenient to open this up, but we should be careful ... maybe by allowing admins how much flexibility they want :)

[ManuelFeller]

Had the same concerns about the in general nice idea.

I was thinking about some safelists for repo-domains that have to match, so you could even limit it to repos from specific servers / projects / users; basically requiring a certain prefix (like https://YOURBITBUCKET.COMPANY/ods-qs-testing/* or https://github.com/michaelsauter/*) to be matched. Nothing too complex; to avoid possible bugs maybe even omit the * and only use a simple .startsWith()comparsion.

And this as optional setting - so Admins can still stick to the old behaviour if they are e.g. on premise and do not want this freedom on their platform to avoid "arbitrary" code execution in the provisioning app...