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).
Created attachment 8769696 [details] [review] [treeherder] mozilla:fix-check-deploy > mozilla:master
2 years ago
Attachment #8769696 - Flags: review?(wlachance)
Comment on attachment 8769696 [details] [review] [treeherder] mozilla:fix-check-deploy > mozilla:master lgtm
Attachment #8769696 - Flags: review?(wlachance) → review+
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.
2 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.