Use language: julia in default Travis #8744
Conversation
|
+1, especially since this falls back to Linux-only testing with no user support. Nice work, @tkelman |
|
There are some corner cases that can make the script do strange things, so I don't recommend it for anything beyond Travis use at this point, but it should serve that particular purpose fairly well. May as well centralize the platform-dependent code in one place rather than in every package's travis config. |
|
Nice |
|
Shouldn't we just download the whole also: @JuliaBackports? |
|
I don't know whether there's any advantage to moving the default yml template to a separate repository, there's no benefit for it to live at some short url. Some type of automatic detection of old idioms in .travis.yml files of existing packages would be nice, but maybe difficult. Often packages may need to manually customize that file to install some distribution packages, etc. Not sure what's best to do there - perhaps just scraping the existing yml's and collecting some statistics on what they look like in terms of age and how modified they are? |
|
I'm 👎 on doing anything fancy with the |
|
How about a Pkg.update_travis_yml(pkg) function? On Wednesday, October 22, 2014, Iain Dunning [email protected]
|
|
Sure, but I feel like its worth having some of your own understanding of what is going on in the only bit of the |
|
On a somewhat related note, one wonders how big of a community we have to be before we could realistically start talking with someone at Travis about adding a first-class |
|
I think we can ask them for this already. |
|
Looks like it might just take a relatively simple PR to https://github.com/travis-ci/travis-build - the closed one for Rust and an open one for C# don't look that complicated. I'm not quite sure what's going on in the |
|
I submitted a PR to travis-build over the weekend and Julia support is well on the way. @tkelman: Can you confirm that http:https://status.julialang.org/stable, that you used in the install script, will be maintained as a URL for the latest stable release? I just thought I should confirm this since it is not used at http:https://julialang.org/downloads/. |
|
Awesome, thanks! You should've cc'ed me on that, would've liked to watch as you worked on it. |
|
So the question is whether we want to use the PPA, or the generic binaries. The binaries don't need sudo to install, but they're very recent and not yet very widely used. |
My apologies, I was not sure how long it would take and spent most of the time wrestling with RSpec.
I agree about the PPAs being more along the lines of what we have been doing with Julia. But if the people over at Travis wants us to refrain from requiring root access I do not see any good alternative. |
|
Also, before I forget, we really need to find a way not to serve Julia over HTTP, but rather over HTTPS. |
|
Yeah, @staticfloat is in charge of status.julialang.org, I have no idea how hard it would be to use https for it (also the install script, if we want to use it). |
|
Those "stable" links will remain stable. ;) https will take a little bit of time, (have to generate a certificate) but is totally doable. |
|
I just thought of a big reason not to host Failing that, I can get HTTPS working on |
|
Alright, everything on status.julialang.org should now be encrypted. HTTP should redirect to HTTPS transparently. I also took the liberty of hosting |
|
Seems like a hash hosted on the same encrypted host is just more for you to screw up? I think we should rather/also host it on the github site |
|
This hash isn't really meant to protect against attackers. If they've compromised |
|
@staticfloat: Awesome! Thanks for the good work. About the hashes, agreed, hashes are to mitigate corruption. If you want security, you need signatures. |
|
@staticfloat: Apologies for slightly hijacking the issue. A while ago, over at the Travis PR, it was requested that we added community maintainers. For now, this is @tkelman and myself. However, given that you are the one performing the actual builds, would you also be interested in being added as a maintainer so that you get notified immediately if something goes wrong? |
|
Sure, that's fine. |
|
No worries on hijacking the issue, this should be redone and simplified quite a bit once Travis rolls out the Julia support anyway. sorta related but not really, @staticfloat is something up with libgfortran on the travis osx builds today? |
|
Yes. |
|
Bottles are fixed now. |
tkelman
force-pushed
the
tk/default-travis-multi-os
branch
from
0242e4e
to
c764722
Compare
and add the os: section for mac testing (has to be explicitly enabled by sending an email to [email protected], see http:https://docs.travis-ci.com/user/multi-os )
tkelman
force-pushed
the
tk/default-travis-multi-os
branch
from
c764722
to
6cb77aa
Compare
tkelman
changed the title
|
Redid this now that Travis supports I have the |
|
It took about a month and a half, but we got that PR accepted. Thanks to @tkelman for the code review and occasional poking of the Travis devs, it really helped. Also a big thanks to everyone handling the Travis docs. Should I wait before this PR is merged and backported before making an announcement over at julia-users/dev? |
|
@ninjin nah, this PR only matters for new packages, be my guest and announce on the mailing lists now in case anyone wants to adapt their existing packages. |
|
When you make the announcement remind people that run their custom test script to keep: before_install:
- if [[ -a .git/shallow ]]; then git fetch --unshallow; fiotherwise overriding script also seems to override the following section travis-ci/travis-build@88c78ff#diff-b9601304d9fc462f9637f2fdd13bd885R64 |
| - if [[ -a .git/shallow ]]; then git fetch --unshallow; fi | ||
| script: | ||
| - julia --check-bounds=yes -e 'versioninfo(); Pkg.init(); Pkg.clone(pwd()); Pkg.build("$pkg"); Pkg.test("$pkg")' | ||
| #script: |
There was a problem hiding this comment.
It might be a good idea to add a comment along the lines of "Uncomment these lines if you wish to override the default Travis script for Julia".
add explanatory comment
tkelman
force-pushed
the
tk/default-travis-multi-os
branch
from
9ce6ac8
to
9b4453a
Compare
|
Has |
|
I'm unaware of any registered projects using it as this point, but I haven't been getting my eyeballs on as many packages lately |
|
OpenCL.jl is using it currently and it cut down your travis test time from 5-6min to 2-3 |
|
@vchuravy you got an improvement in test running time out of it? That's awesome, I actually did not expect that. |
|
Yes, this is working great. +1 for merging. |
Use language: julia in default Travis
|
Are we ready to backport this? Seems to me like we want it before 0.3.4. |
|
Yes. AppVeyor's idle, you want to do it? |
Use language: julia in default .travis.yml and add the os: section for mac testing (has to be explicitly enabled by sending an email to [email protected], see http:https://docs.travis-ci.com/user/multi-os ) (cherry picked from commit 6cb77aa) add git fetch --unshallow in commented out script section add explanatory comment (cherry picked from commit 9b4453a) turn on coverage in commented-out script section (cherry picked from commit a92ea42)
|
Done in 5a18cc6 |
Edit 12/10/14: redid this to use the new
language: juliaformer content:
Ref #7364 and JuliaLang/www_old.julialang.org#151 - I put together a shell script to handle installing Julia binaries on different platforms, now I'm proposing to use it in the default
.travis.ymlfromPkg.generate. I've got a [otherwise unfinished] test package using this script across a matrix of linux and mac on both release and nightlies here, though it looks like the osx builds are going to be queued for a while.Also add the
os:section for osx testing (has to be explicitly enabled by sending an email to [email protected], see http:https://docs.travis-ci.com/user/multi-os, it doesn't do anything if it hasn't been enabled yet).