The changes to use an existing key depended on Node 0.12, but Travis provides
Node 0.10 (unless you specify language: node and a version, but we have
language: go).
This gets us down to 5-6 minute build times.
A new script had to be added to run make conditionally without allowing
builds with make failures to pass.
Always pass Content-Length header
Always use tls: true
Don't write terms of service contents to terminal: it might be a PDF
Separate out signing, posting, and printing code into acme.js
Use acme.js in revoke.js for better error reporting.
Check for PEM passed to revoke.js.
This is in response to some trouble JC had using the client to test in prod. In
particular, Akamai insists on Content-Length (we turned this off for a while to
match Boulder, but now it's back on), and the PEM / DER distinction was a
stumbling block.
This makes the test terminate after the assertion failure. Especially in the
case of AssertNotError, this can avoid triggering an immediate nil dereference
panic that obscures the error message.
This removes TestMode from the boulder-va command, from ca.Config
(it was only used in the VA) and gets the integration config to specify
the ports it should use explicitly.
(It also removes a DBDriver field from ca.Config that was left over from
letsencrypt/boulder#624.)
Fixes#627.
Changes this to use just communicate(), not the subprocess.PIPE stuff (which
apparently can do Weird Things)
Also rename the install variable to cmd in the install function
This eases the CPU and thread requirements of our tests (by forking
less, not doing everything at once). It should also speed up the tests
by avoiding certain repetitive work.
Updates https://github.com/letsencrypt/letsencrypt/issues/712
This has required some substantive changes to the tests. Where
previously the foreign key constraints did not exist in the tests, now
that we use the actual production schema, they do. This has mostly led
to having to create real Registrations in the sa, ca, and ra tests. Long
term, it would be nice to fake this out better instead of needing a real
sa in the ca and ra tests.
The "goose" being referred to is <https://bitbucket.org/liamstask/goose>.
Database migrations are stored in a _db directory inside the relevant
owner service (namely, ca/_db, and sa/_db, today).
An example of migrating up with goose:
goose -path ./sa/_db -env test up
An example of creating a new migration with goose:
goose -path ./sa/_db -env test create NameOfNewMigration sql
Notice the "sql" at the end. It would be easier for us to manage sql
migrations. I would like us to stick to only them. In case we do use Go
migrations in the future, the underscore at the beginning of "_db" will
at least prevent build errors when using "..." with goose-created Go
files. Goose-created Go migrations do not compile with the go tool but
only with goose.
Fixes#111
Unblocks #623
If two OCSP responses were generated in the same second, the earlier would
previously take priority sometimes, leading to a "good" response for revoked
certificates and causing the OCSP integration test to be flaky.
There's no reason to not just enforce it in the code completely and not
worry about it elsewhere. If we need to extract code out of NewDbMap,
we'd need recombineURLForDB in it, anyhow.
This changes moves from using SQLite in the integration tests and in the
test/boulder-config.json.
It does not port the unit tests over, unfortunately. That's a much more
invasive change.
This also updates the Dockerfile to include the MariaDB and RabbitMQ
requirements of start.py as well as adjusts the CMD to expose the
boulder server to the host machine. The Dockerfile also needed to have
its Go version bumped and the test.sh had to grow some explict
"function"s.
Updates #132
Jacob Hoffman-Andrews