Latest version-tagged moonraker (`v0.8.0`) is out of date about prind HOT 6 CLOSED

Change in tagging has been implemented w/ #114.
It will take a few minutes to hours for the builds to complete and new images to be pushed the registry.

I'll cut out a new tagged release once all github actions have finished.

from prind.

Hey there,

the build script is consuming tags from upstream and the most recent tag there is v0.8.0 https://github.com/Arksine/moonraker/tags.

Easiest way to get a new tagged image would be to request a new tag from the moonraker maintainer.

A little more complex (and probably intrusive) would be to add new versioning to prind images so that the tag contains an incrementing number since the last tagged release, to stay somewhat compliant w/ semver.
That way you could use a custom regex versioning scheme in your renovate config.

From the top of my Head I'm thinking about something like v<latest upstream tag>+r<number of commits since the tag>, e.g. v0.8.0+r365.

Great work with kubeklipper 👍
I did a first revision of a helm chart that uses the images of prind but never really came around to finish it. 😅

-Markus

from prind.

Thanks for the quick response!

the build script is consuming tags from upstream

Ah, I completely missed that. I did not see any release in moonraker so I (mistakenly) think you were versioning them independently. I'll poke the moonraker maintainers to see if they are comfortable making a release 😄

Great work with kubeklipper 👍

Thank you! There are still a few rough edges here and there, and I haven't figured out a kubernetes-friendly way to flash klipper yet, but it's been working great for me for the last year. Feel free to drop me a line if you happen to try it!

from prind.

I modified the build script a little and could provide a new versioning scheme based on git describe.
This would generate image tags like v0.8.0-310-g67c98f6, where the number after the tag (v0.8.0) would refer to the number of commits since the tag (310), followed by an abbreviated object name for the commit itself (g67c98f6).
See https://git-scm.com/docs/git-describe#_examples for more details.

As the number of commits is increasing until a new tag is added, it should be possible to set a custom versioning scheme in renovate or any other tooling.

Do you think this could work for you?
I'd have to clean up a few things but I would be willing to change the current versioning scheme, as it would be a lot more readable than just shortened commit SHAs 😅

About a kubernetes way to flash the mcu code.
You could utilize a job to do the flashing, each time the klipper image version is updated.
To prevent the klipper/moonraker pod to start while or before the mcu has not been flashed yet, you'd have to add a init container that waits until the job has completed.
I used that scheme in a few different places over the years and would imagine that it can also be used in that case.

-Markus

from prind.

Thanks for taking the time to giving this a swing! I think the version-incremental-hash scheme should work great and might even work with renovate out of the box (as it is sortable) 🎉

re. the k8s way, I thought about having a job and some kind of barrier, but the more I think about it the more I believe that's operator logic somehow crammed into a chart. I think an operator will be a more maintainable way of doing the flashing thing, and could also unlock other cool features. I've drafted an issue here: roobre/kubeklipper#17

For now, this is not a pressing thing to me, but if enough people show interest and/or volunteer that might happen some day :)

from prind.

v1.11.0 has been released.
All images are now available with the new tagging scheme.

-Markus

from prind.