GH Workflow for building and pushing docker image

[SpecialAro]

Problem

The official API Server of Ferdium (https://api.ferdium.org/) is currently running through the docker image provided by https://hub.docker.com/repository/docker/ferdium/ferdium-server.

As described in #31 the current process for updating the official server is:

1. locally pulling the new commits
2. building a new docker image locally
3. pushing the new docker image to the registry docker hub manually
4. delete the old docker image on the server
5. run the new docker image

This process is also totally non-sense and automation is very much in need.

Proposed Solution

My proposal is to create a GH Action for this workflow so that the image can be built and pushed to the registry docker hub automatically. Then, we should be able to check on the server side if a new version is available, stop the container, get the new image and start the container again with the new image.

Any thoughts on this? Do you agree?

[vraravam]

I like this automated approach better than #31
For checking and restarting the docker container - will we need to go with fargate-like solution? Or are you thinking of doing this part in a cron job? will cron have the required permissions to stop and start a new container?

[SpecialAro]

I like this automated approach better than #31

I think this is a different thing because, in my opinion, the server image shouldn't be upgraded when there is any change on the recipes submodule. It only needs upgrading when there is a version bump in this repo.

So, my approach is to try to update the recipes folder locally inside the container when it is needed and only stop and starting the container when a new version of the server API is released. Do you agree?

For checking and restarting the docker container - will we need to go with fargate-like solution? Or are you thinking of doing this part in a cron job? will cron have the required permissions to stop and start a new container?

Maybe we can try to achieve this using portainer (currently I'm using it to manage the server more easily). There is a feature called Edge Jobs (https://docs.portainer.io/v/be-2.10/user/edge/jobs) that possibly can be used for stopping the container, removing the image, and starting the stack again with the latest image from the hub.

[vraravam]

So, my approach is to try to update the recipes folder locally inside the container when it is needed and only stop and starting the container when a new version of the server API is released. Do you agree?

Yes - but, this can happen only if the recipes folder is mounted as a volume on the container - and not baked into the image itself.

[SpecialAro]

So, my approach is to try to update the recipes folder locally inside the container when it is needed and only stop and starting the container when a new version of the server API is released. Do you agree?

Yes - but, this can happen only if the recipes folder is mounted as a volume on the container - and not baked into the image itself.

#33 makes sure to always pull the newest version. To have two volumes (one for data and another one for recipes) can be a requirement to run this docker image, so that the user persists the data.

[SpecialAro]

When #34 is merged and we release a new image automatically, I'll check if the server updated as well. I implemented a webhook using Portainer for each container (Server and Debugger) and linked it to our Dockerhub account.

If everything works as planned this issue can be closed. Thank you @vraravam and @santhosh-chinnasamy for your suggestions and help!

[SpecialAro]

So... The automation with the webhook didn't work and broke the server. I've disabled that for the time being.

The workflow action isn't running properly as well and it is pushing every commit of the repo. This needs fixing

[santhosh-chinnasamy]

@SpecialAro I have a workaround for actions triggered for each commit, we can setup a manual trigger instead of automatic action trigger. I haven't done this but read about it.

check https://levelup.gitconnected.com/how-to-manually-trigger-a-github-actions-workflow-4712542f1960

[vraravam]

@santhosh-chinnasamy - Nice find! I would suggest that you do the changes and run it in your fork, and then raise the PR in the main repo with the successful run of your Action as proof. That way, you can do this independent of @SpecialAro 's interaction.

[santhosh-chinnasamy]

Alright @vraravam , I'll work on it.