The `auth` parameter was intended to receive either a `TreeherderAuth`
instance (for OAuth credentials), or a `HawkAuth` instance. The former
no longer exists since OAuth support has been removed, and the latter is
not necessary, since the client now supports simply passing `client_id`
and `secret` to the `TreeherderClient` constructor, as a simpler way of
specifying the Hawk credentials. As such, the `auth` parameter is
superfluous and can be removed.
Since they are deprecated and all submitters have switched over to using
Hawk credentials instead.
The automatically created migrations file was edited to remove the
unused `models` import, since otherwise flake8 complains. We could
alternatively exclude the migrations directory from flake8, however we
would then miss linter errors in any hand-written migrations files.
In addition, Django have fixed the issue in 1.9:
a7bc00e17b
Specifically, this update creates an API endpoint that allows updating a
"revised" summary id property off each alert. This is intended for the case
where a performance alert was generated against the wrong summary (usually
because of a downstream merge between branches). For now, the API requires the
user to be staff (i.e. a sheriff), otherwise it will generate a 403 denied.
This test checks that the `calculate_duration` command correctly
populates the `job_duration` table both on an initial run and when new
jobs cause an existing average duration to change.
It also checks that once the task has been run, any subsequent ingestion
of jobs with matching signatures cause those jobs to have the correct
`running_eta` value when inserted into the `job` table.
At the moment tests that store jobs can get away with not having the
test project listed in the repository table. However with later commits,
the new job_duration table will have a foreign key on the repository
table, which will break those tests unless they use the test_repository
fixture, which creates the repository record for them.
This test checks that `./manage.py makemigrations` was run, and the
resultant migrations file committed to the repo, since the last time the
Django models were updated.
Django 1.8 only supports an `exit_code` option, which unhelpfully makes
the command `sys.exit(1)` if there are *no* missing migrations, when
we're more interested in the opposite. As such, we have to confirm that
it does exit 1 (which causes a `SystemExit` exception).
On Django master they've replaced `exit_code` with `check_changes` that
inverts the check, which we should switch to once we're using a version
of Django that includes that fix.
Whilst Django itself handles the password property being set to `None`,
we use the Django DB configs in several places outside of Django (either
directly with MySQLdb, or via datasource which uses MySQLdb too).
MySQLdb will handle the password being the empty string, but raises
if `None` is passed, which can occur if using django-environ, due to:
https://github.com/joke2k/django-environ/issues/56
This change both works around that issue, and is also likely the right
thing to do regardless, since we shouldn't assume that the password is
even set in settings.py at all. (Django defaults the password to the
empty string, so it's perfectly acceptable to omit the password
property in the DATABASES dict entirely.)
* Make sorting more deterministic in cases where we have multiple
entries with the same push timestamp
* Internal PerfDatum clas renamed to just Datum
* Remove buildid parameter from Datum (not used for anything)
* Remove testrun_timestamp paramater from Datum (it's not really useful,
better to use push_timestamp
* Consolidate debug printing into one function that shows
everything
We're about to change the implementation of update_parse_status; this
test will ensure trying to update the status for a non-existent
job_log_url record will still result in a 404 response.
I changed the magic string from PERFORMANCE_DATA to PERFHERDER_DATA before
landing bug 1149164, but forgot to fix this particular part.
Updated unit test so this hopefully won't happen again
The job list endpoint was joining the job table and the resultset table
with the only purpose of sorting the results by push_timestamp.Also we
don't really need any sorting on that endpoint, so let's remove it.
This endpoint will be used by the similar jobs panel in the ui.
It returns a list of jobs shaped in the same way as the job list
endpoint but ordered by resultset_id DESC. In order to achieve decent
performance the returned list is filtered by the same job type as the
one selected.
I haven't found the exact reason why the tests were failing but it must
be a test isolation problem because they were passing individually.
I debugged this issue disabling the tests backwards starting from the
first failure and I found out that test_bz_api_process was the offender.
The test itself is not doing anything wrong but the refdata fixture
used to setup the test seems to be the root cause..
I replaced the two method calls with their orm counterpart and the
problem disappeared.
pytest-django doesn't setup a test database for every single test, but
only for those tests that actually require a db. Tests that require a db
need to either be marked with `@pytest.mark.django_db` or use a fixture
that has a dependency on `db` or `transactional_db`.
Using a non transactional db would make tests execution much faster, but
unfortunately it doesn't play well with the treeherder datasource
creation so I used a transactional_db.
pytest-django also allows you to specify a settings file to use for
tests in a pytest.ini file, which is nicer than monkeypatch the original
settings file in the pytest session start function 😃.
We were previously using the same database (test_treeherder) for both the
jobs and reference data model. I centralized the new db name in the test
settings file. All the test requiring the jobs db or its repository counterpart
can now access it using the `test_project` fixture, while utility functions use
directly the metioned setting. Where the project name is hardcoded in a static
file, I just replaced it with the new name `test_treeherder_jobs`
This guarantees that jobs databases is dropped at the end of each
test. It also makes the jobs database life cycle easier to understand.
In general to keep the tests as fast as possible we shouldn't have much
code in the setup and tear down of each test.
This adds a new FailureClassification for autoclassified
intermittent. When a job is completely classified by the
autoclassifer, and it has the same number of structured and
unstructured error lines, it is marked as an autoclassified
intermittent.
Conversely, when there is exactly one structured and one unstructured
error line, the autoclassifier did not match the job, but has a
detector that could match the job, and the job is marked as
intermittent by a human, add a new autoclassification target
corresponding to the error line.
We store both long and short, but only utilize the short (as before). We
need to populate all the short and long revision records before we can
start using them. So after this commit, we will begin backfilling the
old records that don't yet have those values populated. Once they all
are, we can move to using the long_revision primarily in Bug 1199364.
Some repos have been storing 40 char revisions, though most only store
12.
But a recent change to search by only 12 chars, even if 40 passed in
broke
the ability to search when the stored length was 40. This change will
search for both length revisions, if the 40 char is passed in.
We used to determine which performance signatures were in a repository by
looking at that repository's performance datums. Unfortunately, that method
was rather slow as the query had to work over millions of data points. So
instead, store repository and last modified information in the signature
table itself so it can be looked up quickly.
William Lachance
Ed Morley
Tiramisu 1993
Mauro Doglio
Cameron Dawson
Jonathan Griffin
James Graham
Ed Morley