Create a new Travis environment about ecosystem HOT 28 CLOSED

It takes hw and administration. For the needs we have at the moment, I think travis+appveyor suffice. KISS :)

from ecosystem.

Any solution that requires building Rakudo and co. from source doesn't solve Rakudobrew's problem that triggered this ticket.

from ecosystem.

Then, of course, using rakudobrew which is discouraged.

I don't think that using rakudobrew is by itself a problem. It's not used to switch between dev commits, just for building a release. Pretty static setup.

from ecosystem.

Somewhat of an aside, what about, in addition to Travis, set up something like Jenkins and get volunteers to contribute build testing on other platforms?

Note there are companies that host Solaris and IBM systems that might be interested in contributing as sponsors, too.

from ecosystem.

@Tyil I am experimenting with bintray to create a deb repo for the packages, but at the moment it's pretty much working in progress. This would simplify things considerably.

from ecosystem.

Some random points:

• Great idea. Using the travis builtin perl6 support is painful pushed some people to already use Rakudo packages in travis.
• What is the intended result? A matrix of released version so that people can do something like this?

- language: perl6
- perl6:
  - 2018.03.x
  - 2018.02.x
  ...
  - 2015.12.x

Rakudo releases monthly, so in comparison with, e.g., Perl and Go, today we have a lot of releases (already 25+ releases available since "Christmas").

• Testing only against the latest release? Or include a default "latest" version above?
• Will the .travis.yml of the distribution take care of extra binary dependencies? It should.
• If we go for a version matrix, I don't think that a container will be a good fit. It will result on a download of 200mb-500mb for every version to be tested. This will not be cached between runs. There may be a way to do that, but we're talking about a lot of storage.
• Packages are around 5-8mb, but the version we have start from end 2016. Older packages can be created, but I don't know if it's worth it (some Rakudo breaking changes since then).
• Maybe a package repo would be handy, but I haven't had the time to figure it out how to buld it automatically by Travis and upload to a JFrog repo. On my TODO list.

from ecosystem.

rakudobrew doesn't generally build rakudo releases (which is probably what we should be testing against rather than what happens to be in git at the time). There are alternatives which do (eg. rakudup)

We probably should be testing on other OSes than Linux. Currently OS X is also supported by Travis https://docs.travis-ci.com/user/multi-os/ While the Windows roast tests fail there is probably little point in testing on appveyor)

If you add docker or linux package use you will make it linux specific! I don't really see any advantage in making the build faster.

from ecosystem.

from ecosystem.

@nxadm

Older packages can be created, but I don't know if it's worth it

FWIW whateverable goes up to 2014.01 without any issues. The only issue for it was the lack of --git-reference which you don't need to use if you're building just releases. It's easier than it sounds :)

from ecosystem.

from ecosystem.

It wouldn't work with Star since the travis build needs IO::Socket::SSL which isn't in Star because it has to ship on Windows (which won't have the openssl ddl).

Neither are there any cross platform star binary packages (apart from maybe the linux appimage ones).

I think you are stuck with scripted source builds which should be the last monthly release.

You can get the last release with something like

https://github.com/rakudup/rakudup.github.io/blob/master/rakudup#L31

from ecosystem.

from ecosystem.

FWIW whateverable goes up to 2014.01 without any issues. The only issue for it was the lack of --git-reference which you don't need to use if you're building just releases. It's easier than it sounds :)

@AlexDaniel, yes, certainly an option. How big is the stored installation that needs to be retrieved, how long does it take to unpack and what tools are needed?

from ecosystem.

from ecosystem.

Travis has Linux and MacOS covered, while appveyour works on Windows (and nowadays Linux). What's the usecase for Jenkins? I am not against it (we use it at $work), but I don't see the added value in this case.

from ecosystem.

from ecosystem.

from ecosystem.

I'd suggest to update the community supported version currently in Travis to use the packages from @nxadm . This is easiest to work with for all module developers and speeds up the testing process considerably.

If that is not an option, I have a .travis.yml configuration that downloads the packages and installs them:

language: generic

env:
  global:
    - PATH=/opt/rakudo-pkg/bin:$PATH
  matrix:
    - VERSION=2018.03-01
    - VERSION=2018.02.1-01 TAG=v2018.02.1

os:
  - linux

before_install:
  - sudo apt-get -qq update
  - cd $(mktemp -d)
  - wget "https://github.com/nxadm/rakudo-pkg/releases/download/${TAG:-v${VERSION}}/rakudo-pkg-Ubuntu14.04_${VERSION}_amd64.deb" && sudo dpkg -i *.deb
  - cd -

install:
  - zef install --deps-only .

script: AUTHOR_TESTING=1 prove -v -e "perl6 -Ilib" t/

# vim: et ts=2 sw=2

The matrix allows for multiple testing targets. If the tag and release version name differ, these need to be supplied. If the tag and the version name are the same, only the VERSION is mandatory.

The apt-get update is not necessary I believe, in case you want to skip some extra waiting.

Also, I've only tested this with GNU+Linux as an OS target.

from ecosystem.

from ecosystem.

@JJ Sure, it's certainly doable without a repo. A repo feels less hacky (e.g. files names and download paths are not longer hardcoded while the project progresses).

I am just "recycling" the effort to also offer to regular users. For the travis setup I see two advantages:

• gpg signing instead of sha (most people don't bother checking it).
• no need to keep track of package revisions, you'll always get the last. (Revisions: new versions of the packages not triggered by a new version of Rakudo, e.g. a bug fix.).

That said, reconstruing download urls today is still better than a repo tomorrow.

from ecosystem.

Not related, hence a new comment.

I would also limit the offered packages to the latest dot release of a version, like e.g. 2018.05.3, because they only fix bugs. So, e.g.

• 2018.05.x -> 2018.05.3
• 2018.04.x -> 2018.04 (no dot releases for that version).

from ecosystem.

from ecosystem.

I agree with defaulting to the latest patch release, since less bugs is generally preferred.

from ecosystem.

Make sure to use Travis caching. Helps A LOT with multiple runs.

from ecosystem.

So are we in for this? Should I try to substitute the existing version? Or maybe try to introduce a new "Perl 6 Rakudo Star" edition?

from ecosystem.

from ecosystem.

Once the 2018.04.1 is out (2018.04 fails on i386) and I release the new packages, there will be a deb repo that Travis can use. The repo will have all the releases from 2018.04.1 onwards.

So, in order to use the latest rakudo, this will do:

$ sudo apt-get install rakudo-pkg

In order to install a specific version:

$ sudo apt-get install rakudo-pkg=2018.04.1

So what the travis repo code would need to do is some sause to convert the matrix version notation to the
commands above. See the repo info (once 2018.04.1 is out it will move to master). The Zef-as-user remark can be ignored as it is supplied for the root user on the global dir. The PATH remark still applies. I would just adapt the PATH as explained on the page, although a script is supplied to do it as well.

from ecosystem.

from ecosystem.