1285539 - 'manage.py check --deploy' is failing on Travis

Status: RESOLVED FIXED

(Tree Management :: Treeherder, defect, P1)

Description

[Ed Morley [:emorley]]

Even though the run is green. eg:
https://travis-ci.org/mozilla/treeherder/jobs/143190163

It's failing since `ELASTICSEARCH_URL` is set (since we set it globally across all Travis job types), but for the linters job we don't install elasticsearch.

The reason Travis is still showing a green job is that we have to do an awful hack to work around older versions of Django not having `--fail-level WARNING` (we can remove this hack once we're on Django 1.10).

Given the check deploy command hits the DB, I think we should just move it out of the linters sub-job into another. (Given on the linters job we're not even running the correct mysql version).

Comment 1

[GitHub Autolander Bot]

Attachment: [treeherder] mozilla:fix-check-deploy > mozilla:master

Comment 2

[William Lachance (:wlach)]

Comment on attachment 8769696 [details] [review]
[treeherder] mozilla:fix-check-deploy > mozilla:master

lgtm

Comment 3

[Treeherder GitHub Bugbot]

Commit pushed to master at https://github.com/mozilla/treeherder

https://github.com/mozilla/treeherder/commit/07ea1c4db176a77e85e56ad1b8a26f549dd15bdf
Bug 1285539 - Fix 'manage.py check --deploy' on Travis

The `manage.py check --deploy` command causes the Django models to be
initialised, which requires Elasticsearch to be accessible, if
`ELASTICSEARCH_URL` is set. The variable is set globally for the Travis
runs, however for the linters job (which is where `check --deploy` was
previously being run) Elasticsearch isn't actually installed.

Whilst we could have just unset `ELASTICSEARCH_URL` for the linters job,
it's best to move the test to the main Python job chunk, since:
* The command doesn't only hit Elasticsearch, but also the DB, and the
linters job is running the older mysql 5.5, rather than mysql 5.6.
* Whilst Elasticsearch isn't currently enabled for anywhere other than
the prototype Heroku instance, we'll soon be using it everywhere, so
should get `check --deploy` to actually test what we plan to deploy.

Note: The exception during `check --deploy` was not turning the Travis
run red, due to `check --deploy` being piped to awk. When we update to
Django 1.10 the awk workaround can be removed, however in the meantime
we can use the bash `pipefail` option to ensure the exit code from the
`manage.py` command propagates through to the one that Travis sees.