Feature/docker publish

[danieleguido]

This PR implements Docker build and publish workflow for both the client and server applications. It adds new Dockerfiles for the client and server, a Makefile and a GitHub Actions workflow.

Dockerization and Build Automation

• Added code/Dockerfile.client and code/Dockerfile.server

• Introduced code/Makefile with targets to build both client and server images locally, passing in Git and build metadata as arguments for reproducible builds.

Continuous Integration and Publishing

• Created .github/workflows/docker-build-publish-client.yml to automate building and publishing the client Docker image to Docker Hub on pushes to the main branch, ensuring up-to-date images are available.

• Created .github/workflows/docker-build-publish-server.yml to automate building and publishing the server Docker image to Docker Hub on pushes to the main branch, ensuring up-to-date images are available.

[sim51]

Hi @danieleguido

Thanks for this PR.

I have a few questions for you.

Actually the production is using the docker compose stack, and on each server, we start a part of the stack.
If you have the docker images, shall the process will change or not ?
The compose stack will not be needed anymore, you can just run an image with the good parameters, and it can be easier to maintain, no ?

I don't remember how we have handle the web server that is on the front of the application.
Do we have an nginx (or an other solution) on front of the docker compose stack ?

About your code :

• we have a docker folder which contains everything that is related to it, and you are not using it.
• the client image you build contains only the build directory (which is great), but there is no web server. So I don't know how you will use it. IMHO, it should contains a web server that serves the website and also do the proxy to the /graphql & /pdf endpoints.

[sim51]

@danieleguido I did some work on top of your PR.
Can you take a look at #62 ?

[danieleguido]

Hi @sim51

Actually the production is using the docker compose stack, and on each server, we start a part of the stack.
If you have the docker images, shall the process will change or not ?

We currently use the Docker Compose file not only for orchestration but also as a form of documentation: it makes environment variables and service configuration transparent to other team members (and we only need one general documentation...).
So even if each VM ends up running a single service, we plan to keep a Compose file there for clarity and consistency.

we have a docker folder which contains everything that is related to it, and you are not using it.

Regarding the Dockerfiles, we intentionally avoid using .dockerignore and prefer listing relevant files explicitly. That’s why the Dockerfiles are located within the client and server directories, and this placement ensures both that the build context includes the necessary files and that image rebuilds are triggered whenever the Dockerfile changes.

The main goal is maintainability and quick readability, following the same structure used across our other projects, so contributors can recognize the pattern immediately.
That said, I have no objection to using the docker/ folder, it’s mostly a matter of habit

Concerning the web server, you have it already defined in the docker/docker-compose.yml:

letterbox:
    image: nginx:${NGINX_VERSION}

Our usual approach is to share a volume between the letterbox-client image, which contains only the built static files, and the nginx service. It might be a bit old-school, but it has worked so far :)

As for the PR #62 you’re right, the GitHub Action builds images under the c2dhunilu namespace and this can be a problem for anyone cloning this repository, they probably have their own docker repository... so, instead of creating an extra folder, what do you think about putting the c2dhunilu path, or even the entire c2dhunilu/letterbox-client path, as environment variables? This would keep the folder hierarchy clean and the docker publish action reusable. Would you mind adjusting your PR in that direction?

Thanks again for your time!