Add Dockerfile to make compiler more portable

[tomaz-suller]

First suggested by @thife455 in #22 (comment)

Adding instructions to the README on how to pull from the Ubuntu official images and then map the submission directories with -v would be the minimum to get this closed. It would also be good to link to resources explaining what containers are and to the official Docker installation guide.

Ideally, we would write our own (very simple) Dockerfile and publish it somewhere (perhaps as a GitHub package? not sure if Docker is supported) so users could pull directly from our image, with an entry-point to the CLI.

[tomaz-suller]

The GitHub repository for containers is the Container registry, so in theory we could build our container in CI and upload it there

[tomaz-suller]

@thife455 did you use a custom Dockerfile or did you just pull straight from the Ubuntu images and map your submission and the CLI into a volume?

[thife455]

Hi Tomaz! Sorry for the late reply!

I have made a custom image derived from the official Ubuntu image, mapping all of the current directory files to the new image itself, my crude solution was to make a shell script that removes the image (only the local files, not remote) and creates it again with a watch command, compiles everything and spits out the .mvn file onto the directory.

I do not know if this is the best approach, if you have any ideas feel free to share!

[tomaz-suller]

From my experience volumes are dynamic, so if you create a file somewhere mapped to a volume in your Dockerfile, you could always use the same container.

The simplest way to use a container in this case would likely be something like

$ docker run ubuntu:focal -v $(pwd):/some/path 'cd /some/path && ./mvn-cli assemble -i file.asm' > file.mvn

If you could figure out what the default WORKDIR of the Ubuntu image was, you could map the volume directly to it, or write your own very simple Dockerfile along the lines of

FROM ubuntu:focal
WORKDIR /sisprog

and then

$ docker run my-container -v $(pwd):/sisprog './mvn-cli assemble -i file.asm' > file.mvn

Using a custom Dockerfile would be interesting since you could then make your Dockerfile such that it downloaded the CLI binary into the container on build, and you could then make the CLI an ENTRYPOINT. We already have a one-liner that downloads the latest release from GitHub which you could use, or better yet turn into a script so it's more readable:

curl -LO $(curl -s https://api.github.com/repos/PCS3616/mvn-rs/releases/latest | grep browser_download_url | grep mvn-cli | cut -d '\"' -f 4) && chmod +x mvn-cli

[tomaz-suller]

If you go the custom Dockerfile route (more work but better results, which we could possibly reuse in CI), you could in fact download the mvn-cli binary to somewhere in the $PATH of the container (/usr/bin or $HOME/.local/bin) so you wouldn't have to refer to the full path where the binary was installed.

[tomaz-suller]

Since this repo is public, we can actually use the GitHub Container Registry free of charge. That would allow us to build out own container image in CI using our secret configuration files, without having to rely on downloading a ready-made release from GitHub.