feat(core): extended template variable functionality

[Panaetius]

Adds support for default values and typing (string, enum, boolean, number) to template variables.

https://dev.renku.ch/gitlab/renku-qa/core-it-template-variable-test-project contains an example of this.

closes #2034

/deploy

[rokroskar]

cc @lorenzo-cavazzi

[lorenzo-cavazzi]

Great to see this taking form!

I was messing around a bit, and I've noticed that --description doesn't work well when I provide a specific source. In other words, renku init -d worked as expected showing me the description, while renku init -s <source> -d initialize the project ignoring the -d switch.

Should --description also show the expected type (if any)?

[Panaetius]

@lorenzo-cavazzi Oh actually that was a bug that has been around for a long time it seems, -d didn't work with a template repo that only has 1 template (In the case of 1 template, that one is used and the user is not prompted to pick a template, so the -d code was bypassed).

Not really a part of this ticket but I fixed it so you can test 🙂

[lorenzo-cavazzi]

This works well in the cli 👍
Could you add the /deploy string in the first post? I'd like to quickly try it on the service

[RenkuBot]

You can access the deployment of this PR at https://renku-ci-rp-2120.dev.renku.ch

[lorenzo-cavazzi]

Sorry for taking a bit longer for the review. I expected the core service to be compatible with the UI since no breaking changes have been introduced, but it crashes when creating a new project so I'm trying to go deeper into the problem.

In the meanwhile, I've noticed the CLI doesn't ask for a value when the parameter has a default. The only way to change it is by providing it through the console.
Would It be a better UX asking anyway for a value and using the default only if the user doesn't enter anything?

Funny fact: the cli shows the parameters in different orders every time. It's not a big deal, but I found it a bit unusual (I typed fake description a few times before realizing it was asking me for the numeric variable first, since the first 3-4 times I got asked for the description first)

[lorenzo-cavazzi]

This looks good to me! I tested a bit with https://dev.renku.ch/gitlab/lorenzo.cavazzi.tech/template-variables

It contains a breaking change for the UI since the templates.read_manifest API returns an object for each variable instead of a string, causing the UI to crash with all the templates.
Since that seems a good solution, I would try to have a compatible version of the APIs but I would wait to merge this until the UI catches up.

[rokroskar]

Is it a breaking change or can it be merged independent of the UI PR?

[Panaetius]

It should be backwards compatible (otherwise tests would fail as current templates don't contain this yet).

[m-alisafaee]

Looks very good! I've made some comments. I also notice that --describe gets ignored when passed without -l. This is a bit confusing. Perhaps we should rename it to --verbose or make also list and describe templates. This of course should be done in a new story.

[m-alisafaee]

Thank you!