Add packaging support for Docker images

[bahnwaerter]

The Docker packaging support allows to build Docker images for all Ultimate tools. The images are based on Alpine Linux to ensure a minimal footprint. The build is based on a multi-stage process where temporary build artifacts are discarded and not included in the final Docker images. Each Ultimate tool now has its own dedicated Docker image. Additionally, the WebBackend can be automatically configured through docker-compose environment files to simplify the configuration and deployment of the Web service.

[bahnwaerter]

Currently, the Ultimate tools are built with individual build calls, and the appropriate configurations (toolchain and settings files) are still missing in the respective Docker images.

It would be advantageous if the complete build of the Docker images would be based on the makeFresh.sh script. However, this also includes the makeZip.sh functionality, which is not necessarily required here. Should we split the functionality of the two scripts with regard to the Docker packaging?

A new separation of functionality could look like this:

• makeBuild.sh: Responsible for the Maven build and to collect the correct configurations for each tool
• makeZip.sh: Compresses the corresponding built artifacts
• makeFresh.sh: Calls makeBuild.sh and then makeZip.sh

The separation introduces the makeBuild.sh script that could be used to build the Docker images.

[danieldietsch]

That's a very good idea. I also like your Dockerfile, in particular the use of dockerize!

[danieldietsch]

Very cool changes!

I added some minor comments, and have two things:

Use "real" webserver

I would like to avoid using the Jekyll webserver for the frontend. Could you just use nginx as base?

Our current frontend at https://ultimate-pa.org does the following.

services:
  frontend:
    image: nginx:latest
    volumes:
      - /mnt/shared/ultimate-pa/config/nginx/conf.d:/etc/nginx/conf.d
      - /mnt/shared/ultimate-pa/config/nginx/nginx.conf:/etc/nginx/nginx.conf
      - /mnt/shared/ultimate-pa/frontend:/www/frontend
      - /mnt/shared/ultimate-pa/config/frontend/config.js:/www/frontend/config/config.j

where /mnt/shared/ultimate-pa/frontend is the static website, config.js the config you would expect, /mnt/shared/ultimate-pa/config/nginx/nginx.conf is default, and /mnt/shared/ultimate-pa/config/nginx/conf.d/default.conf is default except specifying the frontend folder:

server {
    listen       80;
    listen  [::]:80;
    server_name  localhost;

    location / {
        root   /www/frontend;
        index  index.html index.htm;
    }

    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   /usr/share/nginx/html;
    }

    error_page  404 /404.html;
    location /404.html {
        root /www/frontend;
        internal;
    }
}

Check windows build

I tried running ./makeFresh.sh as usual, and got at the end:

Archive Ultimate Debug UI [linux]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Not enough arguments supplied -- use arguments in the following order
1. the toolname
2. the launcher name
3. the maximum heap memory size
4. the maximum stack memory size
5. 'linux' or 'win32' for the target platform

But everything else worked as expected

[danieldietsch]

Hm, why not build the frontend with jekyll and serve it with a "real" webserver? I was at least under the impression that jekyll serve is only used for debugging/designing a website, not really for production use.

[bahnwaerter]

I created the Docker image of the Web frontend for development purposes. Here, jekyll serve offers an automatic rebuild and reload mechanism, which makes it super easy to debug and extend the frontend.
This is obviously not suitable for a productive Docker setup. In this case, you would probably be better off using a decent Web server, like your proposed nginx, and a powerful proxy server, like Traefik.

We could create a second Docker image of the Web frontend for production purposes. What do you think?

[danieldietsch]

Ah, that makes sense. Perhaps a comment in the README would be nice so that we remember why it is like it is :)

And of course, a second variant with nginx would be appreciated, then I would switch our current setup over to that.

[danieldietsch]

I think this could now become a function in makeFresh -- which could also be somewhat simpler then. In particular, now that packaging is done before and this only names the zip and actually creates it.

[bahnwaerter]

Good idea! The script has become very small now. It's really not worth a script anymore.

[schuessf]

I just tried running makeFresh.sh, but it just showed the build splashscreen and exited silently.
I checked and it turned out that javac --version produced javac 24, which should be >= 21.
After I used update-alternatives to change javac to 21, the build worked as expected.
Therefore, I think there is some issue here.

[bahnwaerter]

You're right. The version comparison should support that.