[BUG] branch and release builds should be immutable (for a specific sha) - nightly builds should move to their own CI script

[liambresnahan]

Describe the bug
Currently I use watchtower to pull docker images and update on a nightly basis. I also use the master-omnibus image as recommended in the docs. This results in pulling the container every day. This seems undesired (from both yours and my standpoint), I noted 225 downloads from that package as of now (6 hours after the package updated) so I assume I’m not the only one seeing this.

Expected behavior
I think there are three options here

• change the docs to use a tagged version
• create a latest tag that is based on releases
• move master-omnibus to use a deployment model that only updates on releases

[AnalogJ]

Hm, not sure what the ask is here.

Scrutiny is available as branch specific docker images (beta-omnibus and master-omnibus) as well as release specific images (v0.4.9-omnibus, etc).

If you want to lock to a specific version, you can do so.

[shamoon]

I think he means because you tag like ghcr.io/analogj/scrutiny:master-omnibus and that tag gets updated (not sure where on your ci) and so it looks like a new image and tools like watchtower will pull again

@liambresnahan If you use ghcr.io/analogj/scrutiny:latest this doesn’t happen

I also noticed the tag in the top right of the app shows a SHA (or something) on the master-omnibus tag whereas latest shows 0.4.9

[liambresnahan]

What @shamoon mentions is what I'm thinking. I was further confused by the sample docker-compose files and docker run commands mentioned mater-omnibus as it sounds like that's the only way to get the combined web app and backend in a single image. If using latest is the best way to track only the latest release but not every commit, that is what I'll update to.

I also tried to check where in the ci the omnibus image gets updated each time, but couldn't find it on quick glance.

What I was mostly asking for is a way to stay on the latest release without seeing a new image every day or every time a new commit is added via ci. I.e. only seeing what is formally making a release.

Sorry I wasn't clear in my ask initially.

[AnalogJ]

Ah, apologies.

So the CI script used to orchestrate the docker image builds can be found here: https://github.com/AnalogJ/scrutiny/blob/master/.github/workflows/docker-build.yaml#L166-L184

In general I follow a golden master development flow, which means that I don't update the master branch directly (unless its for documentation changes), instead I work in a feature branch, or commit to the beta branch.

As development progresses, and I'm satisfied that a feature is complete, and the quality is acceptable, I merge the changes to master and trigger the creation of a new release -- ie, when master is updated, a new release is almost immediately created (and tagged with latest)

So changing from master-omnibus -> latest will be the same thing for all intents and purposes.

Having said that -- the one key difference is the automated cron builds that run on the master and beta branches. They trigger a nightly build, even if nothing has changed on the branch. This has a couple of benefits, but one is to ensure that there's no broken external dependencies in our (unchanged) code.

However, as everyone unfortunately found out a couple of days ago, I had an error in my CI script, which caused failures to be ignored -- #287. That has since been fixed.

Hope that gives you an understanding for how everything is wired up.

TL;DR; The master-omnibus and latest tags are almost semantically identical, as I follow a golden master development process. However if you want to ensure you're only using the latest release, you can change to latest

[shamoon]

Yea I misunderstood, my bad. Well I can’t say I understand the purpose of the nightly builds on master when no source code has actually changed but obviously your project your call!

Ultimately I agree with OP that ideally an image would remain stable and unchanged between releases (and if you want nightly builds you use beta or even nightly or something). Maybe more like a FR I suppose :)

[AnalogJ]

actually you bring up a good point. When i first wrote scrutiny, i only had 1 Github Actions CI script. Since that time I've broken things out into multiple scripts. It probably makes sense to move the nightly builds out into its own script, and leave the docker images as immutable for a specific sha.

I'll update the issue title.

[liambresnahan]

Thanks @AnalogJ and @shamoon yes agree with the new title, that's what I was getting at. Thanks for updating!

[liambresnahan]

@AnalogJ - I’m still seeing nightly builds when using http://ghcr.io/analogj/scrutiny:master-omnibus is that expected now? I assumed not. Last night I updated to the e364e48 commit although I see that v0.4.13 was released 2 days ago. Is something still poking a nightly build or should I just update to scrutiny:latest?

[AnalogJ]

So there are no longer nightly builds, but documentation changes are made directly in the master branch, which will trigger docker builds (but probably shouldnt, I'll add the docs folder to the .dockerignore)

In general I follow a golden master development flow, which means that I don't update the master branch directly (unless its for documentation changes), instead I work in a feature branch, or commit to the beta branch.

Since there are no nightly builds anymore the number of (non-release) updates will be pretty infrequent, but it can happen. If you only want releases, then scrutiny:latest would be the way to go.

[liambresnahan]

Got it. Thanks for confirming. Agree, something in dockerignore sounds good. I'll look to move to latest in future too