tagging images with versions · containers

Stream: containers

Topic: tagging images with versions

Philip Durbin 🚀 (Jun 15 2023 at 19:08):

Today in the containerization meeting we discussed the need for images to be tagged with version numbers such as 5.14, 6.0, etc.

Philip Durbin 🚀 (Jun 15 2023 at 19:08):

We looked at https://hub.docker.com/_/solr/tags as an example of what we want.

Philip Durbin 🚀 (Jun 15 2023 at 19:09):

Screen-Shot-2023-06-15-at-3.09.03-PM.png

Philip Durbin 🚀 (Jun 15 2023 at 19:09):

Someone pointed out that "latest" and "9.2.1" have the same digest. This is normal and expected.

Philip Durbin 🚀 (Jun 15 2023 at 19:10):

It's nice to point to 9.2.1 because you know it won't change under your feet. This is not true of the "latest" tag.

Philip Durbin 🚀 (Jun 15 2023 at 19:11):

I couldn't find anything about this in our roadmap. I'd suggest that we create a GitHub issue for it when we're ready.

Philip Durbin 🚀 (Jun 15 2023 at 19:12):

A big question I have is, when we release 5.14, should we push a 5.14 tag to DockerHub? I don't think we're ready to do this honestly. It'll take some work to prepare for this.

Thomas van Erven (Jul 10 2023 at 08:03):

Philip Durbin said:

A big question I have is, when we release 5.14, should we push a 5.14 tag to DockerHub? I don't think we're ready to do this honestly. It'll take some work to prepare for this.

Out of curiousity, what obstacles do you see here?

Oliver Bertuch (Jul 10 2023 at 10:30):

Problem with version tags is about getting outdated.

Oliver Bertuch (Jul 10 2023 at 10:30):

Releasing updated images for old versions is creating a lot of effort

Oliver Bertuch (Jul 10 2023 at 10:31):

The problem here is not just technical.

Oliver Bertuch (Jul 10 2023 at 10:31):

It's a thing about commitment

Oliver Bertuch (Jul 10 2023 at 10:31):

IQSS is not able to support usage of Docker images for production (yet?)

Oliver Bertuch (Jul 10 2023 at 10:32):

So this is sth that the community needs to look into

Oliver Bertuch (Jul 10 2023 at 10:33):

And we do not have a team of platform engineers yet that is working together here

Oliver Bertuch (Jul 10 2023 at 10:35):

Maybe, when we have a more sophisticated testing pipeline, we could create more supported versions than latest main and develop...

Oliver Bertuch (Jul 10 2023 at 10:36):

And it's not done with just the app image getting tags. We would need to do tagged base images as well, as we would need to have certain versions of Payara around etc

Oliver Bertuch (Jul 10 2023 at 10:36):

I'm not really that sure it's worth it.

Oliver Bertuch (Jul 10 2023 at 10:37):

If you are concerned about new image versions, go use the sha256 to pin down the docker image version.

Oliver Bertuch (Jul 10 2023 at 10:37):

That's good practice anyway

Oliver Bertuch (Jul 10 2023 at 10:38):

Oh and not to forget: we'd need versions of configbaker, too...

Oliver Bertuch (Jul 10 2023 at 10:40):

If the community says we don't care about security, just give us frozen in time images with potential sec risks, sure, let's do it.

Thomas van Erven (Jul 10 2023 at 12:01):

Yeah, alright, that makes perfect sense; maintainability of the images is a factor and if there aren't the engineering resources to drive it forwardd (consistently and securely) then it's not a good hill to die on.

Philip Durbin 🚀 (Jul 11 2023 at 12:28):

I guess I'm a little confused. We COULD push a 5.14 image and never update it. It would be nice and reproducible. However, a log4j or whatever vulnerability could be in there. And that's bad, obviously, security-wise. But if you push a new 5.14 doesn't that defeat the purpose of the image being stable?

Thomas van Erven (Jul 11 2023 at 13:57):

I would say ordinarily, you would push a 5.14.1 (same as you would with "regular" software). However, I can see the engineering effort of testing/maintaining/distributing that on two separate channels can be exhausting. I would say delaying a (public, versioned) release has the benefits of not creating expectations in that manner as well; if you haven't released it, it hasn't broken in production (yet).

Philip Durbin 🚀 (Jul 13 2023 at 11:38):

Hmm. Maybe we should touch on this in the containerization meeting in a couple hours.

Philip Durbin 🚀 (Jul 13 2023 at 14:50):

I did touch on it but only briefly. I linked back to this topic.

Thomas van Erven (Jul 19 2023 at 06:11):

I'm silly that I keep missing those. I'm going to plan that timeslot regular to inform people (especially Management) they shouldn't be Muggling about during that period.

Philip Durbin 🚀 (Jul 19 2023 at 13:06):

Heh. No worries. We can talk about it tomorrow if you like!

Philip Durbin 🚀 (Aug 11 2023 at 09:45):

We had a fairly robust discussion about tagging in the middle of yesterday's meeting: https://harvard.zoom.us/rec/share/vt5PT7OH-Jw3w_orzEhfH1LVCb_cbpNZj3zbz9rsMmqotqLe0aDutti2CoKeJ6MF.Tqs7XJ648HnCvoj7

Johannes D (Dec 15 2023 at 13:59):

I there a change to tag dataverse releases with something like alpha:v6.1 and share them via dockerhub?

Philip Durbin 🚀 (Dec 15 2023 at 14:01):

We discussed this briefly yesterday. Here's the recording: https://harvard.zoom.us/rec/share/-e5CHUCBg7STDie4RF7dFx-YHB74pYQewg6hzKUAuNFBTrD_S7UvH0WrlvZ95erw.eVB72Eyc16Y_kcHE

Specifically we were talking about #containers > change version scheme base image? but it's all related.

Johannes D (Dec 15 2023 at 14:05):

Thanks for the link, I'll watch the recording: )

Philip Durbin 🚀 (Dec 15 2023 at 14:06):

Sure. I think we mentioned you a couple times. :sweat_smile:

Philip Durbin 🚀 (Dec 15 2023 at 14:06):

And it's pretty short. Don't worry. :grinning:

Johannes D (Dec 15 2023 at 14:10):

Yeah I heard my name a few times ;)

Philip Durbin 🚀 (Dec 15 2023 at 14:14):

only good things :grinning:

Johannes D (Dec 15 2023 at 14:39):

IHMO: Build matrixes, with different build options, would be nice but the added complex is not worth the hassle. The "official" release only includes a single war file and no different compiled versions. We are all happy with that... For docker images, a single tag for each release would be sufficient for the beginning. The remainder images are here and can be used to test against a PR. If we really want access to each specific commit, then we need to push and tag each commit. Most likely the majority of those images won't be used and we need to define a retention cycle unless we want to use all the storage ;). Therefore, I believe a single tag for each release is the best option.

Philip Durbin 🚀 (Jan 26 2024 at 20:01):

I just wanted to mention that we had a fairly robust discussion about tags yesterday in the container meeting: https://harvard.zoom.us/rec/share/rDo_V6heO9vo6UDIVhm0mnnsdTDXqA4lNX72lCjhGWrmOEpZttM13CsBceAFXkvr.SgokYNw-AoOACtSm

Philip Durbin 🚀 (Jan 26 2024 at 20:02):

Notes are a bit scattered across the regular notes and a doc I'm using for #containers > tutorial for demo or eval #10238 .

Philip Durbin 🚀 (Jan 26 2024 at 20:02):

Better to watch the video, I think. :grinning:

Philip Durbin 🚀 (Sep 23 2024 at 17:25):

@Oliver Bertuch I see you marked the other thread resolved, which makes sense. Should we continue using this one?

Philip Durbin 🚀 (Sep 23 2024 at 17:26):

I just requested a review from you for this PR: bump version to 6.4 #10871

I added the extra change we need for containers (and made noise about it at standup this morning).

