This accomplishes two things:
- setup.sh should now be usable by the client integration test.
- setup.sh can be used by new project members to simplify first setup.
Update the README to indicate the new file, and to correct some out-of-date
information.
Make `make` aware of output files so it doesn't always have to rebuild. Also
make it use `go install`, which is faster than building files individually.
Now that make is faster, use it in startservers.py to consolidate building
logic. This also has the handy side-effect that ./start.py exposes useful build
information through /build, whereas before only the .rpm packaged version did.
Additionally, this allows us to remove `make` from the Travis matrix, since we
are running `make` as part of the integration test. This means each PR only
triggers two Travis builds instead of one, which means we will get results from
Travis faster.
Also, change the Travis matrix logic to be a list of actions to run, rather than
a list of actions to skip. That fixes
https://github.com/letsencrypt/boulder/issues/817.
Enumerate specific sections of test.sh to run, rather than sections to skip.
Note: ./start.py now installs into ./bin/ instead of $GOPATH/bin.
Only set up GitHub secret file (for PR status reporting) when available, and
decrypt it into /tmp rather than $HOME, to avoid accidentally caching it once
Travis' caching features are available.
Clone letsencrypt repo into $HOME instead of $TMP, to make it possible to cache
eventually.
Remove unused `mysql` dependency in Travis.
Override default Travis install command to prevent it from adding
Godeps/_workspace to GOPATH. When that happens, it hides failures that should
arise from importing non-vendorized paths.
bitbucket is espescially slow and flaky. Not doing this caused a test
failure on master.
We should probably figure out a solution for keeping binaries
around. (Godeps doesn't solve that trivially.)
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.
The unit test part of the build matrix doesn't need letsencrypt
downloaded and built, so only do it when needed.
Also, use travis_retry in test.sh for git and pip work to compensate
better.
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
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
The github-secret.json file can't be decrypted if the PR is coming from
someone who is not a maintainer on boulder. So, just use the boring old
status updates from TravisCI and let the tests continue to run.
This uses a node.js module to post `status` updates to Github, and uses a Travis
secret to authenticate.
- Post comments from static analysis tools
- Change to posting from LetsEncryptBot
- For integration testing, only fail if the compile fails, or
the NodeJS-client fails. Log if the Python client fails.
Travis:
* Downloads the Let's Encrypt client
* Installs system requirements for client
* Sets up virtualenv
Dockerfile:
* Buildout for development
* Includes numerous pacakges needed for integration testing
(including all of the above in Travis)
test.sh:
* If no path is defined for the LE client
* Download the Let's Encrypt client
* Set up virtualenv
test/amqp-integration-test.py:
* Run client test with sensible defaults
* One test: auth for foo.com
Nut, https://github.com/jingweno/nut, is a tool to manage Go dependencies and
versioning by vendorizing them, i.e. including them in your own repo.
This makes version management easier, as well as authenticating the contents of
this repository.
Also inthis change: Factor out the testing commands from .travis.yml to make it
easier to run them by hand. Add Vim swap files to .gitignore.
Jeff Hodges