Just wondering if there is added value in enhancing this widely used and very handy workfow to cache the download of rakudo.
The aim would be to make workflows that use "setup-raku" more robust, efficient and faster, as setup-raku would always "deliver" (except on first time runs, as nothing is cached yet), preventing not needed downloads and work even when http://rakudo.org/ is offline or slow.
Here it is suggested, to reload on dependency changes only, so maybe only fetch when the calculated download URL changes (compared to the cached version) AND $URL is reachable AND download is finished in less than Timeout (e.g. 5 seconds)? In all other cases we stay with the cached version of rakudo.
GitHub might be doing this automatically. The first time I ran my workflow, it took 35 seconds to download and install Raku. I don't know how long it's cached for, but now it's nearly instantaneous.
Just wondering if there is added value in enhancing this widely used and very handy workfow to cache the download of rakudo.
The aim would be to make workflows that use "setup-raku" more robust, efficient and faster, as setup-raku would always "deliver" (except on first time runs, as nothing is cached yet), preventing not needed downloads and work even when http://rakudo.org/ is offline or slow.
Here it is suggested, to reload on dependency changes only, so maybe only fetch when the calculated download URL changes (compared to the cached version) AND $URL is reachable AND download is finished in less than Timeout (e.g. 5 seconds)? In all other cases we stay with the cached version of rakudo.
with e.g. $URL = http://rakudo.org/dl/rakudo/rakudo-moar-2023.10-02-macos-x86_64-clang.tar.gz
Maybe something is this direction?