Philip Durbin 🚀 (Sep 23 2024 at 18:17):

This thread is linked from https://guides.dataverse.org/en/6.3/container/running/production.html by the way, so it might be nice to keep it open.

Oliver Bertuch (Sep 23 2024 at 19:16):

Sounds good to me :saluting_face:

Philip Durbin 🚀 (Sep 25 2024 at 19:47):

@Oliver Bertuch I think we have only one more PR we want to merge before releasing 6.4. Any news on #10618 (app image tags)? Should we hold the train?!? :train:

Oliver Bertuch (Sep 25 2024 at 19:47):

No please carry on. I will not be able to work on this before next week.

Philip Durbin 🚀 (Sep 25 2024 at 19:47):

Fair enough! Thanks!

Oliver Bertuch (Sep 25 2024 at 19:47):

We'll release a 6.4 image once we have the workflow going

Philip Durbin 🚀 (Sep 25 2024 at 19:48):

Yeah, we'll build on it.

Oliver Bertuch (Sep 25 2024 at 19:48):

Just like we did with 6.1-6.3 now :smile:

Philip Durbin 🚀 (Sep 25 2024 at 20:01):

Yeah. Anyway, we just kicked off a new sprint. I dragged #10618 into it. Hopefully we'll get to it in the next two weeks. If not, we can kick it back. :grinning:

Oliver Bertuch (Sep 25 2024 at 20:02):

SGTM! :sound: :+1: /me

Philip Durbin 🚀 (Sep 25 2024 at 20:04):

I gave it a tiny size because last time you did all the work but please let me know if I can help at all.

Philip Durbin 🚀 (Sep 25 2024 at 20:21):

When discussing making the 6.4 release today I explained toggling between these:

<base.image.version>${parsedVersion.majorVersion}.${parsedVersion.nextMinorVersion}</base.image.version>
<!-- <base.image.version>${revision}</base.image.version> -->

@Steven Winship asked if we could automate this as part of our release process. We all agreed it's a good idea, but our release process is highly manual right now. :grimacing:

Oliver Bertuch (Sep 25 2024 at 20:24):

My money would be on sth like https://www.mojohaus.org/versions/versions-maven-plugin/set-property-mojo.html

Philip Durbin 🚀 (Sep 25 2024 at 20:35):

Hmm, should we start a topic for this?

Oliver Bertuch (Sep 25 2024 at 20:37):

You kind of did in #dev > From Jenkins to GHA to Dagger? , too. As it's not just containers, maybe talk about it in a #dev topic?

Philip Durbin 🚀 (Sep 25 2024 at 20:39):

Yeah, I'm thinking #dev

Philip Durbin 🚀 (Oct 08 2024 at 18:01):

So can I help in any way with this issue? Tags for application container images #10618

Philip Durbin 🚀 (Oct 08 2024 at 18:02):

I assigned it to myself at the start of the sprint (which is now almost over) but I haven't done anything with it. :sweat_smile:

Philip Durbin 🚀 (Oct 10 2024 at 12:15):

@Oliver Bertuch do you figure we'll talk about tagging during today's call? I don't have much on the agenda.

Oliver Bertuch (Apr 30 2025 at 14:00):

So I'm looking into app container image versions right now.

Oliver Bertuch (Apr 30 2025 at 14:00):

I'm wondering if for the time being I should actually touch any of the usual app image pushing and stuff

Oliver Bertuch (Apr 30 2025 at 14:01):

I could also just use the maintenance job and let that take care of the app image stuff on its own. Maybe that would reduce complexity. (It's already VERY complex)

Oliver Bertuch (Apr 30 2025 at 14:02):

Any thoughts?

Philip Durbin 🚀 (Apr 30 2025 at 14:04):

Yay!

Philip Durbin 🚀 (Apr 30 2025 at 14:04):

I'm not sure I'm following. Whatever you feel is best!

Philip Durbin 🚀 (Apr 30 2025 at 14:05):

Happy to do a zoom or whatever if it helps!

Oliver Bertuch (Apr 30 2025 at 14:05):

Yeah, that might be a good idea.

Oliver Bertuch (Apr 30 2025 at 14:05):

Should I light a fire?

Oliver Bertuch (Apr 30 2025 at 14:07):

I just did: https://fz-juelich-de.zoom.us/j/62913876486?pwd=E0IcMtxb7ZufoDYp9rLNbpDDxGCaKS.1

Philip Durbin 🚀 (Apr 30 2025 at 14:07):

container working group, assemble!

Philip Durbin 🚀 (Apr 30 2025 at 14:07):

(but I need to find a room) :sweat_smile:

Philip Durbin 🚀 (Apr 30 2025 at 14:56):

@Oliver Bertuch great chat, thanks for working on #10618! Please let me know if we should move it from "on hold" to "in progress"!

Oliver Bertuch (May 08 2025 at 07:26):

Yes, please move it :slight_smile:

Philip Durbin 🚀 (May 08 2025 at 17:57):

Actually now that there's a PR (#11477) I moved the PR to "in progress" (and mentioned it at standup) and removed the issue from the project (which is our way). :smile:

Oliver Bertuch (May 09 2025 at 11:00):

@Don Sizemore any ideas why your guides action wouldn't install the dependency? Worked on my machine... https://github.com/IQSS/dataverse/actions/runs/14927388354/job/41935232979

Don Sizemore (May 09 2025 at 12:19):

@Oliver Bertuch I'm afraid not, off the top of my head. The only reason we have that fork is: uses -W instead of --keep-going

Don Sizemore (May 09 2025 at 12:20):

I see the .cache permissions error, but I've done nothing special to the upstream sphinx container.

Oliver Bertuch (May 09 2025 at 12:20):

I'm suspecting that the base image (sphinx:3.5.4) has an old Python version that might not be compatible.

It's using 3.9 as seen in the image. The package requires 3.10 (as seen here)

Oliver Bertuch (May 09 2025 at 12:25):

@Don Sizemore can this be upgraded? Simply switching to sphinx:7.4.0 would probably help :smiley:

Philip Durbin 🚀 (May 09 2025 at 12:29):

Should we open a new PR to see if it's happening everywhere?

Oliver Bertuch (May 09 2025 at 12:29):

No need - it's just for me because I installed another extension

Oliver Bertuch (May 09 2025 at 12:30):

We are installing Sphinx 7 anyway by installing it via pip/requirements.txt, so it would probably make sense to update.

Don Sizemore (May 09 2025 at 12:31):

Let's open an issue and yes sounds like upgrading Sphinx is the way to go.

Oliver Bertuch (May 09 2025 at 12:32):

I can't open an issue - the repo https://github.com/uncch-rdmc/sphinx-action has them deactivated.

Oliver Bertuch (May 09 2025 at 12:32):

I could create a PR though :smiling_face_with_hearts:

Oliver Bertuch (May 09 2025 at 12:47):

@Philip Durbin ☀️ this isn't a good look :cry:
image.png

Do you think we should enable the Renovatebot to update our container deps/packages/...?

Don Sizemore (May 09 2025 at 12:59):

@Oliver Bertuch I had thought you might open an issue in the IQSS repo (and potentially do away with the uncch-rdmc fork altogether?)

Oliver Bertuch (May 09 2025 at 13:00):

Well we could pull the action into the IQSS main repo and make it our own action. Is that what you're suggesting? Add it to https://github.com/IQSS/dataverse/tree/develop/.github/actions and use from there?

Don Sizemore (May 09 2025 at 13:00):

@Oliver Bertuch that uncch-rdmc fork was a stop-gap; it would be preferable for it to go away.

Oliver Bertuch (May 09 2025 at 13:01):

@Don Sizemore I see!

Don Sizemore (May 09 2025 at 13:02):

@Oliver Bertuch or, if we still need it, that's fine as well. just an extra hop, is all.

Oliver Bertuch (May 09 2025 at 13:03):

Well I can create an issue. Wouldn't try to rope the moving into this PR, but would like to get it unblocked. Can we still update the current bandaid before we rip it off?

Don Sizemore (May 09 2025 at 13:04):

sure thing. speaking of band-aids, I still remember the pain of upgrading to our currently-used version of Sphinx.

Philip Durbin 🚀 (May 09 2025 at 13:29):

@Oliver Bertuch yes to renovatebot, please!

Don Sizemore (May 09 2025 at 13:51):

in the short term, I've put testing with sphinx:7.4.0 on my never-ending to-do list.

Oliver Bertuch (May 09 2025 at 14:36):

What would you needed to be tested? Some other workflows using this action?

Oliver Bertuch (May 09 2025 at 14:40):

Philip Durbin ☀️ said:

Oliver Bertuch yes to renovatebot, please!

Great. I'll make it do weekends, group by image and only work on ct stuff, no Java.

Oliver Bertuch (May 09 2025 at 14:40):

We can extend from there...

Oliver Bertuch (May 09 2025 at 14:41):

Way more options than dependabot :cowboy:

Oliver Bertuch (May 15 2025 at 13:46):

Tried this out today. It works (see https://github.com/gdcc/wip-dataverse-base-image/issues/3#issue-3065663570), but there is a big BUT. Looks like in Alpine, they do not save older versions. So there is no reproducible builds, because once the version progresses on their side, there is no installing an older version...

Oliver Bertuch (May 15 2025 at 13:48):

So the only way to go about this is to stick to the current approach without versions and detect in the maintenance script if updates for them are available

Oliver Bertuch (May 15 2025 at 13:49):

Might be good to save this link, in case we need a Renovate Bot configuration again at some later time. https://github.com/gdcc/wip-dataverse-base-image/commit/53843cc0c4f0299435706a72af3e6ff980fa7a2d

Philip Durbin 🚀 (May 15 2025 at 13:53):

Should we switch from Alpine? Is there some other image that saves older versions?

Oliver Bertuch (May 15 2025 at 13:53):

Not images, package ecosystems. Yeah, Ubuntu etc keep older versions for longer

Philip Durbin 🚀 (May 15 2025 at 13:55):

I wasn't sure what to call it. :sweat_smile:

Oliver Bertuch (May 15 2025 at 14:06):

I really am thinking about using Ubuntu here as well. The images would be aligned and we can reuse the scripts we already have to detect the new package versions.

Oliver Bertuch (May 15 2025 at 14:07):

We'd need to install some stuff not from package managers, but that might not be that bad. We can use Renovate to keep 'em updated

Philip Durbin 🚀 (May 15 2025 at 14:10):

No objection to switching to Ubuntu.

Oliver Bertuch (May 15 2025 at 14:20):

Haha I read up a little about Ubuntu's policy on this - same... They don't keep old packages, only very temporarily.

Philip Durbin 🚀 (May 15 2025 at 14:23):

So much for reproducible builds!

Oliver Bertuch (May 15 2025 at 17:10):

Using Ubuntu means we blow up the image by ~100%. 239 MB -> 419MB

Oliver Bertuch (May 15 2025 at 17:10):

And I had to use hacks to work around stuff that is not packaged for Ubuntu :rolling_eyes:

Oliver Bertuch (May 15 2025 at 17:11):

Like install pipx via apt, then install pipx with pipx, delete apt version, install pipx with pipx globally just to install awscli without crazy python3-pip package dependencies in Ubuntu... Otherwise it would have been ~300MB more... Crazy Ubuntu packaging....

Philip Durbin 🚀 (May 15 2025 at 17:31):

Well, at least we're standardizing.

Oliver Bertuch (May 15 2025 at 17:32):

Yeah. Also probably not a bad idea to have python and a recent pipx around

Oliver Bertuch (May 15 2025 at 17:33):

Can be used for scripting

Oliver Bertuch (Jun 02 2025 at 13:08):

@Philip Durbin would you agree that we should keep the Alpine flavors for the past releases and not change those to Ubuntu for the sake of backward compatibility?

Oliver Bertuch (Jun 02 2025 at 13:08):

(So switch to Ubuntu going forward only)

Philip Durbin 🚀 (Jun 02 2025 at 13:15):

This is only for configbaker, right? Does it matter much? As long as it works, right?

Oliver Bertuch (Jun 02 2025 at 13:15):

Yeah, that's what I figured.

Philip Durbin 🚀 (Jun 02 2025 at 13:15):

Whatever is easier, I'd say. Whatever is less complicated.

Oliver Bertuch (Jun 02 2025 at 13:16):

As it means less patch files, sticking with Alpine for the moment seems less complex

Philip Durbin 🚀 (Jun 02 2025 at 13:16):

for past releases

Philip Durbin 🚀 (Jun 02 2025 at 13:16):

sure, sounds fine

Oliver Bertuch (Jun 02 2025 at 14:10):

@Don Sizemore I fixed Sphinx with https://github.com/IQSS/dataverse/pull/11477/commits/db86eb1a5cfbf896ae11f073891c0c1c14894f0e

Oliver Bertuch (Jun 02 2025 at 14:14):

BTW for the configbaker image I'm introducing a Trivy Scan in case there's no more recent upstream image. This way we can learn if there are sec vulns that can be fixed by updating (=rebuild)

Oliver Bertuch (Jun 02 2025 at 14:15):

For now, this will only look at OS packages, but we can extend that further.

Oliver Bertuch (Jun 02 2025 at 14:15):

Keeping it a bit simpler for now

Philip Durbin 🚀 (Jun 02 2025 at 14:15):

KISS!

Oliver Bertuch (Jun 02 2025 at 14:15):

Might be helpful for the other images as well. We'll see.

Don Sizemore (Jun 02 2025 at 14:26):

@Oliver Bertuch wonderful! I'm sorry this languished on my to-do list.

Oliver Bertuch (Jun 02 2025 at 14:28):

No worries. I didn't make a very sophisticated thing of this, just reusing things already available. And who knows - maybe we publish the docs to GH pages or some place else using GH actions some day.

Oliver Bertuch (Jun 02 2025 at 14:55):

@Philip Durbin reason enough to upgrade the older images, too?
image.png

Philip Durbin 🚀 (Jun 02 2025 at 14:56):

I mean, no objection from me. I appreciate all the work you're doing on these images!

Oliver Bertuch (Jun 02 2025 at 15:00):

Bah I'll leave it at that for now. We can still switch to a different policy at a later point

Oliver Bertuch (Jun 02 2025 at 15:03):

@Philip Durbin the PR is mostly done (missing a release snippet and docs in the devguide). Do you have spare cycles to take a look? It would be good to have the PR merged this week so I have images ready to go for next week... :wink:

Oliver Bertuch (Jun 02 2025 at 15:04):

I can walk you through as well :smile:

Oliver Bertuch (Jun 02 2025 at 15:05):

It looks huge, but isn't that complicated...

Philip Durbin 🚀 (Jun 02 2025 at 15:28):

Sure! Want to do a quick call?

Oliver Bertuch (Jun 02 2025 at 17:35):

So we can do a Zoom now if you want and don't mind me eatin' :wink:

Oliver Bertuch (Jun 02 2025 at 17:36):

No camera anyway :smiley:

Philip Durbin 🚀 (Jun 02 2025 at 17:37):

yes, no camera please :smile:

Philip Durbin 🚀 (Jun 02 2025 at 17:37):

let me grab sonia's office

Oliver Bertuch (Jun 02 2025 at 17:37):

The ipu6 Intel cam doesn't work on Linux (yet), so no worries :smiley_cat:

Oliver Bertuch (Jun 02 2025 at 17:39):

https://fz-juelich-de.zoom-x.de/j/63874239919?pwd=NRA5yGhjPc35teaSCb1agMt5pHcIVK.1

Philip Durbin 🚀 (Jun 04 2025 at 15:30):

Why do we already see tags like 6.6-noble at https://hub.docker.com/r/gdcc/dataverse/tags even though #11477 hasn't been merged yet? This is because of the existing maintenance script from #10827?

Oliver Bertuch (Jun 04 2025 at 16:15):

Probably was me during tests on my local machine... :melting_face:

Philip Durbin 🚀 (Jun 04 2025 at 17:32):

Ok, no worries, thanks.

Philip Durbin 🚀 (Jun 04 2025 at 18:53):

This doesn't make much sense to me, under "Upcoming":

Summary: Rolling tag, equivalent to unstable for current development cycle. Will roll over to the rolling production tag after a Dataverse release.

Philip Durbin 🚀 (Jun 04 2025 at 18:54):

Do we even need "upcoming"? Who would use it?

Oliver Bertuch (Jun 04 2025 at 18:55):

Someone you wants to use the next release version in some evaluation but not get the changes from the next dev cycle

Oliver Bertuch (Jun 04 2025 at 18:56):

Because the upcoming versioned tag will be the next stable rolling tag

Philip Durbin 🚀 (Jun 04 2025 at 18:56):

If someone wants a preview of 6.7, for example?

Oliver Bertuch (Jun 04 2025 at 18:56):

Yeah exactly

Oliver Bertuch (Jun 04 2025 at 18:56):

And then maybe stick with it

Oliver Bertuch (Jun 04 2025 at 18:57):

Some staging environment where the version gets rolled over to the production environment once satisfied and released

Philip Durbin 🚀 (Jun 04 2025 at 18:57):

for staging

Philip Durbin 🚀 (Jun 04 2025 at 18:57):

but wait, why not just use "unstable"?

Oliver Bertuch (Jun 04 2025 at 18:58):

Because that will always point to the latest dev snap

Oliver Bertuch (Jun 04 2025 at 18:58):

Let's have an example

Philip Durbin 🚀 (Jun 04 2025 at 18:58):

please!

Oliver Bertuch (Jun 04 2025 at 18:58):

Say I'm testing 6.7

Oliver Bertuch (Jun 04 2025 at 18:58):

That's not released at the moment

Philip Durbin 🚀 (Jun 04 2025 at 18:58):

Oliver Bertuch (Jun 04 2025 at 18:59):

So it's the same as unstable

Philip Durbin 🚀 (Jun 04 2025 at 18:59):

specifically, the tag is 6.7-noble right? but we'll call it 6.7 for short

Oliver Bertuch (Jun 04 2025 at 19:00):

But as I want to stick to a certain level of development, maybe eager for some feature to be in 6.7, I still use the version to make it explicit what I am doing - I'm interested in the 6.7 release, not following the dev cycle beyond it

Oliver Bertuch (Jun 04 2025 at 19:00):

Now 6.7 gets released

Oliver Bertuch (Jun 04 2025 at 19:00):

So unstable will now be the same as 6.8-noble

Oliver Bertuch (Jun 04 2025 at 19:01):

And I get the stable, maintained images sticking to 6.7

Oliver Bertuch (Jun 04 2025 at 19:01):

So I can make a PR from my staging branch for GitOps to production and there's 6.7 that's getting inserted

Oliver Bertuch (Jun 04 2025 at 19:02):

So I don't need to make a manual change from unstable to 6.7

Oliver Bertuch (Jun 04 2025 at 19:02):

I can definitely see someone using such a workflow

Oliver Bertuch (Jun 04 2025 at 19:02):

And yes, using 6.7-noble shortened to 6.7 for less typing ... lazy dev here

Oliver Bertuch (Jun 04 2025 at 19:03):

Does that make sense now?

Philip Durbin 🚀 (Jun 04 2025 at 19:03):

Let me try to express this another way.

You decide on 6.7-noble as the tag you want. 6.7 hasn't been released yet. You merrily test away.

Eventually, 6.7 is released. At this point, the 6.7-noble tag you chose is the same tag that someone would use if they want the released version of 6.7. You don't have to do anything (well, maybe a docker pull). You're already on the tag you want.

Oliver Bertuch (Jun 04 2025 at 19:03):

Yeah exactly

Philip Durbin 🚀 (Jun 04 2025 at 19:03):

Ok, interesting use case.

Philip Durbin 🚀 (Jun 04 2025 at 19:04):

I'm hacking away on these docs. I'll have you review them. :smile:

Oliver Bertuch (Jun 04 2025 at 19:04):

It's actually pretty common in DevOps/GitOps to have expressive statements of what you want

Philip Durbin 🚀 (Jun 04 2025 at 19:04):

declarative

Oliver Bertuch (Jun 04 2025 at 19:04):

Yeah

Oliver Bertuch (Jun 04 2025 at 19:04):

Sry

Oliver Bertuch (Jun 04 2025 at 19:05):

Poor choice of wording here

Oliver Bertuch (Jun 04 2025 at 19:05):

We probably can, at a later point, introduce a tag like 6-noble to further this

Oliver Bertuch (Jun 04 2025 at 19:06):

Which would always point to the latest stable minor release

Philip Durbin 🚀 (Jun 04 2025 at 19:06):

You would need to docker pull, right? When 6.7 comes out?

Oliver Bertuch (Jun 04 2025 at 19:06):

Absolutely

Philip Durbin 🚀 (Jun 04 2025 at 19:06):

Oliver Bertuch (Jun 04 2025 at 19:06):

In case of Kubernetes, you'd use an ImagePullPolicy of Always

Oliver Bertuch (Jun 04 2025 at 19:07):

So when the pod is restarted, it gets the new image immediately

Philip Durbin 🚀 (Jun 04 2025 at 19:10):

ha, now I want a |nextNextVersion| :crazy:

Philip Durbin 🚀 (Jun 04 2025 at 19:38):

Ok, I just pushed. Please take a look.

Philip Durbin 🚀 (Jun 04 2025 at 19:41):

There's a bit of duplication going on with all the "supported image tags" stuff.

Philip Durbin 🚀 (Jun 04 2025 at 19:41):

But I'm not going to worry about that right now. I'd like to move this along.

Oliver Bertuch (Jun 04 2025 at 19:42):

Yeah, I don't fancy the dupes. But if someone goes to one of the pages, all of the info is right there, no need to go to another site.

Oliver Bertuch (Jun 04 2025 at 19:42):

So someone looking for specific information on one of the images can find it all in one place

Philip Durbin 🚀 (Jun 04 2025 at 19:43):

I feel like 99% of people will only care about the dataverse image, the app image.

Oliver Bertuch (Jun 04 2025 at 19:43):

Also, if we change the release model in the future for the different pieces, it would be good to already have a proper szart

Oliver Bertuch (Jun 04 2025 at 19:43):

There's much truth in that 99%...

Philip Durbin 🚀 (Jun 04 2025 at 19:43):

yeah, it's fine

Philip Durbin 🚀 (Jun 04 2025 at 19:44):

anyway, please edit away those docs

Oliver Bertuch (Jun 04 2025 at 19:44):

They look fine

Philip Durbin 🚀 (Jun 04 2025 at 19:44):

revert my ideas as needed :smile:

Oliver Bertuch (Jun 04 2025 at 19:45):

No no it's all good. Someone else should also get it, too, and you have a different context and perspective than me, so it's good to mix that into all.of this.

Philip Durbin 🚀 (Jun 04 2025 at 19:46):

As I look at the code, is there anything in particular you have doubts about?

Oliver Bertuch (Jun 04 2025 at 19:46):

You mean something in the maintenance scripts that might fall apart when looking to closely?

Philip Durbin 🚀 (Jun 04 2025 at 19:46):

just in general

Philip Durbin 🚀 (Jun 04 2025 at 19:47):

I'm not sure I understand this:

"It needs to be decided if not running the Maven Unit Test workflow on push to master and not on new tags.
Otherwise, this is only touching container stuff, low risk for anyone else."