Set php PATH for repository's hook

Summary:
~~Set PATH for repository's hook, so the environment.append-paths can used~~
repository's hook may can't find php path if user's profile like bash_profile is not loaded.

Test Plan: check the hook generated is contain the right path

Reviewers: epriestley, #blessed_reviewers

CC: Korvin, epriestley, aran

Differential Revision: https://secure.phabricator.com/D7743
Allow repositories to be associated with projects

Summary: Ref T4264. Ref T2628. Ref T3102. Allows you to associate repositories with projects. In the future, you'll be able to write Herald object rules against projects, use Herald fields like "Repository's projects", and search by project.

Test Plan: See screenshots.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T3102, T4264, T2628

Differential Revision: https://secure.phabricator.com/D7881
Recognize "#project" as a formal object name

Summary: Ref T4264. Ref T4262. Ref T2628. Ref T3190. To write Herald object rules which bind to a project, I want to take the low budget approach and have the user just type `#project` into a text field. Formally recognize `#project` as an object name, by moving all the existing stuff from the remarkup rule to the PHID type declaration.

Test Plan: Typed `#project` into jump nav and `phid.lookup` in Conduit. Typed `#project` into Remarkup.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T3190, T4264, T2628, T4262

Differential Revision: https://secure.phabricator.com/D7882
Allow Herald pre-commit rules to act on repository projects

Summary:
Fixes T4264. Adds:

  - New "Repository's projects" field to Herald pre-commit rules, so you can write global rules which act based on projects.
  - Allows pre-ref/pre-content rules to bind to projects, and fire for all repositories in that project, so users with limited power can write rules which apply to many repositories.
  - The pre-ref and pre-content classes were starting to share a fair amount of code, so I made them both extend an abstract base class.

Test Plan: Wrote new pre-ref and pre-content rules bound to projects, then pushed commits into repositories in those projects and not in those projects. The "repository projects" field populated, and the rules fired for repositories in the relevant projects.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T4264

Differential Revision: https://secure.phabricator.com/D7883
Add 'hook.d/' directories to SVN and Git repositories for custom hooks

Summary:
Fixes T4189. Ref T4151. Allows repositories to have additional custom hooks for operations which can't be expressed with Herald (one such operation is lint).

This adds only local hook directories, since they're easier to use with existing hooks than global directories. I might add global directories eventually.

This doesn't support Mercurial since we have no demand for it and it's more complicated (we lose compatibility and power by just dropping a `hooks.d/` somewhere).

Test Plan:
  - Pulled hosted SVN and Git repos to verify the hook directories generate correctly.
  - Added a variety of hooks to the hook directories (echo + pass, fail).
  - Pushed commits and verified the hooks fired (output expected info, or failed).
  - Verified push log reflected the correct error code ("3", external) and detail ("nope.sh") when rejecting.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T4151, T4189

Differential Revision: https://secure.phabricator.com/D7884
Cut Herald rules off at 1GB of diff text

Summary:
Ref T4276. When a change is larger than 2GB, PHP can not read the entire change into a string, so Herald can not process it.

Additionally, we already have a time limit for practical reasons, but it's huge (probably incorrectly). To deal with these things:

  - Add an optional byte limit to `diffusion.rawdiffquery`.
  - Make the query with a 1GB limit.
  - Reduce the diff timeout from 15 hours to 15 minutes.
  - Add a "Changeset is enormous" field. This field is true for changes which are too large to process.

This generally makes behaviors more sane:

  - We'll always make progress in Herald in a reasonable amount of time.
  - Installs can write global rules to handle (or reject) these types of changes.

Test Plan: Set limit to 25 bytes instead of 1GB and ran test console on various changes.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T4276

Differential Revision: https://secure.phabricator.com/D7885
New icons for play, pause, etc.

Summary: New icons

Test Plan: photoshop

Reviewers: epriestley, btrahan

Reviewed By: epriestley

CC: Korvin, epriestley, aran

Differential Revision: https://secure.phabricator.com/D7893
Phriction - fix a corner case on renaming a project

Summary: if you rename a project in such a way that the old slug and the new slug are the same, there are errors when the phriction document is updated. detect this case and don't bother updating the document since there is no change. Fixes Github issue 474.

Test Plan: made a project "testTest". Viewed the wiki page. Created the wiki page. Renamed the project "TestTest". Before patch, this error'd, post patch it works!

Reviewers: epriestley

Reviewed By: epriestley

CC: Korvin, epriestley, aran

Differential Revision: https://secure.phabricator.com/D7888
Nuance - conduit method to create items

Summary:
pretty simple. did the bare minimum in the editor, etc. to be able to create an item from the conduit console.

I put the work in the editor for initializing new values, rather than some initializeNewItem method, mainly because Items don't have policy directly but instead policy will be defined by the queue(s) the item is in. The editor is definitely going to host this work, so it felt like it might be better to do it this way in time...? anyway, easy to make an initializeNew method instead if you want to have that paradigm going all the time.

Test Plan: made an item from teh conduit console - success. verified errors for missing data as well

Reviewers: epriestley

Reviewed By: epriestley

CC: Korvin, epriestley, aran

Differential Revision: https://secure.phabricator.com/D7879
Apply "enormous changes" rules to pre-commit content rules too

Summary:
Fixes T4276. This adds "Change is enormous" to pre-commit content rules so we can, e.g., just reject these and not worry about them elsewhere.

Also, use the same numeric limits across the mechanisms so there's a consistent definition of an "enormous" changeset.

Test Plan:
  - Set enormous limit to 15 bytes, pushed some changes, got blocked by a rule.
  - Set it back, pushed OK.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T4276

