Bump to 2024.03 and change alpine to alpine:latest

[AntonOks]

@m-dango @Altai-man @moritz @jmaslak

As far as can I see, the alpine image version was kept "latest" manually... so with this commit, beside bumping the Star version, I'd like to switch to alpine:latest to simplify things... hope thats ok for everyone.

Should I have missed some "good reasons" to stay on selective alpine versions, pls let me know...

thanks & regards

[JJ]

I have never been familiar with this repo, but there are a couple of things to note here; first is the repetition of code here and there; second the use of manual values instead of ARGs in the build process. Finally, could it be possible to use some kind of templates to maintain a single source, instead of several ones?
This is just a comment, because some of the stuff I mention is clearly out off scope.
In scope I have a nit: changing the name of a variable does seem to have a certain impact, plus not clear what would be the difference, and if there's really any improvement in doing so.
Long story short, I would buy just changing the Alpine version, which seems reasonable, and leave the rest for some refactoring.

[m-dango]

I would prefer we keep explicit versions, at least for now.

There are a variety of well-reasoned arguments out there against using latest tags for production. A simple case to consider would be if Alpine were to update after we publish an image, someone who builds the docker image themselves is going to have a different version of the OS to someone who pulls the published one.

I believe it would make building these images simpler, but I think we should open an issue instead and have a discussion about potential unforeseen consequences of a change like this.

It may be a better approach for us to adapt conventions used by other Docker Official images, I believe there are some which have scripts set up for some automation:

https://github.com/docker-library/ruby
https://github.com/docker-library/golang

[JJ]

I would prefer we keep explicit versions, at least for now.

Sorry, but I have to disagree here. Explicit versions are inherently technical debt. Sooner or later, you'll have to pay back. latest is safe by definition, and if there happens to be a vulnerability with the version you've built, just build it again.

There are a variety of well-reasoned arguments out there against using latest tags for production. A simple case to consider would be if Alpine were to update after we publish an image, someone who builds the docker image themselves is going to have a different version of the OS to someone who pulls the published one.

The workflow can be built to be triggered on demand, or simply schedule updating after certain time. Plus the OS version here is not such a big issue, since no API is being used directly. As a matter of fact, scheduling a build under latest would be advisable, just in case there's some regression.

I believe it would make building these images simpler, but I think we should open an issue instead and have a discussion about potential unforeseen consequences of a change like this.

Opening an issue before a PR is always a reasonable option. I'm happy to move the discussion there, if you so wish.

It may be a better approach for us to adapt conventions used by other Docker Official images, I believe there are some which have scripts set up for some automation:

https://github.com/docker-library/ruby https://github.com/docker-library/golang

Well, I'm not so fond of official images myself. They're one size fits all. But as said above, automation will always save you time.

[AntonOks]

I'm a huge fan of reproducible builds... for "enterprise software". That's why I'm pushing Rakudo dev's to "git tag" their modules with the same version info as they have in the META6.json files... so that's a point for "explicit versions".

In this case here, we talk about docker containers. Per definition, those should have a very short run (and life ;) ) time. And also, from my understanding, "latest" is stable and something with a good reason. There wouldn't be a need for "latest" if the previous "explicit" version wouldn't have issues or is somehow outdated.
With explicit versions, we would need to also define when such a version is good to be used for our docker build.... something like:

• it's already there for XYZ months and/or
• it's downloaded / installed /used XYZ thousand times
  Also, don't know if this really happens with containers, but it does with "enterprise software releases", what if an implicit version, which we just have decided to use, will be discontinued for a good reason (say "security" or "bug" un general). How will we act here then?

So, for our case here, say short living containers, I would feel "ok" with "latest"...

[AntonOks]

... and whatever we define, it has to be reflected in our automation, CI/CD, workflows... because doing the docker releases manually is nothing I'll vote / go for!

[AntonOks]

I have never been familiar with this repo, but there are a couple of things to note here; first is the repetition of code here and there; second the use of manual values instead of ARGs in the build process. Finally, could it be possible to use some kind of templates to maintain a single source, instead of several ones? This is just a comment, because some of the stuff I mention is clearly out off scope. In scope I have a nit: changing the name of a variable does seem to have a certain impact, plus not clear what would be the difference, and if there's really any improvement in doing so. Long story short, I would buy just changing the Alpine version, which seems reasonable, and leave the rest for some refactoring.

For the refactoring topic... who would volunteer to do it?
As the Star docker image wasn't updated for some months, it seems like there is not much of an interest and/or involvement.

My intention is, to have very recent docker images available. Best case, automated and shortly after each new Star release (which is build automatically shortly after a new Rakudo Release)...

[AntonOks]

Just for clarity... my intention to split the former "rakudo_version", was a future automation, I have in mind.
In it, I would check existing "git tags" and / or available "latest" Rakudo Star releases, which do NOT have the "build_revision"... and based on those checks, I'd update (say RegEx) the Docker files...

Some years ago, I think I saw a "rakudo.org" API, which also returned a (or all?) "Star" release(s). If someone points to to that one AND this one returns a "latest" Star version info with the "revisions", I could maybe also use this API in a comming automation.. and then leave the string as it is / was?!?

[AntonOks]

well, just remembered... I do already something similar at https://github.com/rakudo/star/blob/a4653f4c34fad5b83b4ce3b27fa2a2ff27f8c57d/.github/workflows/publish_rakudo-star_on_rakudo.org.yml#L29

So, if you really are against splitting the "rakudo_version" and want to keep it as is, with the revision info, I know a way how to do that ;)

[JJ]

Not really against doing that per se, but I'd prefer an alternative that would not involve changing other lines elsewhere.

[m-dango]

The current setup follows what is considered best practice, and deviating from best practice "to simplify things" seems like an unwise step to take. Unfortunately I'm not currently well versed enough in the reasoning behind Docker's recommendation to participate in this conversation effectively: https://docs.docker.com/develop/develop-images/guidelines/#pin-base-image-versions

I err on the side of caution for deviating from what is considered best practice without a strong justification, but if you feel that you understand the consequences then continue with the change.

Be sure to also check that there will not be any problems with proposing this change to Docker Official Images. This is from their repository:

Because the official images are intended to be learning tools for those new to Docker as well as the base images for advanced users to build their production releases, we review each proposed Dockerfile to ensure that it meets a minimum standard for quality and maintainability. While some of that standard is hard to define (due to subjectivity), as much as possible is defined here, while also adhering to the "Best Practices" where appropriate.

#60 (comment)

[JJ]

With an adequate build script, we can have both: pinned versions (for those who want them), latest ones (for those that don't mind). But come to this point, I think the discussion is out of scope for a simple PR. Should we open an issue for that?

[AntonOks]

With an adequate build script, we can have both: pinned versions (for those who want them), latest ones (for those that don't mind). But come to this point, I think the discussion is out of scope for a simple PR. Should we open an issue for that?

Yes, for me, we are already discussing "something else" (and thanks for all your input / feedback!!!).
Please feel free to take this discussion to other Raku(do) decission makers ;)

I'll continue to implement a workflow without touching the "version" string... and if you (more / good / easy) update workflow examples of other docker "official images", pls let me know.

[AntonOks]

will re-do it...