Update Travis configuration so that it does not compile Rakudo every single time.

[JJ]

The official Travis configuration for Perl 6 uses Rakudobrew to download from source and then compiles. Every single time.

We would need either

• Precompiled binaries we can download directly, with an URL that can be generated automatically from version.
• Docker containers. That might be tricky to install dependencies.

If there's any other option, or you prefer any of those above, please let us know.

[AlexDaniel]

Just for the record, whateverable builds are available publicly. For example: https://whateverable.6lang.org/HEAD. However, they're built with a very recent version of glibc so they don't work on Travis. Somebody has to do it properly, and I'm even ready to store them, but it'll take a few weeks to get the amount of builds I currently have for whateverable. Though maybe for Travis it doesn't matter.

[patrickbkr]

In most cases it makes sense to use a Rakudo release (in contrast to latest master) when testing a module. So given we actually start providing official binary builds of releases (I hope we do!), we could just use those in the Travis config.

[nxadm]

Here are instructions to use packages:
https://github.com/nxadm/rakudo-pkg#using-rakudo-pkg-on-travis

(All versions are present, so different version could be specified in a matrix.)

[patrickbkr]

Who has privileges to change the 'perl6' configuration?

We have two working solutions (docker containers that @JJ provides, and rakudo-pkg that @nxadm provides), so all that's needed is for someone to update the Travis configuration to use one of the two. Personally I'd go with rakudo-pkg, as it's the more conventional solution.

[nxadm]

Traditionally, a regular travis setup looks like this:

language: raku
raku:
- latest
# - 2019.x
- "2019.07.1"
- "2019.07"
- "2019.3"
...

However, if there one could also play with the prefix:

language: raku
raku:
# What regular users would probably use
- latest
- 2019.07.1
- 2018.03
# Advanced cases:
# from git
- branch-master
- branch-6f
# from docker
- docker-star:tag 

For my use case packages that include zef are enough, but maybe a more flexible system can be useful for some people.

[AlexDaniel]

Who has privileges to change the 'perl6' configuration?

@PatZim I guess I have that? Just tell me where to click :)

[AlexDaniel]

Oh wait, you probably mean the travis side… that I'm not sure :S

[nxadm]

Oh wait, you probably mean the travis side… that I'm not sure :S

I think the procedure is sending a PR to travis, but I am not sure who did the integration before (zoffix?).

[AlexDaniel]

Somewhere around here: https://github.com/search?q=org%3Atravis-ci+perl6&type=Code

[JJ]

@PatZim We need to create a PR in the Travis site. They are "community"-maintained configurations. In this case, since we'll be substituting the old one, maybe some additional check is needed, but we'll do it as we go.
Also, @github just set up its own CI integration suite. We might want to configure that, too... But that's another issue.

[patrickbkr]

@nxadm Are you actually ok with your packages becoming the official travis perl6 source? If yes I'll Soon start looking into getting a travis PR ready if no one beats me to it.

[nxadm]

@PatZim, before taking changes upstream (Travis & Github new CI thing, etc), I think it makes sense to wait for the result of #89. I will certainly be more confident to offer a commitment once the renaming is decided.

[JJ]

Renaming (and its results) can take time, and once it's done, it's better if we create _new_ configurations, leaving the old one for some time, instead of just substituting it. Remember, perl6 installations are not going to disappear overnight.