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



Tree Management
2 years ago
2 years ago


(Reporter: emorley, Assigned: emorley)


(Blocks: 1 bug)



(1 attachment)

Even though the run is green. eg:

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).
Created attachment 8769696 [details] [review]
[treeherder] mozilla:fix-check-deploy > mozilla:master
Attachment #8769696 - Flags: review?(wlachance)
Comment on attachment 8769696 [details] [review]
[treeherder] mozilla:fix-check-deploy > mozilla:master

Attachment #8769696 - Flags: review?(wlachance) → review+

Comment 3

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

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.
Last Resolved: 2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.