Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Travis otp vsns #295

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
5 participants
Contributor

tuncer commented Jun 11, 2014

Try out some otp version changes in .travis.yml.

Contributor

ferd commented Jun 11, 2014

One version per release doesn't always work when features are added during the entire cycle. In this case, testing a late version may not show that a thing that was broken, say in R16B as part of its breaking release, and was then fixed or modified in R16B03 if that's the only version we test.

This includes things like regressions, new features (we can't say we support versions RXXB* are if we only test RXXB03), and so on.

Contributor

tuncer commented Jun 11, 2014

Should we include all minor versions then?

Contributor

ferd commented Jun 11, 2014

That would be my guess, if we want to say we support all of the minor versions.

Contributor

tuncer commented Jun 12, 2014

Also, the test didn't seem to work. I cannot see travis-ci results here, and there's no mention of the pull request on travis-ci. Any idea?

Member

tsloughter commented Jun 14, 2014

I think we should also keep all minor versions. I'll look at why travis isn't running this.

Member

tsloughter commented Jun 14, 2014

Actually, I bet it doesn't build because anyone can then update the travis config, create a PR and it run in travis. That is my guess, trying to verify.

Member

tsloughter commented Jun 14, 2014

It looks like the ones you added aren't available on travis: https://travis-ci.org/rebar/rebar/builds/27577634

I think we should just close this ticket now.

Contributor

tuncer commented Jun 14, 2014

Shouldn't we report this and get it fixed at travis-ci.org?

Member

tsloughter commented Jun 14, 2014

It just takes them time before new Erlang versions work, but yes, we can poke them to try to get it added sooner. As for R13, I don't know why we need it, and probably less likely to get them to add.

Contributor

tuncer commented Jun 15, 2014

It just takes them time before new Erlang versions work, but yes, we can poke them to try to get it added sooner.

To match the old public otp versions, we should probably only add 17.0 and 17.1 anyway.

As for R13, I don't know why we need it, and probably less likely to get them to add.

travis-ci uses and supports rebar for Erlang projects, so why not?

@ferd ferd added the enhancement label Jun 15, 2014

@BanzaiMan BanzaiMan referenced this pull request in travis-ci/travis-ci Sep 4, 2014

Closed

Consider adding older Erlang OTP Releases #2757

If you are still interested in testing with old OTP Releases on Travis, we just deployed on-demand installations of OTP Releases not pre-installed. Some versions are now available for builds. (See travis-ci/travis-ci#2757 (comment) for details.)

Contributor

tuncer commented Jul 7, 2015

@BanzaiMan, thanks, yes, we're still interested. Is there anything I have to do besides changing otp_release in .travis.yml?

@tuncer Besides setting otp_release: values, nothing is required. If the specified release is not pre-installed, it will be installed. (It may or may not work, depending on whether or not the archive is available; R14B01 is not, because the build process seg faults.)

Contributor

tuncer commented Jul 7, 2015

Are you sure the builds have been uploaded? This is what I get for R14B02, R14B, R13B04, R13B03:

The command "wget https://s3.amazonaws.com/travis-otp-releases
/ubuntu/$(lsb_release -rs)/erlang-R14B-x86_64.tar.bz2"
failed and exited with 8

ah. sorry. I need to change the file permissions.

Try again now.

Contributor

tuncer commented Jul 7, 2015

Okay, will do. What version of OTP did you use to build the rebar binary for travis-ci? For absolute compatibility, use R13B03 or R13B04.

Contributor

tuncer commented Jul 9, 2015

@BanzaiMan can you switch the travis-ci kerl process to fetch git tags (releases) instead? That way we can access all OTP releases, including those which haven't been released as tarballs on http://erlang.org. That will solve the issue of missing OTP versions. For the missing 17.2 you would do this:

kerl build-install git https://github.com/erlang/otp.git OTP-17.2 17.2

@tuncer I'm not sure if that is a good idea. Building on the fly will add several minutes. As for 17.2, kerl does not recognize as a valid release name.

Contributor

ferd commented Jul 9, 2015

Yeah I'll have to agree. Building on the fly can easily take 15-20 minutes, and we just doubled the number of versions to test.

BTW, I've also built R13B02, 03 and 04. Those are available for on-demand installation.

Contributor

tuncer commented Jul 10, 2015

@BanzaiMan didn't you say on-demand builds will be cached the same way as the ones you built manually?

We can limit it to tarballs on erlang.org, but not all official releases are available that way. kerl could download a tarball for a git tag instead, if git clone is a concern, but someone has to modify kerl for that. Since git tags can be downloaded as tarballs, it seems logical to use that instead of detecting available releases with a regex applied to the erlang.org download folder listing.

To be clear, @ferd and @tsloughter suggested to test against all versions, so I completed the list. That said, I don't mind keeping the list short by, for example, testing only against each minor release (17.5.6.2, 18.0.2, etc.).

@tuncer I think there was a misunderstanding. The on-demand installation will pull the archive that https://github.com/travis-ci/travis-erlang-builder builds (which is a manual process) and uploads to our S3 bucket. My understanding is that kerl build pulls source from erlang.org when it builds.

Building from git via kerl doesn't sound like a good idea, if the resulting archive is not an official release, as this is meant for testing by Erlang users at large. If you need to test against specific tag on the git repo, then you are welcome to use kerl build-install git … as you indicated, but you are responsible for managing the runtimes.

Contributor

tuncer commented Jul 11, 2015

@tuncer I think there was a misunderstanding. The on-demand installation will pull the archive that https://github.com/travis-ci/travis-erlang-builder builds (which is a manual process) and uploads to our S3 bucket. My understanding is that kerl build pulls source from erlang.org when it builds.

Okay.

Building from git via kerl doesn't sound like a good idea, if the resulting archive is not an official release, as this is meant for testing by Erlang users at large. If you need to test against specific tag on the git repo, then you are welcome to use kerl build-install git … as you indicated, but you are responsible for managing the runtimes.

The OTP team does not make official releases with Windows installers for each minor release, and that's why some releases are missing on http://erlang.org. The tags (https://github.com/erlang/otp/releases) are official releases and the only way to access them all. Strictly speaking, kerl is broken and does not support the new versioning scheme (since 17.0). That's also why it misses many releases. Therefore, until kerl starts fetching tarballs from github (like https://github.com/erlang/otp/archive/OTP-18.0.2.tar.gz), the reasonable thing to do is building and archiving the official releases via kerl build-install git....

Also, now that there's R13B03 on travis-ci, can you please rebuild the rebar binary (used by everybody on travis-ci) with that old release? That's important for the binary (and the included .beam files) to work with all otp releases.

Contributor

lrascao commented Feb 12, 2016

i've looked into this, apparently Travis doesn't use kerl to obtain OTP versions, it just downloads them from an S3 bucket, build #1 (https://travis-ci.org/lrascao/rebar/builds/108782313) shows this, maybe bug the Travis guys?

Contributor

tuncer commented Feb 12, 2016

@lrascao, yes, according to @BanzaiMan, prebuilt otp installations are stored on S3, but as kerl does not pick up all releases, we don't have access to those. First kerl needs to be fixed, or Travis-CI has to use a different mechanism to build OTP.

Contributor

tuncer commented Feb 13, 2016

Contributor

tuncer commented May 3, 2016 edited

@BanzaiMan, can you upgrade travis-ci's kerl now that kerl/kerl#122 has been merged? It will give you access to all releases by relying on git tags. This way, we will finally be able to use each and every official release, not just those that went through the special process which produces archives in erlang.org/download. Once that's updated, and you've prepared builds for all tags, all Erlang projects can use them in .travis.yml.

Currently, we do not rely on kerl to determine which versions of OTP Releases are available. Making changes to the mechanism is not trivial, and will take some time.

Contributor

tuncer commented May 14, 2016 edited

@BanzaiMan, is it in one of the travis-ci open source projects, and can it be fixed sooner by an external contribution?

Contributor

tuncer commented May 14, 2016 edited

@BanzaiMan, to be clear, you built+archived the available OTP releases with kerl, but you didn't use it to decide which ones should be. Is that correct?

Contributor

tuncer commented Aug 18, 2017

Closing due to silence from Travis-CI team.

@tuncer tuncer closed this Aug 18, 2017

@tuncer tuncer deleted the tuncer:travis-otp-vsns branch Aug 18, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment