The UI has already been removed. This cleans up the data ingestion
and removes the `JobDuration` model, however leaves the `running_eta`
field on the `Job` model for the next time that table is touched (since
the table is large, so altering the schema would likely require
downtime).
Most of the existing config (generated by `sphinx-quickstart`) was
either commented out, identical to the defaults or else for build
modes we do not use - and only end up making the config hard to read.
* Removes the unnecessary initial `make html`, since sphinx-autobuild
performs the initial build itself.
* Enables `--poll` watch mode, since file change detection otherwise
doesn't work in Vagrant.
* Updates the docs to recommend the livereload web server over the
one-off build when working on docs locally.
The build previously contained warnings like:
```
docs/rest_api.rst:144: WARNING: Title underline too short.
docs/admin.rst:18: WARNING: Could not lex literal_block as "sql". Highlighting skipped.
WARNING: html_static_path entry u'.../docs/_static' does not exist
```
Now that no submissions are using revision_hash, it can be removed.
This removes everything but the model field, which will be handled
later.
I've removed revision_hash from the Pulse jobs schema without bumping
the version, which wouldn't normally be ok, but no one is still using
it, and I'd rather have explicit failures later than if we left the
schema unchanged.
Since for people installing node/yarn on their own (outside the
Vagrant environment) it can be confusing to work out which version is
appropriate, given node always has both an LTS and current release.
Note: This leaves the models and tables intact so that we can
revert without data loss in case we discover an issue. A follow-up
commit will remove those tables and models.
The maintenance section was not addressing that data can take a while before the different scheduled processes bring the data into the right tables.
This addresses documenting how to:
* Update the runnable jobs table
* Update the job priority table
This populates the job priority table with data locally.
It puts all jobs into the table without considerations of analyzing failures.
That can follow up in the future.
Update docs accordingly.
Change of new environment variable `PULSE_PUSH_SOURCES`.
Keep old `publish-resultset-runnable-job-action` task name by creating a
method that points to `publish_push_runnable_job_action`.
By default webservers like Django's runserver, gunicorn or the
Webpack devserver only bind to the loopback adapter (127.0.0.1) and
so are not accessible from outside the Vagrant / virtualbox VM,
since port forwarding only forwards traffic to the non-loopback
adapters.
Previously varnish (which listened on `0.0.0.0`) was reverse
proxying traffic to runserver/gunicorn, however we need to now do so
for webpack-dev-server on another port too. Doing both with varnish
adds complexity, and we don't actually need any of varnish's other
features, so ideally want to stop using it.
Rather than having to override each webserver to bind to all
adapters (using the IP `0.0.0.0`), it's possible to forward traffic
to the loopback adapter using iptables NAT PREROUTING rules. This
is still secure so long as the Vagrantfile port forwarding uses a
`host_ip` of `127.0.0.1`. To prevent this "Martian packet" traffic
from being blocked, `route_localnet` must also be set to `1`. See:
https://unix.stackexchange.com/questions/111433/iptables-redirect-outside-requests-to-127-0-0-1
By default neither sysctl or iptables settings are persisted across
reboots, and fixing that requires more complexity (eg installing the
iptables-persistent package and handling config changes during
provision). As such, it's just easier to re-run the commands on each
login since they take <30ms.
Previously a forgotten-about `local.conf.js` (which is git-ignored)
would override the URL passed by the `SERVICE_URL` environment variable.
With webpack and environment variables, there is no need to use a local
config file to control the API URL, so we can now remove this footgun.
Artifacts no longer exist (they've been replaced by more specific types
like "jobdetails"), and so fetching from this endpoint has been disabled
for some time already.
For data submission, we still call them artifacts (and sort their type
after submission), however all artifacts are currently submitted at the
same time as the job, so this endpoint is unused.
This import only affects internal treeherder usage, people using the
PyPI package import from the `thclient` subdirectory instead.
Fixes:
treeherder/client/__init__.py:1:1: F401 '.thclient.*' imported but unused
Since it's faster, deterministic and doesn't given obscure errors when
using `--no-bin-links` (which is required for both npm and yarn on
Windows hosts), and as such unblocks the work in bug 1343624.
Many of the commands are the same as with npm. See:
https://yarnpkg.com/en/docs/usage
The `test` script entry in `package.json` (used by `npm test`) already
calls karma with the appropriate parameters, so the helper scripts are
unnecessary.
For the same reason as the previous commit.
Ideally we'd remove the grunt abstraction entirely and call eslint from
the `lint` command, but we might as well save that to the Neutrino PR.
Routing commands via npm/yarn is preferred, since it avoids
having to do global installs of grunt-cli, which simplifies contributor
setup, and means less effort when we switch to Yarn (since it requires
manual PATH setup for globally installed packages).
These were added by bug 1312575 and bug 1323110.
The table exclusion list has also been updated to remove the corsheader
entry, since as of v2.0.0 it no longer creates any tables.