As part of my work to get grunt build running automatically on deploy,
I'm going to run it on Travis to make sure we catch things like this
before deploy :-)
The hawk credentials lookup function is the glue between hawk and
the `application` django app. I wrote tests to verify its logic,
everything else is mostly configuration code.
An authenticated user can access the new ui and add new credentials.
When new credentials are created the system generates automatically
a secret key which is available in the credentials details.
The credentials needs to be approved by a member of staff before they
can be used for data submission; that can be done via the admin
panel.
In the admin panel it is also possible to reset the secret key of one
or more credentials. The new secret will be available to its owner
in the application details.
The new app handles treeherder client credentials.
The content of the credentials table should replace the credentials file
we currently use for authentication.
This commit includes orm models, migrations and an admin interface.
The login_required decorator redirects unauthenticated users to
settings.LOGIN_URL, adding a `next` querystring parameter to it.
This parameter is then passed to the browserid login button so that
the user can be sent back to the original page after a successful
authentication.
It seems like 1G is too little for mysql as it is currently configured,
bumping the default memory on the Vagrant instance is an easy way of
addressing this.
This sets a dyanmic width for the job-tabs-panel so when non-Talos
jobs are selected, we optimize the resize experience at small browser
widths since only 4 tabs are visible.
When Talos jobs are selected, we increase the size accordingly
to accommodate 5 tabs.
It's unused in the UI and doesn't add any value, since we're
normally much more interested in the push_timestamp.
This can land without causing errors, since the field is DEFAULT NULL,
so can be dropped at our leisure later.
These are the settings (which can be overridden by environment variables)
that will be used to specify which Pulse exchanges we ingest data from
This also introduces the ``django-environ`` package which will be used
elsewhere as we move away from ``local.py`` files on the stage/prod
servers.
Rather than just the summary text. Also removes the redundant bug
summary from the title (since it matches the link text) - which means
that there is no tooltip to show for bug suggestions unless the bugs are
resolved.
As of karma-jasmine 0.3.0, the jasmine library is not bundled with
karma-jasmine, and so jasmine-core has to be installed separately.
jasmine-jquery also has to be updated, since the old version was not
compatible. A duplicate jasmine-jquery file that was outside of the
tests vendor directory has also been removed.
To avoid Travis failing if new package authors don't follow semver and
break things in a point release.
This is effectively a no-op, compared to a clean install using the prior
package.json.
The karma package already comes with a wrapper script, so there's no
need to install another locally. The intended use for karma-cli is to
install it globally, which cannot be done from package.json.