Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Latest version-tagged moonraker (v0.8.0) is out of date #111

Closed
nadiamoe opened this issue Feb 11, 2024 · 6 comments
Closed

Latest version-tagged moonraker (v0.8.0) is out of date #111

nadiamoe opened this issue Feb 11, 2024 · 6 comments

Comments

@nadiamoe
Copy link

Hi there!

I'm a very happy user of your images, and I happen to rely on semver-tagged images as they are easier to upgrade in my ecosystem. I happened to realize, while updating my moonraker config, that the latest tagged image is still v0.8.0.

This version is starting to show incompatibility issues with Mainsail for example, where webcams stopped appearing in the dashboard (this was unpleasant to troubleshoot).

I've worked around this by using one of the commit-tagged images, but I'd really love if we could have a new tagged image for it.

Is there any blocker or reason why this hasn't happened? Can I help to make this happen somehow?

nadiamoe added a commit to nadiamoe/kubeklipper that referenced this issue Feb 11, 2024
Version-tagged moonraker images are out of date and have started to have issues with Mainsail.
Reported upstream: mkuf/prind#111
@mkuf
Copy link
Owner

mkuf commented Feb 11, 2024

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

@nadiamoe
Copy link
Author

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!

@mkuf
Copy link
Owner

mkuf commented Feb 14, 2024

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

@nadiamoe
Copy link
Author

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: nadiamoe/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 :)

@mkuf mkuf mentioned this issue Feb 22, 2024
3 tasks
@mkuf
Copy link
Owner

mkuf commented Feb 22, 2024

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.

@mkuf
Copy link
Owner

mkuf commented Feb 23, 2024

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

-Markus

@mkuf mkuf closed this as completed Feb 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants