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

Support for auto-updating the uv version #31

Open
burgholzer opened this issue Apr 22, 2024 · 4 comments
Open

Support for auto-updating the uv version #31

burgholzer opened this issue Apr 22, 2024 · 4 comments
Labels
question Further information is requested

Comments

@burgholzer
Copy link

Hey 👋🏼

Thanks for your work on this project! Integrating it into some of our repositories over at https://github.com/cda-tum was pretty smooth sailing and works nicely. Consider this issue more a request for comment or a suggestion and not as an issue per se.

Right now, the action will (rightfully, imo) emit a warning when not specifying an explicit version of uv to use.
However, not specifying a version generally lowers the maintenance overhead as one keeps automatically getting new versions.
If I would specify a version explicitly (maybe even using SemVer to permit patch version updates), I would have to manually check for new versions continuously and update them in all projects that use this action.
Given that the version is specified as an option to the action, this is cannot be simply updated by dependabot and I am not really aware of any other solutions for automating that particular setting. (that might just be my ignorance, though 😅)

Over at nox (and probably many others, such as cibulidwheel) this is solved by versioning the action with the same version as the tool the action provides. For convenience, some of those repositories provide additional (moving) tags for their actions that would, e.g., allow for action versions such as @2.5, which would correspond to ~2.5.0 in SemVer or @2, which would correspond to ~2.0.
This kind of versioning policy of the action allows for using dependabot to get automatic updates through CI, while still giving the user the option to decide which granularity of SemVer they want to go for.

Would you consider something like that? Feel free to close this issue if you feel that this is totally out of scope for this action here 😌
(Technically, one could directly bring this up to the folks at @astral-sh and ask if they would be willing to set something like that up.)

@yezz123 yezz123 added the question Further information is requested label Apr 23, 2024
@Vanley
Copy link
Contributor

Vanley commented Jun 14, 2024

@burgholzer You can omit specifying the version and live with eyesore of the warning.
image

@burgholzer
Copy link
Author

@burgholzer You can omit specifying the version and live with eyesore of the warning.

image

We actually do that in all of our workflows.

However, the point of the feature request was a bit of a different one. For reproducibility reasons, it would be better to pin a version of uv. But as off now, there is no (easy) way to automated the update process, e.g., with dependabot.
The description above tries to lay out a suggestion for how that could be made to work.

@Vanley
Copy link
Contributor

Vanley commented Jun 17, 2024

Sorry, yes I totally miss that 😅

If you want dependabot to be able to suggest you a update then, personally i don't see the way other then you already mentioned to release and bind versions 1 to 1, but that is to big of the strain on the maintainer.

if you just want the respecting semver range then that could be done, (but i believe that its not what you are asking for).
If special character '@' then take tags on that repo (they are ordered from latest to oldest)
https://docs.github.com/en/rest/repos/repos?apiVersion=2022-11-28#list-repository-tags
https://api.github.com/repos/astral-sh/uv/tags?page=1 (multiple pages)
then filter all tags

import * as semver from 'semver';
semver.satisfies(tag, semverString)

then find the latest tag which is in range
then prepare link as its already done there

    installScript =
      version == null
        ? `https://github.com/astral-sh/uv/releases/latest/download/uv-installer.sh` 
        : `https://github.com/astral-sh/uv/releases/download/${version}/uv-installer.sh`

@yezz123 btw just good to know, you can use github to resolve latest https://docs.github.com/en/repositories/releasing-projects-on-github/linking-to-releases#linking-to-the-latest-release

@burgholzer
Copy link
Author

Sorry, yes I totally miss that 😅

If you want dependabot to be able to suggest you a update then, personally i don't see the way other then you already mentioned to release and bind versions 1 to 1, but that is to big of the strain on the maintainer.

if you just want the respecting semver range then that could be done, (but i believe that its not what you are asking for). If special character '@' then take tags on that repo (they are ordered from latest to oldest) https://docs.github.com/en/rest/repos/repos?apiVersion=2022-11-28#list-repository-tags https://api.github.com/repos/astral-sh/uv/tags?page=1 (multiple pages) then filter all tags

import * as semver from 'semver';
semver.satisfies(tag, semverString)

then find the latest tag which is in range then prepare link as its already done there

    installScript =
      version == null
        ? `https://github.com/astral-sh/uv/releases/latest/download/uv-installer.sh` 
        : `https://github.com/astral-sh/uv/releases/download/${version}/uv-installer.sh`

Something like that would definitely be possible and it would probably make the action itself more useful as you could specify supported version ranges and kind of relax the strict version setting a little bit while still being explicit on what you want to support.

But you are right, it's technically not solving the auto-update "problem".
I think most of the tools that base their versioning on the releases of some third-party package have the process of tagging new versions automated via GitHub actions so that it doesn't become painful for the maintainer(s). That way, it's only painful once while setting up that process, but works nicely afterwards.
The ruff-pre-commit mirror roughly works like that. See https://github.com/astral-sh/ruff-pre-commit/blob/main/.github/workflows/main.yml.
Potentially, some inspiration could be taken from there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants