[DevDoc] Continuous Integration in Knetminer

Knetminer and other related software are managed by means of Continuous Integration systems, so that updates to our github repositories automatically trigger build and pipelines, which included testing, deployment of the Knetmier web application on our test servers and new binaries made available for downloads.

The process is explained in this presentation:

As you can see, the CI code is mostly based on standalone scripts, which depend as little as possible on the particular CI it is used (which at the moment is GitHub Actions).

Moreover, the CI scripts are based on common scripts, which are downloaded by each repository needing a CI build and can be customised with local extensions.

Among other things, this allows for a common procedure to trigger a new release during the CI build process.

Knetminer has such specific customisations, in particular:

• The main build (which is usually something like 'mvn deploy') happens within our own Docker container, so that we can easily work on a the environment that Knetminer needs (Java, Maven, Node.js, etc).
• After the main build, the scripts use the new tested code to rebuild the Docker image for Knetminer.
• Finally, a trigger is sent to our Jenkins, an internal CI system that, in the case of Knetminer pulls the newly-built image and redeploys test servers for the Knetminer application.