search

Raku / docker

Docker files for Rakudo Star
Artistic License 2.0
34 stars 22 forks source link

Bump to 2024.03 and change alpine to alpine:latest #60

Closed AntonOks closed 5 months ago

AntonOks commented 5 months ago

@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

AntonOks commented 5 months ago

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)...

m-dango commented 5 months ago

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.

JJ commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

will re-do it...