run scheduled builds every week

[ansnoussi]

Context :

• the current latest image for Gotenberg has several vulnerabilities (some from the base debian image, but mostly from installed packages like chromium)
• rebuilding the image will fetch latest versions for these packages and solve 17High, 14Medium and 7Low vulnerabilities:
• here's the test for rebuilding the image and scanning with Docker scout :
  • before :
    
  • after :
    

What's added in this PR :

Run scheduled weekly builds to the keep the latest image always up to date (Use the latest release tag for build).

[gulien]

Hello @ansnoussi,

Thanks for your PR! AFAIK, it overrides the latest versions? Wouldn't it better to create a new minor release instead?

[ansnoussi]

Hello @gulien , first of all thank you for this awesome project.

Following Semantic versioning, a minor release is when you add functionality in a backward compatible manner, which is not exactly the case here.
Even a patch version doesn't make much sense since Gotenberg's code hasn't really changed.

It's quite common for docker images to be built on schedule without bumping the version, In fact it's even better to re-build all the previous (supported) versions on regular basis.

[gulien]

Sorry, I meant a PATCH release 😬 I understand why it would make sense in some projects, but Gotenberg relies heavily on its dependencies. That’s why I tend to consider that the dependencies in the Docker image are part of the semantic versioning.

[ansnoussi]

I understand your point. And ultimately, there could be a system with :

• stable tag for the minor and major versions ( images tagged with 7, 7.5 , 7.6, ... will keep getting updated)
• unique tag for minor versions ( images tagged with 7.5.1 , 7.5.2, ... will not get any updates)

I made the change so there is a someway to keep getting security updates without using the latest tag which could introduce a breaking change (major version bump).

PS: I do know that Gotenberg should not be public-facing, but this keeps triggering automated security alerts, which I believe should be the case for other users too.

[gulien]

Thanks @ansnoussi and sorry for the delay.

I’m still not convinced of the actual implementation. When a bug comes, it’s often great to know the exact version that is affected. If we auto-update 7 version, the startup message will still show 7.9.1.

IMO, I do think having a dedicated patch release is a better option in our context.

[ansnoussi]

@gulien I do understand your hesitation, but I think the issue you are talking about can be fixed in 2 ways :

• having automated tests done on the built image : best solution IMO but takes time/effort to put in place.
• fixing all dependencies versions down to minor release versions so make sure no breaking change is introduced by any dependency : an overall best practice and should be done even if you implement the first solution.

From my POV, having regular updates is mandatory to fix security findings, but releasing a patch version with each re-build of the image is not perfect :

• if there were no updates to any dependency/base image => you would have many patch versions that are exactly the same, and it would be costly.
• I don't see a scenario where someone would rather use an old version with the exact gotenberg api, but vulnerable base image / dependencies.
• users who want to always have the latest patches will have to update their infra each week.

I think to help you make a decision, you can take a look at other OS projects with nightly docker image updates :

• https://github.com/Kong/kong/blob/master/.github/workflows/release.yml
• https://github.com/fedora-cloud/docker-brew-fedora/blob/master/.github/workflows/update_image.yml
• https://github.com/AdoptOpenJDK/openjdk-docker/blob/master/.github/workflows/updater.yml
• https://github.com/rocky-linux/sig-cloud-instance-images/blob/main/.github/workflows/build.yml
• https://github.com/adoptium/containers/blob/main/.github/workflows/updater.yml
• https://github.com/osrf/docker_images/blob/master/.github/workflows/trigger_nightly.yaml
• https://github.com/nodejs/docker-node/blob/main/.github/workflows/automatic-updates.yml

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.