Differential Revision: https://secure.phabricator.com/D7887
Rename "Apply build plans" to "Run build plans" in Herald

Summary: "Run" is clearer than "Apply". This has already been changed in Harbormaster itself.

Test Plan: used eyeballs

Reviewers: btrahan, zeeg

Reviewed By: btrahan

CC: aran

Differential Revision: https://secure.phabricator.com/D7889
Adjust transformed URI in CSS

Summary: This one CSS file has a pre-transformed URI in it, just use a raw resource name. The tranform pipeline will fix it (and this URI is no longer correct).

Test Plan: Loaded some pages.

Reviewers: btrahan, chad

Reviewed By: chad

CC: chad, aran

Differential Revision: https://secure.phabricator.com/D7895
Simplify adding new database patches

Summary:
Currently, to add new migration patches you need to:

  - Add a file to `resources/sql/patches/`; then
  - add an entry to `src/infrastructure/storage/blahblah/BlahBlahBlah.php`.

The second step isn't actually necessary, and we've been using this system for a long time without any issues arising.

Instead of requiring manual adjustments to the patch list, infer the patch specifications from the files on disk so you don't need to do step 2.

Also, simplify the existing data, which can //mostly// be derived from patch names. There are a few exceptions/errors, noted inline, which are preserved for compatibility.

Test Plan:
  - For the new genration of `name` and `type`, I added code to check that the old and new values were the same before converting. This caught the two inline exceptions ("emailtableport", "drydockresouces").
  - Added new patches to `autopatches/` and ran `bin/storage status` to verify they got picked up correctly.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Differential Revision: https://secure.phabricator.com/D7894
Add mailKey to macros

Summary:
If you have private replies on and a Macro reply handler set, we try to access `getMailKey()` and fail. See P1039 for a trace.

(Thanks to @Korvin for picking this up.)

Test Plan: Set configuration, repro'd the exception, applied the patch, then disabled/enabled a macro.

Reviewers: btrahan

Reviewed By: btrahan

CC: Korvin, aran

Differential Revision: https://secure.phabricator.com/D7896
Split Harbormaster workers apart so build steps can run in parallel

Summary:
Ref T1049. Currently, the Harbormaster worker looks like this:

  foreach (step) {
    run_step(step);
  }

This means steps can't ever be run in parallel. Instead, split it into two workers. The "Build" worker starts things off, and basically does:

  update_build();

(We could theoretically do this in the original process because it should never take very long, but since there's a lock and it's a little bit complex it seemed cleaner to separate it.)

The "Target" worker runs an individual target (like a command, or an HTTP request, or whatever), then updates the build:

  run_one_step(step);
  update_build();

The new `update_build()` mechanism in `HarbormasterBuildEngine` does this, roughly:

  figure_out_overall_status_of_all_steps();
  if (build is done) { done(); }
  if (build is fail) { fail(); }
  foreach (step that is ready to run) {
    queue_target_worker_for_step(step);
  }

So, overall:

  - The part of the code that updates Builds is completely separated from the part of the code that updates Targets.
  - Targets can run in parallel.

Test Plan:
  - Ran a bunch of builds via `bin/harbormaster build`.
  - Ran a bunch of builds via web UI.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T1049

Differential Revision: https://secure.phabricator.com/D7890
Replace "Cancel Build" with "Stop", "Resume" and "Restart"

Summary:
Ref T1049. Currently you can cancel a build, but now that we're tracking a lot more state we can stop, resume, and restart builds.

When the user issues a command against a build, I'm writing it into an auxiliary queue (`HarbormasterBuildCommand`) and then reading them out in the worker. This is mostly to avoid race messes where we try to `save()` the object in multiple places: basically, the BuildEngine is the //only// thing that writes to Build objects, and it holds a lock while it does it.

Test Plan:
  - Created a plan which runs "sleep 2" a bunch of times in a row.
  - Stopped, resumed, and restarted it.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran, chad

Maniphest Tasks: T1049

Differential Revision: https://secure.phabricator.com/D7892
Make HarbormasterBuild a better source of truth about restarting/resuming/stopping

Summary: Ref T1049. The logic in the BuildEngine is a little different from the logic on the Build itself. Make these more consistent, and make queued commands more private.

Test Plan: Restarted, stopped, and resumed a build.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T1049

Differential Revision: https://secure.phabricator.com/D7897
Improve restart/stop/resume UI

Summary:
Ref T1049. Improves the UI:

  - Pending commands, like "stopping", are shown separately from the current status.
  - Pending commands are shown on the list view.
  - Builds can be restarted, stopped and resumed from the list view.
  - Add a missing crumb.

Test Plan:
{F99022}

{F99023}

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T1049

Differential Revision: https://secure.phabricator.com/D7898
Allow entire buildables to restart/stop/resume

Summary: Ref T1049. Creates convenience actions at the Buildable level to stop, resume, or restart all builds.

Test Plan:

  - Stopped all builds.
  - Resumed all builds.
  - Restarted all builds.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T1049

Differential Revision: https://secure.phabricator.com/D7899
Audit - tweak colors

Summary: See github issue 413. This diff adds color to the commit view as the user expects *AND* adds green to both audit and commit views. I looked in the history (D6184) and I can't tell how expected green was, but it feels nice to me given differential color coding.

Test Plan: looked at lists of audits and commits with pretty colors.

Reviewers: epriestley, chad

Reviewed By: epriestley

CC: Korvin, epriestley, aran

Differential Revision: https://secure.phabricator.com/D7900