helm: chart directory to reflect latest release

[diegodelemos]

Closes #288

---

This PR includes automatic Helm Chart releases with Helm Chart Releaser Action, leaving the following actions to be taken:

• Set up an access token to be stored in the repository (see more here). Probably we want this token to be a machine user token, for example reana. (should be done by repo owner)
• Create a new branch gh-pages for the CR Action to work (it expects a gh-pages branch always)
• Remove releasing charts docs as it will be automated.

[diegodelemos]

Note: the naming convention stated in this comment is the used inside the PR, so it is in prototype status and can be modified.

Inside the Makefile's recipe to build production images, I am passing all compute backends as this is what we do for production... but if we do so RJC won't start:

$ kubectl logs reana-run-batch-826a4748-27c8-4b6d-9988-28aa811e60c5-z86mp job-controller                                                                                                [10:45:05]
 * Serving Flask app "reana_job_controller/app.py"
 * Environment: production
   WARNING: This is a development server. Do not use it in a production deployment.
   Use a production WSGI server instead.
 * Debug mode: off
Configuration Error Line 0 while reading config source /usr/bin/cernbatchsubmit|
not a valid command, errno=2 : No such file or directory

This points in the direction of having different images, which leads at least to two questions right now:

1. How should the images be separated?

   1. release VS CERN specific
   2. by backend flavour.
   3. any other ideas?

   Regardless the decision, the outcome can be very well encapsulated in our deployment repository, where the values.yaml will point to (1. i.) reanahub/reana-job-controller-cern:v0.7.0 or (1. ii.) reanahub/reana-job-controller-condor:v0.7.0 and the image in the public release will go just with Kubernetes and be reanahub/reana-job-controller:v0.7.0.

2. How is the logic to build them going to be split across our code base? Currently, there is PUBLISH=1 make prod-build

   1. We extend by parameters: COMPUTE_BACKENDS=kubernetes,htcondorcern,slurmcern make prod-build, or even BUILD_ARGUMENTS="COMPUTE_BACKENDS=kubernetes,htcondorcern,slurmcern" make prod-build (the latter smells like a hell to be implemented in Make)
   2. We decouple by targets: make release-build, make cern-build (this hints that we should leave the build logic in gitlab.cern.ch/reana/deployment, so this Makefile will be having only make release-build). Note that this is the approach I initially took, otherwise I should have used the already existing make build.
   3. any other ideas?

@tiborsimko @mvidalgarcia @alintulu

[tiborsimko]

1. How should the images be separated?

I like option 1ii, by backend flavour. Helps to reuse the same image for many deployments, e.g. we could have CERN general instance of REANA, CERN-ATLAS instance, etc.

Kubernetes is the default backend, so it should be included always, and additional backends should be included in alphabetical order, for example:

reanahub/reana-job-controller-htcondorcern-htcondornyu-slurmcern:0.7.0

2. How is the logic to build them going to be split across our code base?

I like option 2i, extending build arguments. It is nicely consistent with option 1ii. People specify which backends they want to build, and the images are named accordingly, and pushed accordingly.

make prod-build

Haven't look at the code, but how would prod-build play with production/values.yaml? Have you thought about dev-build and development/values.yaml private builds as well? Something one could also streamline by extending build parameters, for example:

$ COMPUTE_BACKENDS=foo,bar CLUSTER_FLAGS="ui.enabled=true" BUILD_TYPE="production" make build push
...
reanahub/reana-job-controller-bar-foo:0.6.0-28-g080898f

$ COMPUTE_BACKENDS=foo CLUSTER_FLAGS="ui.enabled=true" BUILD_TYPE="development" make build push
...
reanahub/reana-job-controller-foo:0.6.0-28-g080898f_development

i.e. "kubernetes" always included (and hence omitted in the published image name), and build type (prod/dev) included after version number (with "production" omitted) after underscore... Just an example of possible image naming conventions.

BTW I'm assuming here that e.g. NYU deployment does not need anything special built-in inside images, that any specifics can be expressed as compute backend types, and any other further things (e.g. server URL for the reana-ui! e.g. SSO!) can be passed via other build arguments if need be.

Speaking of which, the default URL in REANA-UI should probably by localhost (for people trying out system locally), and we could have:

reanahub/reana-ui-cern:0.6.0-28-g080898f_development
reanahub/reana-ui-cern:0.6.0-28-g080898f_qa
reanahub/reana-ui-cern:0.6.0-28-g080898f
reanahub/reana-ui-nyu:0.6.0-28-g080898f_development
reanahub/reana-ui-nyu:0.6.0-28-g080898f_qa
reanahub/reana-ui-nyu:0.6.0-28-g080898f

similarly as for r-j-controller.

Ideally, the URL should be an environment variable or something, that we don't need to publish separate images, obviously... So the "flavour" will handle only different authentication techniques, say local accounts vs CERN SSO vs NYU SSO etc.

Talk IRL?

[diegodelemos]

After chatting IRL, we decide to go for 1. ii. and 2. i.. For 2. i. to happen we will merge all build-related actions into the build target and use sub-targets to point to dev-build and release-build.

[tiborsimko]

As discussed IRL a few days ago, aren't we going to separate arguments into their own respective environment variables?

Instead of:

$ BUILD_ARGUMENTS="COMPUTE_BACKENDS=htcondorcern,slurmcern VERBOSITY_LEVEL=info" make foo

going for separating them:

$ BUILD_COMPUTE_BACKENDS=htcondorcern,slurmcern BUILD_VERBOSITY_LEVEL=info make ci

This is the usual envvar usage paradigm, and it could also help us to distinguish target components one day, for example:

$ export REANA_JOB_CONTROLLER_COMPUTE_BACKENDS=htcondorcern,slurmcern
$ export REANA_SERVER_VERBOSITY=info
$ make ci

Just some examples.

P.S. We can do this also after merge.