-
-
Notifications
You must be signed in to change notification settings - Fork 32
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
Auto-detecting latest tool versions #5
Comments
Thanks for writing this! I strongly agree that auto-detection of the latest version is necessary.
Yes. In the past, this action used the similar way that you mentioned (56a0328), but I have encountered both of these problems.
The repository that manages homebrew tap for my project has a script that automates this (and CI to auto-create PR when the update is needed), so I'm considering porting it. |
Yeah, I figured as much (this is also how I'd do it too).
That makes sense, I had kinda assumed the window between the release creation and binary upload, but figured it would be too small for that to happen in practice, but given how frequently CI runs happen (especially as the number of all projects using the action increases), I'm not sure why I thought this.
Ah, this is a better solution I think. Then you'd just need to run the CI that does the version check/PR on a cron. Or something like that, anyway. For some reason, I thought making automated PRs was somewhat more involved, and couldn't just be done from an action. |
Rambling about prebuilt binaries and version update automation
It's hard to say what to do about prebuilt binaries. I think it would allow avoiding the version compat issues that mdbook has and would allow simplifying the main.sh quite a bit, but... it comes with a lot of pain. I suspect the lack of consistency for release formats, archive names, etc. is generally less difficult to address than inconsistencies between ecosystems, build systems, etc. (see the end for more here) That is, IME there's really no limit to how annoying an arbitrary project can be to build (although it's not unthinkable to do this for stuff like rust, go, zig, <insert other modern portable compiled language here...>). To put it another way, I think it basically means you're taking on basically taking on a subset of the roles that packagers1 are responsible for... which gets a lot harder when you start expanding focus to other build systems and ecosystems. That said, it might be worth it sometimes, but probably only for packages without prebuilt binaries, and which have a sufficient ratio between usefulness and build complexity to justify the hassle. Handling Unsupported Github Runner OS VersionsFor stuff that has binaries like this, I think I'd want to handle it differently. Basically, I'd want to teach the install-action script about which github runner OS versions are supported by which packages. This is a big pain to do manually, but if updates are automated, I think it's a lot easier -- the bot that does the update PR can also try on many different runners, see which ones are compatible, and automatically update information the script has about it. Then, if a user tries to use the package on a runner that is not supported the script can produce a nicer error2. For example, IMO an error like "No prebuilt binary available for A benefit of this approach is that it is still useful even if if it turns out you want to manage the binaries yourself. It's very likely that the binaries would still have some runners they don't work under, and this would help in that case. Handling inconsistent URL/Tag/release formatsSo, let's ignore OS/version compat issues like the one with mdbook, though, and just consider "the lack of uniform formats for URLs, archive names, ...". and try to solve that without performing the build ourselves. I think this is possible. The thought is: use the code that automatically performs PRs for new releases (which I'm going to refer to as "the pr maker"4), and have it also be responsible for normalizing these differences and re-publishing the normalized version somewhere using a normalized/consistent5 scheme for tagging, versions, compression, naming, etc. Now, this would just be moving complexity from the There are a couple reasons I see, but some of them may not be convincing for you, IDK.
EDIT: Note that a big downside of this approach is that it makes #5 more important (maybe much more), since now the request is made to an endpoint which is controlled by you, and not the original authors. A Hypothetical CaseTo elaborate on the previous benefits, lets consider a hypothetical package
So, the problem: The "smart main.sh" approach:
The "smart pr maker" approach:
That is to say, this approach seems much better. Additionally, the flexability this approach has to install whatever software is needed (part 3) means that it's basically perfectly set up to perform the builds too, should that end up being necessary for some of the packages. It just is also able to get that same benefit without taking on that complexity in cases where the authors of the tool in question provide usable binaries themselves. Which I suppose shouldn't be suprising, since this is just "do all the thing's you'd do if you did the build yourself, but reuse the prebuilt versions"... SummaryOkay, that was honestly... quite rambling. I'm genuinely sorry. Most of it was talking through it for myself. Obviously this is your project, so you can take any approach you like. Anyway, I guess the TLDR boils down to: IMO doing all the builds yourself sounds deceptively hard, but you can get a lot of the same benefits by sticking smarts into the tool that does version updates/PRs. Specifically:
Footnotes
|
FYI, |
This has been implemented in v2.0.0. The implementation (#27) is basically an extension of the one described in #5 (comment). The basic design/policy is something like "all the annoying stuff like gaps between tools is handled by the manifest generator" -- this allowed us to remove almost all package-specific code from As for the host OS version, mdbook has started distributing musl binaries, so it is not high on my priority list, but I think @thomcc's idea (better error messages) makes sense (thanks for the idea!), so I will try it. Btw, the implementation I currently think of is as follows:
For the latter, |
It seems like the list of versions is manually maintained. This seems hard to scale and already is at the point where it would be hard to blame you for failing to notice that a release happened.
I'm hoping to use
install-action
to replace some similar code (in an unreleased project). However, remembering to update to the latest version seemed impractical to me, so my code auto-detected it using the github API +jq
(jq
is pre-installed on GHA runners). The code was something like this:This hard-codes several things which would need to not be hard-coded for
install-action
usage, but it may be useful as a starting point. (Also, I'm not good atsh
, so this may do something that is not ideal in some way). But you get the picture.Although, maybe it's not how you'd like to do it. There's an argument that auto-detecting the latest version in this way is fragile, both because it makes too many API requests, and because it breaks if a release happens without binaries. It also doesn't easily support usage with a checksum as required by #1.
So perhaps it would be better to instead automate the updates of
install-action
's version list in some manner. This seems harder to me though, but perhaps you have plans.Anyway, sorry if my concern is misplaced and you do not think this will be a problem. I just felt a little bit bad adding to your workload by adding a new tool after I noticed that versions were hard-coded.
Thank you.
The text was updated successfully, but these errors were encountered: