Remove the old bootstrap scripts, which have been subsumed into letsencrypt-auto-source/pieces/bootstrappers. They no longer need to be dispatched among manually: everyone can just run letsencrypt-auto --os-packages-only, regardless of OS.
Make the root-level le-auto a symlink to the canonical version. It should thus still work for people running le-auto from a git checkout.
* We choose a different Travis infra for one of the jobs, as in https://github.com/numpy/numpy/blob/master/.travis.yml#L49.
* We keep the language as "python" so the installation of packages (like tox, which we need) doesn't fail.
* Override the before_install to disable the dpkg stuff the other jobs need.
* adduser is redundant with `--groups sudo` above, so we delete it.
Despite its description,
https://github.com/letsencrypt/letsencrypt/pull/630, removed not only
Python 2.6 support, but also Travis tests against Python 3. ACME
library supports Python 3 and Travis should tests it.
This must be merged before any pending PRs agains acme library.
This prevents the integration tests from getting run before the boulder
processes have finished booting in most cases. There's still some small
races with debug ports going up before RPC ports, but this flushes the
big ones (specifically, the WFE ports), and the boulder devs going to
fix the rest in integration-test.py over time.
This also makes boulder-start.sh a blocking operation. Now the TravisCI
integration tests no longer requires boulder-start.sh, we can let the
other priority of being easier for users to control (that is, basically,
make it easy to Ctrl-C) take over. That plus the idea that
self-daemonizing code is tricky to get right, especially over multiple
platforms led me to not trying to get start.py to make itself
asynchronous.
Most of this change is code movement in order to allow developers to run
boulder-start.sh once and boulder-integration.sh many times while also
not duplicating that code in order to run the tests in TravisCI.
I'm not a huge fan of both the letsencrypt's shell scripts and boulder's
integration-test.py having hard-coded file dependencies in the other's
repo.
This, however, seemed like the smallest path to code that would
spuriously break less. All the designs I was able to come up that were
maybe smaller changes either had the "starts tests before the servers
are up" problem or with a "each repo uses another repo's test code file"
problem. Those problem on top of the "it's a bigger change" problem led
me here.
Peter Eckersley