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
A new take on reducing travis test time for perl6/doc #1946
Comments
|
Thought: this will break if we ever change the required modules list (at least until the package is then updated) |
|
It depends. The pkg takes the modules list directly from the repo, so a new package needs to be respinned. Just bumping the revision to "02" will trigger the build for a new package that will obsolete the previous one. It can be probably automated if changing dependencies is something that happens often. The question is what more important:
I think option 2 is more applicable for a CI system, but I understand the argument for option 1. |
|
The current test includes a docker container that already packs all required modules, and will break as soon as we change it. The whateverable binary, on the other hands, installs them and it takes some time. I'll put this one for testing in the shippable version (in #1931) first. |
|
And thanks a lot, @nxadm , for preparing this. |
Why can't we have both? Surely it can install modules that are not installed on the fly? |
|
@AlexDaniel |
|
2018-04-21 10:58 GMT+02:00 Aleks-Daniel Jakimenko-Aleksejev <
notifications@github.com>:
- the dynamism of adding module dependencies on the fly.
- or shave some minutes (I didn't time it, but building the deps takes
a long time) for every commit.
Why can't we have both? Surely it can install modules that are not
installed on the fly?
Theoretically, we should have achieved that using shippable's cache. I
couldn't make it work, however.
Anyway, the Whateverable version does add modules on the fly, so we can
have the cake and eat it too with the matrix.
|
|
Installing modules takes around 4 minutes, however. If we really want to
make it faster, that's our next frontier.
We still have the fallback option, and we can also have rakudobrew built
for us. But having a fast response, for PRs for instance, makes all the
difference.
|
|
Instruction could be amended to: env:
global:
- PATH="/opt/rakudo-pkg-for-doc/bin:/opt/rakudo-pkg-for-doc/share/perl6/site/bin:$PATH"
sudo: required
install:
- sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 379CE192D401AB61
- echo "deb https://dl.bintray.com/nxadm/perl6-doc trusty main" | sudo tee -a /etc/apt/sources.list
- sudo apt-get update && sudo apt-get install rakudo-pkg-for-doc
- sudo zef --deps-only install . |
|
(All the commands besides the path, could be added in a script) |
|
But that will basically save the time for installing |
|
zef will not install what's already installed. I suppose it won't upgrade
modules either.
|
|
2018-04-21 11:53 GMT+02:00 nxadm <notifications@github.com>:
zef will not install what's already installed. I suppose it won't upgrade
modules either.
Ah, OK. I'll try that then.
|
|
If we want to actually process test logs, we need TAP::Formatter::Junit and thus cpanm. Check this out https://app.shippable.com/github/JJ/doc/runs/24/1/console |
|
It takes now 4 minutes more with the installation of cpanminus and the new module added... |
|
TAP::Formatter::Junit 0.09 is part of Ubuntu trusty: https://packages.ubuntu.com/trusty/libtap-formatter-junit-perl Will that version do? In case it does: sudo apt-get install libtap-formatter-junit-perl |
|
Um, right. That will do. Will test.
|
|
It's definitely faster than downloading cpanm and installing all the modules, but that little module has got a whole lot of dependencies that also take time to download. |
On issue #1765 some options were implemented:
I propose a new take that, in my view, is easier to maintain and probably faster: a deb package containing rakudo, zef and all the perl6 modules specified in the META6.json of this repo.
To use this package, this need to be added to a .travis.yml file:
There is no need to specify a version, you'll always get the latest released Rakudo.
If this solution proofs itself useful, a new package will be created and automatically uploaded to the repo by travis for every Rakudo release.
The automation of the pkg creation and repo upload are handled in this repo:
https://github.com/nxadm/rakudo-pkg-for-doc
cc: @JJ
The text was updated successfully, but these errors were encountered: