[#2129] make evm and cask setup more reliable in travis

[gonewest818]

Resolves [#2129] with new scripts to setup evm and cask in Travis builds.

These scripts improve on the prior process by adding error detection with
retries, such that network errors during this setup stage are less likely to
abort the build with mysterious errors.

In addition to the retry logic, we also cache the installations of evm and cask
such that the contents of those directories are restored across successful
builds. This eliminates the requirement to install evm and cask from scratch. It
is possible to force-delete these caches if needed.

The net result of all this is, most incremental builds need only attempt to
update evm and cask (essentially a git pull) and update any needed elisp
packages via cask update.

---

Before submitting the PR make sure the following things have been done (and denote this
by checking the relevant checkboxes):

• The commits are consistent with our contribution guidelines
• [n/a] You've added tests (if possible) to cover your change(s)
• All tests are passing (make test)
• [n/a] The new code is not generating bytecode or M-x checkdoc warnings
• [n/a] You've updated the changelog (if adding/changing user-visible functionality)
• [n/a] You've updated the readme (if adding/changing user-visible functionality)
• [n/a] You've updated the refcard (if you made changes to the commands listed there)

Thanks!

If you're just starting out to hack on CIDER you might find this section of its
manual extremely useful.

[gonewest818]

by the way, you have probably been ignoring travis because it's been so broken, but I want to brag about the fact the build errors on this branch are now all completely legitimate issues to be dealt with.

[xiongtx]

Can you explain why we need this retry logic? I recall (a long time ago in a galaxy far far away) that CI used to work reliably without this. Is the problem w/ @travis-ci, EVM, or Cask?

[gonewest818]

I can’t completely explain why, but I’ve definitely seen the results of broken connections in various stages of the build, and for instance if the “cask install” fails to properly install the elisp package, or the files are corrupted in transit (I’ve seen that happen) then the build is hosed. The retry logic is really about making the package install idempotent. Either it installs properly or it is deleted without a trace, so that the next install starts from a clean slate. After three failed retries the job will abort just as before. I will also say, I’ve never seen a failure with “apt-get” type package installs. I suspect Travis might have mirrors for the deb packages to avoid excessive (and rather repetitive) inbound traffic related to jobs setting themselves up. So in that regard evm and cask are probably not benefitting from any kind of mirror - they’re just installing themselves plus all their package dependencies over the internet, over and over in each job. And this change tries to minimize the impact of that.

…

On Dec 14, 2017, at 11:43 AM, Tianxiang Xiong ***@***.***> wrote: Can you explain why we need this retry logic? I recall (a long time ago in a galaxy far far away) that CI used to work reliably without this. Is the problem w/ @travis-ci <https://github.com/travis-ci>, EVM, or Cask? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2139 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACWM9jLTketdJ00eii-GwV1fdTOyu9MVks5tAXp7gaJpZM4RBf4y>.

[gonewest818]

Here's a concrete example from the build https://travis-ci.org/clojure-emacs/cider/jobs/316281526

At the tail of the log it says:

Symbol's value as variable is void: -
Cask could not be bootstrapped. Try again later, or report an issue at https://github.com/cask/cask/issues
The command "curl -fsSkL https://gist.github.com/rejeep/ebcd57c3af83b049833b/raw > x.sh && source ./x.sh" failed and exited with 1 during .

And a little ways before that in the log it says:

Compiling /home/travis/.emacs.d/.cask/24.3/bootstrap/commander-20140120.1052/commander.el...

In toplevel form:
commander.el:512:1:Warning: reference to free variable `-'
commander.el:512:3:Warning: reference to free variable `Peer'
commander.el:512:8:Warning: reference to free variable `has'
commander.el:512:12:Warning: reference to free variable `closed'
commander.el:512:19:Warning: reference to free variable `the'
commander.el:512:23:Warning: reference to free variable `GnuTLS'
commander.el:512:30:Warning: reference to free variable `connection'
Wrote /home/travis/.emacs.d/.cask/24.3/bootstrap/commander-20140120.1052/commander.elc

Which is sort of amusing if it weren't so annoying.

Does Travis need to fix their infrastructure? Should the underlying emacs packaging system prevent this this sort of file corruption? Should cask be more resilient? Should every project need to patch over this in the way I did? Yes, yes, maybe and definitely no.

Should cask be thrown out because of this? Up to you, but this gives you reliable builds while you sort out your desired strategy for this.

[xiongtx]

commander.el:512:1:Warning: reference to free variable `-'
commander.el:512:3:Warning: reference to free variable `Peer'
commander.el:512:8:Warning: reference to free variable `has'
commander.el:512:12:Warning: reference to free variable `closed'
commander.el:512:19:Warning: reference to free variable `the'
commander.el:512:23:Warning: reference to free variable `GnuTLS'
commander.el:512:30:Warning: reference to free variable `connection'

It seems the problem is still w/ GnuTLS? Is the closed connection a problem w/ @travis-ci? Does it happen every time?

[gonewest818]

As mentioned in #2120 and #2129, it’s intermittent. Note that before pull request #2128 (fixed #2120 ) gnutls wasn’t even installed in your build jobs — so it’s not likely gnutls is the root cause of these intermittent errors.

…

On Dec 14, 2017, at 6:12 PM, Tianxiang Xiong ***@***.***> wrote: commander.el:512:1:Warning: reference to free variable `-' commander.el:512:3:Warning: reference to free variable `Peer' commander.el:512:8:Warning: reference to free variable `has' commander.el:512:12:Warning: reference to free variable `closed' commander.el:512:19:Warning: reference to free variable `the' commander.el:512:23:Warning: reference to free variable `GnuTLS' commander.el:512:30:Warning: reference to free variable `connection' It seems the problem is still w/ GnuTLS? Is the closed connection a problem w/ @travis-ci? Does it happen every time? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[bbatsov]

Should cask be thrown out because of this? Up to you, but this gives you reliable builds while you sort out your desired strategy for this.

Likely yes. As I said - the project is mostly abandonware at this point and betting on it, doesn't seem particularly wise. Anyways, I appreciate every step in the direction of stable CI builds!

Thanks for working on this!