travis-racket
travis-racket copied to clipboard
greghendershott
Work with the travis docker infra
This requires:
- not using
sudo - not downloading for
www.cs.utah.edu(see travis-ci/travis-ci#3012)
- IME on Linux the Racket install.sh needs sudo (at least for the default target directories target option). But trying it just now, looks like the Travis env doesn't need sudo after all. So that's easy.
- Not sure what you mean for me to do instead? Get a nightly build from elsewhere, and if so, where? (BTW that URL is only used when people have
HEADas one of the Racket versions in their build matrix.)
On 1, yes, you'd need to not install in /usr.
On 2, use the Northwestern snapshot server, http://plt.eecs.northwestern.edu/snapshots/
Do you mean substituting http://plt.eecs.northwestern.edu/snapshots/current/installers/racket-test-current-x86_64-linux-precise.sh?
That would be easy enough to change. I have some vague recollection of someone (Matthew?) suggesting that Utah is more reliable source of nightly builds than Northwestern. Maybe I misremember.
(I understand that the container format apparently doesn't work with Utah, at all. So obviously Northwestern is more reliable than 0%. :) But how about the status quo, non-container Travis approach? It would be shame to make that less reliable, for the sake of getting the container-based approach working at all. Kind of two steps forward, one back? At least that's my question/concern.)
On 1, yes, you'd need to not install in /usr.
Even simpler, actually it installed just fine to /usr without sudo, for me.
That run didn't take place on the container infra, though, so I don't know if it works there.
I don't think the Northwestern site is supposed to be less reliable -- they've been basically the same for me.
That run didn't take place on the container infra, though, so I don't know if it works there.
Good point. I'll test by adding sudo: false to the .travis.yml.
By the way, do you think that (the container infra) should simply be the default in my example .travis.yml? I ask because your issue here today is the first I've heard about the container infra, and the Travis docs I've read so far are a bit terse about the pros and cons. Maybe a related question would be to ask, why are you excited about using the container infra?
- It allows caching of generated/download files
- It seems to start sooner
- It seems like it is inevitably the future of everything :)
I don't think you should make it the default, though.
It seems like it is inevitably the future of everything :)
pavlov rings bell dog salivates interwebs say "docker" dev salivates
So I made a mistake with my experiment. Fixing that, it turns out that sudo is indeed required for install to /usr in traditional Travis CI environment (which in hindsight makes sense).
So to avoid sudo, have to install elsewhere.
However people's existing .travis.yml files have lines like /usr/racket/bin/raco test. So changing the Racket install location will break those. So I need some backward compatability strategy. Which I can't figure out right now, so I'm going to have to set this aside at least for the very near future.
Well, step 1 would probably be to configure the PATH in the script so that people don't have to hardcode paths.
In the current state, one option would be a command line option, and another would be a separate script.
Yes but I'd tried that originally (when first setting this up 18 months ago) but I wasn't able to change PATH in install-racket.sh in a way that persisted for use back up in .travis.yml.
What definitely works is having the .travis.yml set an env var like RACKET_INSTALL_DIR that is used by the child install-racket.sh. That's why I'm experimenting with already on a topic branch.
(And if RACKET_INSTALL_DIR isn't set at all, then it must be an older .travis.yml, and we default it to /usr/racket and do use sudo. Otherwise we don't use sudo. Something like that.)
So I went many rounds on this, partly due to my own dumb mistakes. Although I haven't yet merged it to master, here's where I ended up.
What I didn't explore was caching specific directories. According to "things not to cache":
The cache's purpose is to make installing language-specific dependencies easy and fast, so everything related to tools like Bundler, pip, Composer, npm, Gradle, Maven, is what should go into the cache.
For other things, the cache won't be an improvement. Installing them usually takes only short amounts of time, but downloading them will be the same speed when pulled from the cache as it will be from their original source. You possibly won't see a speedup putting them into the cache.
I don't know what falls into this category, for all Racket projects, that I should put in the example .travis.yml? If you do please let me know.
But at least people should be able to set sudo: false in their .travis.yml (and install-racket.sh will support that), and also add a cache: directories: hash map for directories they know should be cached for their project. IIUC.
This issue got closed from a commit message, but since the example travis.yml doesn't talk about using cache: directories I'm reopening it.
One thing I'm confused about, is how caching is supposed to work with the HEAD build target, which corresponds to the nightly snapshot builds.
In other words you probably do not want cache: directories when RACKET_VERSION = HEAD.
Always grateful for improvements, but inasmuch as my question sort of led to reopening this issue, please don’t feel that you need to investigate on my account. travis-racket works great as is. Thank you for the work you’ve already done. Obviously, it was easy to point at mirror.racket-lang.org to avoid costing PLT bandwidth. Instead, my Travis builds will be paid for by students at Northeastern, who will experience slightly choppier video while streaming “Game of Thrones.”
One other thing to cache here is the downloaded racket installers themselves for released versions, which would speed up some builds a lot.
Probably this should be the default these days -- they seem to be discouraging the old infrastructure.
Probably this should be the default these days -- they seem to be discouraging the old infrastructure.
I could uncomment this line.
Is that in your opinion sufficient? If not, could you submit a PR?
I don't have a lot of time to work on this, at the moment.
Yeah, that seems sufficient.
FWIW, I’ve had the sudo: false line uncommented in all my .travis.yml files for a while (for instance), and the Racket installers still get downloaded afresh for each build. I say this not to impose work on @greghendershott, but rather as a counterpoint to @samth’s theory.
I stand corrected. I’ve been observing my Travis builds this weekend. The Racket installer “download” now takes only 7-10 secs for each build, which means the installers must be getting cached locally.