Add an "update.sh"

Question

Add an "update.sh"

J0WI opened this issue 6 years ago · comments

@docker-library-bot can run a simple update.sh script for you to update the Perl version automatically. Just add it to the team and open a corresponding PR here: https://github.com/docker-library/oi-janky-groovy/blob/master/update.sh/vars.groovy

See e.g. here: docker-library/wordpress@d775299

Zak B. Elep · Answer 1 · Wed Jan 30 2019 16:41:23 GMT+0800 (China Standard Time)

Thanks @J0WI, I think you've brought this up before in #24 (comment)

I'll try taking a look at this again this weekend.

Zak B. Elep · Answer 2 · Sat Feb 16 2019 16:20:31 GMT+0800 (China Standard Time)

So I've taken a look, and so far a few things need to happen here:

A way to get stable/oldstable Perl release versions reliably: asking on #p5p I was pointed to looking at https://perl5.git.perl.org/perl.git tags and this seems easy enough to implement in an update.sh
A means to run Devel::PatchPerl under update.sh; this could be just as simple as running generate.pl under update.sh (after it updates config.yml) but I'm not sure of the environment update.sh runs on, particularly if I can run perl/cpanm on it. @J0WI @tianon would you know?
A better way to manage that config.yml (and maybe converting to config.json as it seems CLI tools to use under update.sh talk better in JSON than in YAML.)

I'm happy to hear of more ideas/considerations as well, thanks again for suggesting!

Tianon Gravi · Answer 3 · Wed Feb 20 2019 07:30:54 GMT+0800 (China Standard Time)

You definitely shouldn't rely on running perl/cpanm via update.sh if you want @docker-library-bot to be running it. It's reasonable to rely on curl/wget/jq, but perl or cpanm is too much. It might make more sense to use Travis CI or something like it, especially now that they support cron jobs (https://docs.travis-ci.com/user/cron-jobs/), since you'll be able to control the environment much better.

See docker-library/docs#1248 (comment) for a bit more detail on what we use @docker-library-bot for (and how much it does). It's really not very much. 😅

Zak B. Elep · Answer 4 · Wed Feb 20 2019 11:49:51 GMT+0800 (China Standard Time)

Thanks @tianon, yeah this might be more doable using Travis CI cron jobs; I've been thinking about adding CI for a while now so this might push it further.

mohawk2 · Answer 5 · Mon Sep 14 2020 19:54:25 GMT+0800 (China Standard Time)

cpanm can self-bootstrap via curl though?

Zak B. Elep · Answer 6 · Mon Sep 14 2020 20:47:46 GMT+0800 (China Standard Time)

Yes, this is worth revisiting now that perl5 itself is now hosted here; we can probably look at https://github.com/Perl/perl5/releases to get update info (and probably have some additional tooling there so that https://github.com/Perl/perl5/releases/latest can point to the right new version.)

Wesley Schwengle · Answer 7 · Sun Nov 01 2020 00:29:46 GMT+0800 (China Standard Time)

There is CPAN::Perl::Releases[1] which can give you some information about where you can download the tarball. It does not give you the checksum. But I think that is just a PR away to include that information. You can than automate much of the generation of the configuration and even make it smaller because most of the info can be found in the module.

[1] https://metacpan.org/pod/CPAN::Perl::Releases

mohawk2 · Answer 8 · Wed Nov 04 2020 05:22:10 GMT+0800 (China Standard Time)

It might be worth thinking about using the MetaCPAN API to get all available Perl versions (it might take a feature request, but ought to be straightforward). Also I'd think about using GitHub Actions (which can be triggered periodically) rather than the basically defunct Travis CI.

Zak B. Elep · Answer 9 · Sun Aug 07 2022 00:57:32 GMT+0800 (China Standard Time)

Thanks, probably high time to revisit this - we can have a GH action that can be scheduled or triggered to produce the PR needed for updating against a new Perl version.