1. 11 Jul, 2019 27 commits
    • Ana Rute Mendes's avatar
      7496f4ec
    • Ana Rute Mendes's avatar
      Update sysadmin ticket project · 2c0654bb
      Ana Rute Mendes authored
      2c0654bb
    • Ana Rute Mendes's avatar
      LOCAL/POLICY: set sysadmin requests policies · f1c49409
      Ana Rute Mendes authored
      Set sysadmin resquests policies according to confidentiality
      chosen by the user.
      f1c49409
    • Ana Rute Mendes's avatar
      LOCAL: Restrict All users policy for top-level docs · 356c555d
      Ana Rute Mendes authored
      Restrict the creation of a new top-level document if visibility or
      edition policies are set to "All users".
      
      See T4759
      356c555d
    • Daniel Stone's avatar
      LOCAL: Make 'All Users' space extremely magic · d20dba84
      Daniel Stone authored
      Phriction's view policy is ancestral: in order to access /w/foo/bar/baz,
      you must be able to access /w/foo and /w/bar in addition to
      /w/foo/bar/baz itself.
      
      This is fine and makes life easy: by setting restrictive policies on
      top-level pages, we can lessen the risk of someone exposing information
      they shouldn't, by accidentally making
      /w/cold-fusion/secret-research/funding-meeting/2018-09-14 public, when
      the rest of the hierarchy is super locked down.
      
      Phriction also recently gained Spaces support, which is nice: rather
      than trying to lock down with groups and harmonise permissions, we can
      just move top-level wiki pages to a particular Space, and then we don't
      need to worry about groups.
      
      Our clients don't know Spaces even exist, which is great since it avoids
      us having to explain the two-tier permission model to them. The reason
      they don't know it exists is because if you can only see a single Space,
      then Phabricator hides the entire Spaces UI away from you. Great!
      
      Unfortunately one detail ruins everything: /w/ is a top-level page
      itself, it counts for permission checks, and it _must be in a Space_.
      So, there is no way to have wiki documents in mutually-invisible Spaces
      unless you also have a common Space, at which point the whole Spaces UI
      suddenly becomes very visible everywhere.
      
      In order to try to keep our wiki partitioned, but to not confuse our
      clients (and give them the chance to potentially expose confidential
      information!), we:
        - have a magic 'Visible to Everyone' space
        - actually hide that space from everyone with policies
        - hack policy filters to make this space visible to everyone _only
          for the purpose of checking policies on wiki objects_
        - only allow admins to change view/edit policies on the root wiki
          page (see comment for reason why)
      
      This actual patch can obviously never go anywhere near upstream, but on
      the other hand we should probably make them aware of the problem and see
      if they're interested in discussing a solution, which is probably just
      to bless the root page with magic semantics.
      Signed-off-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      d20dba84
    • Daniel Stone's avatar
      LOCAL/UI: PHUI: Add custom Collabora colour scheme · 184587cb
      Daniel Stone authored
      Add a colour scheme for tagging objects in lists.
      184587cb
    • Daniel Stone's avatar
      LOCAL/UI: Project: Reorder profile tabs · 71ded62b
      Daniel Stone authored
      This is a UI tweak.
      71ded62b
    • Daniel Stone's avatar
      LOCAL/UI: Diffusion: Set default autoclose to 'master' · f3716693
      Daniel Stone authored
      Encode policy, allowing patches to land on feature branches without
      closing tasks.
      f3716693
    • Daniel Stone's avatar
      LOCAL/UI: Differential: Use tab width of 8 rather than 2 · 08a9379a
      Daniel Stone authored
      It would be nice, as the comment notes, to have this customisable perhaps
      per-repository, but for the meantime this is unambiguously the better
      solution.
      08a9379a
    • Evan Priestley's avatar
      LOCAL/UI: PHUIHandleTagListView: Sort alphabetically · 1a063225
      Evan Priestley authored
      Sort tags alphabetically, rather than order of (PHID) appearance in the
      database.
      
      From https://secure.phabricator.com/p/epriestley at:
      https://secure.phabricator.com/T11420#188498
      1a063225
    • Daniel Stone's avatar
      LOCAL/UI: Maniphest: Show points and review status in task queries · 7bba232b
      Daniel Stone authored
      In the Maniphest query result view, show the story points as well as the
      review/CI status on each task as we currently show them in workboard
      column cards, along with the project tags.
      
      This is local UI policy; the correct fix (of rewriting hover/card views
      to be more generic and extensible) is pretty much impossible to achieve,
      and isn't approachable by non-Phacility contributors.
      7bba232b
    • Daniel Stone's avatar
      LOCAL/UI: Project: Show task status in workboard cards · d6e0bc5e
      Daniel Stone authored
      Show the status of every task in workboard cards using the icons
      explicitly, rather than just differentiating between closed and
      not-closed.
      
      This is a local UI choice.
      d6e0bc5e
    • Daniel Stone's avatar
      LOCAL/UI: Project: Show review/CI status on workboard · 6b3a418c
      Daniel Stone authored
      On project workboard cards, also show the status of linked code reviews;
      both the review itself, and any attached Harbormaster CI buildables.
      
      This is already taken care of in the task-detail view by 45c740ac,
      and extends it to the workboard view. It should probably share more code
      with the task-detail view.
      
      It will not be accepted upstream in its current form; it was felt in
      https://secure.phabricator.com/T7076 discussion that performing multiple
      queries for each revision to get the current state was too much. This
      makes it exceedingly unlikely that doing the same number of queries for
      every task in a workboard would be acceptable.
      
      There was discussion of how to fix that, but it was essentially
      impossible, and explicitly discouraged for anyone to even try.
      6b3a418c
    • Daniel Stone's avatar
      LOCAL/POLICY: Maniphest: Auto-assign purchasing tasks to approver · bd3624ce
      Daniel Stone authored
      Enforce a local policy, that on purchasing tasks, the approver will be
      auto-assigned if there is no assignee.
      
      The 'correct' fix would probably be a Herald rule, if it were actually
      possible to implement. An EditEngine extension might work as well, but
      this was easier.
      bd3624ce
    • Daniel Stone's avatar
      LOCAL/POLICY: Project: Make project field required for Maniphest · 11182bd0
      Daniel Stone authored
      Enforce a local policy that all tasks must have an associated project.
      11182bd0
    • Daniel Stone's avatar
      LOCAL/POLICY: Differential: Clear 'Depends On' when attaching new diff · 96d4d230
      Daniel Stone authored
      When we attach a new diff to a Differential revision, clear out its
      'Depends On' field. This is so we don't end up with dependency cycles
      when we rebase/cherry-pick commits out of order.
      
      As upstream do not use rebasing/chery-picking/multi-patch-branch
      workflows, this is unlikely to be accepted.
      96d4d230
    • Daniel Stone's avatar
      HACK: Conduit: Accept OAuth2 Authorization header · c41d8fd6
      Daniel Stone authored
      This is really lame. The Ruby OAuth2 client can only pass its token in
      the form data (which Phab is not prepared to accept), or as part of the
      Authorization header (which PHP strips out).
      
      Use a function only available in newer PHP to scrape the Authorization
      header from the raw stream.
      
      I have no idea what the correct fix is.
      c41d8fd6
    • Daniel Stone's avatar
      HACK: OAuth: Accept Mattermost double-URI · 4eb66088
      Daniel Stone authored
      Mattermost OAuth requires two separate URIs, whereas the Phabricator
      OAuth server only allows returning to a single URI. Special case
      Mattermost and get on with life.
      
      The correct fix is to actually allow multiple values in the OAuth
      configuration. I don't know off the top of my head how this would work,
      e.g. a tokenising field, or a multi-line field (which I don't know how
      to achieve without Remarkup), or ... ?
      4eb66088
    • Daniel Stone's avatar
      HACK: Reverse add/remove transaction application order · 36944cc0
      Daniel Stone authored
      PhabricatorApplicationTransactionEditor contains logic (inside
      combineTransactions -> mergeTransactions ->
      mergePHIDOrEdgeTransactions), which will combine two transactions of the
      same edge type and author, then apply the operations in a deterministic
      order.
      
      This breaks our change to remove dependencies when updating a
      Differential revision, since we (acting as the user who uploaded the
      revision) remove the DifferentialRevisionDependsOn edge, then have the
      Remarkup block parser add the dependencies from the commit message
      later.
      
      The two (simplified) transactions of:
      {
          "1-from-our-change-to-differential": {
              "type": "edge",
              "-": {
      	    "PHID-DREV-1234": [...], // remove previous dep
      	}
          },
          "2-from-remarkup-parsing": {
              "type": "edge",
              "+": {
      	    "PHID-DREV-1234": [...], // add dep from commit message
      	}
          }
      }
      
      get merged into:
      {
          "1-combined": {
              "type": "edge",
      	"-": {
      	    "PHID-DREV-1234": [...], // remove previous dep
      	},
      	"+": {
      	    "PHID-DREV-1234": [...], // add dep from commit message
      	}
          }
      }
      
      getPHIDTransactionNewValue() then returns an empty dictionary, because
      it always executes the add before the remove, regardless of ordering.
      The correct fix would be quite invasive to the transaction editor
      (making the combine function considerably less naïve, and always
      preserving order of operation WRT identical PHIDs); the quick fix for
      now (at least) is to just make add operations execute after remove, thus
      'fixing' it for the only case we really care about.
      
      The correct fix is more time than worthwhile to achieve, especially
      since it's extremely difficult to achieve without code modifications.
      36944cc0
    • Emanuele Aina's avatar
      BROKEN: Add the `phill` command line tool to import projects and tasks · c9157ca7
      Emanuele Aina authored
      This is completely broken with modern transactions. It should also be
      rewritten to match Phabricator's coding style.
      c9157ca7
    • Daniel Stone's avatar
      WIP: Transactions: Hide transactions involving restricted objects · 23ef4457
      Daniel Stone authored
      If a transaction has an object that a particular user cannot see, then
      mark the transaction as hidden for the default transaction view. This
      particularly elides 'foo moved this task from Restricted Workboard
      Column to Restricted Workboard Column on the Restricted Project board'
      messages in the timeline, which are not hugely useful.
      
      This would need a fair bit more work to go upstream, especially eliding
      notifications for restricted-only transactions as well.
      23ef4457
    • Daniel Stone's avatar
      WIP: Maniphest: Hide hidden project tags for tasks · 5ace28bc
      Daniel Stone authored
      If the viewer doesn't have permission to see something a task has been
      tagged with, then don't show it to them in the Maniphest task list view,
      the task detail view, or the workboard view.
      
      This should be extended further to also eliminate it from the
      transaction history (in the task detail view) and also from
      notifications, but it's a start.
      
      This would need quite a bit more work to go upstream.
      5ace28bc
    • Daniel Stone's avatar
      WIP: Maniphest: Allow restricting custom fields to subtypes · ebe2b9cd
      Daniel Stone authored
      Add a 'subtype' parameter to custom fields, which means they will only
      be visible on (and validated with) tasks of a particular subtype.
      
      Suitable for upstream after much rework:
      https://secure.phabricator.com/D17593
      ebe2b9cd
    • Emanuele Aina's avatar
      Derive story/mention time from transactions · 229119af
      Emanuele Aina authored
      By taking the story time from the transaction creation date we ensure that the times reported in the feed view match the ones reported in the item-specific change lists.
      229119af
    • Quinn Ebert's avatar
      Default Phriction ACL configuration support · a0446c6a
      Quinn Ebert authored
      This implements an Applications > Phriction configuration option that allows the administrators to specify default view and edit ACL policies for root-level Phriction documents.
      
      Test Plan:
        1. Create a clean test install of Phabricator, login as the admin user
        2. Go to Applications, configure settings for Phriction, set up the ACL you want
        3. Upon creating the first document in Phriction, the ACL chosen by default should be the one you configured in step 2.
      a0446c6a
    • Daniel Stone's avatar
      Accept arrays in PHID custom-field validation · 0b50c4a0
      Daniel Stone authored
      As setValueFromStorage() notes, we can accept either JSON strings or arrays for PHID-type custom fields. Handle this in decodeValue by passing through an array if we've received one.
      
      Test Plan:
        - Add Maniphest custom field with PhabricatorPeopleDatasource
        - Create task with field filled
        - Go to Maniphest task detail view
        - Observe no errors in DarkConsole / PHP error log
      0b50c4a0
    • Daniel Stone's avatar
      Preserve silent and time when updating blocked tasks · f3aa48e7
      Daniel Stone authored
      Ref T13042. Updating blocked tasks creates a new ManiphestTransactionEditor instance from within the current transaction application, which fails to carry over all of the current properties. Failing to update silent means that mails will be generated for updates to blocked tasks, regardless of the setting for the original transaction editor.
      
      Failing to preserve the time can also give large time deltas in corner cases, such as running an importer which pulls tasks from yesteryear.
      
      This equally applies to inverse-edge transactions, though I don't have a ready-made usecase for those.
      f3aa48e7
  2. 29 Jun, 2019 1 commit
  3. 28 Jun, 2019 1 commit
  4. 26 Jun, 2019 1 commit
  5. 25 Jun, 2019 4 commits
    • epriestley's avatar
      (stable) Bump the remarkup cache version after JIRA/Asana rule changes · 2d2626d7
      epriestley authored
      Summary: See PHI1319. Ref T13291. Bump the remarkup cache version, since the old JIRA / Asana rules may exist in the partial cached representation of remarkup blocks from older versions.
      
      Test Plan: Typed some comments with various formatting, saw remarkup work fine.
      
      Reviewers: amckinley
      
      Reviewed By: amckinley
      
      Maniphest Tasks: T13291
      
      Differential Revision: https://secure.phabricator.com/D20619
      2d2626d7
    • epriestley's avatar
      Bump the remarkup cache version after JIRA/Asana rule changes · 987e1046
      epriestley authored
      Summary: See PHI1319. Ref T13291. Bump the remarkup cache version, since the old JIRA / Asana rules may exist in the partial cached representation of remarkup blocks from older versions.
      
      Test Plan: Typed some comments with various formatting, saw remarkup work fine.
      
      Reviewers: amckinley
      
      Reviewed By: amckinley
      
      Maniphest Tasks: T13291
      
      Differential Revision: https://secure.phabricator.com/D20619
      987e1046
    • epriestley's avatar
      (stable) Limit the read buffer size in `bin/storage dump` · ccf207f2
      epriestley authored
      Summary:
      Ref T13328. Currently, we read from `mysqldump` something like this:
      
      ```
      until (done) {
        for (100 ms) {
          mysqldump > in-memory-buffer;
        }
      
        in-memory-buffer > disk;
      }
      ```
      
      This general structure isn't great. In this use case, where we're streaming a large amount of data from a source to a sink, we'd prefer to have a "select()"-like way to interact with futures, so our code is called after every read (or maybe once some small buffer fills up, if we want to do the writes in larger chunks).
      
      We don't currently have this (`FutureIterator` can wake up every X milliseconds, or on future exit, but, today, can not wake for readable futures), so we may buffer an arbitrary amount of data into memory (however much data `mysqldump` can write in 100ms).
      
      Reduce the update frequency from 100ms to 10ms, and limit the buffer size to 32MB. This effectively imposes an artificial 3,200MB/sec limit on throughput, but hopefully that's fast enough that we'll have a "wake on readable" mechanism by the time it's a problem.
      
      Test Plan:
        - Replaced `mysqldump` with `cat /dev/zero` as the source command, to get fast input.
        - Ran `bin/storage dump` with `var_dump()` on the buffer size.
        - Before change: saw arbitrarily large buffers (300MB+).
        - After change: saw consistent maximum buffer size of 32MB.
      
      Reviewers: amckinley
      
      Reviewed By: amckinley
      
      Maniphest Tasks: T13328
      
      Differential Revision: https://secure.phabricator.com/D20617
      ccf207f2
    • epriestley's avatar
      Limit the read buffer size in `bin/storage dump` · eaa60334
      epriestley authored
      Summary:
      Ref T13328. Currently, we read from `mysqldump` something like this:
      
      ```
      until (done) {
        for (100 ms) {
          mysqldump > in-memory-buffer;
        }
      
        in-memory-buffer > disk;
      }
      ```
      
      This general structure isn't great. In this use case, where we're streaming a large amount of data from a source to a sink, we'd prefer to have a "select()"-like way to interact with futures, so our code is called after every read (or maybe once some small buffer fills up, if we want to do the writes in larger chunks).
      
      We don't currently have this (`FutureIterator` can wake up every X milliseconds, or on future exit, but, today, can not wake for readable futures), so we may buffer an arbitrary amount of data into memory (however much data `mysqldump` can write in 100ms).
      
      Reduce the update frequency from 100ms to 10ms, and limit the buffer size to 32MB. This effectively imposes an artificial 3,200MB/sec limit on throughput, but hopefully that's fast enough that we'll have a "wake on readable" mechanism by the time it's a problem.
      
      Test Plan:
        - Replaced `mysqldump` with `cat /dev/zero` as the source command, to get fast input.
        - Ran `bin/storage dump` with `var_dump()` on the buffer size.
        - Before change: saw arbitrarily large buffers (300MB+).
        - After change: saw consistent maximum buffer size of 32MB.
      
      Reviewers: amckinley
      
      Reviewed By: amckinley
      
      Maniphest Tasks: T13328
      
      Differential Revision: https://secure.phabricator.com/D20617
      eaa60334
  6. 24 Jun, 2019 6 commits
    • epriestley's avatar
      (stable) Make "bin/files" parsing of working set arguments more consistent · ccfc7470
      epriestley authored
      Summary:
      Fixes T13326. In D20571, I slightly generalized construction of an iterator over a set of files, but missed some code in other "bin/files ..." commands which was also affected.
      
      Today, basically all of these workflows define their own "--all" and "names" flags. Pull these definitions up and implement them more consistently.
      
      Test Plan: Ran multiple different `bin/files` commands with different combinations of arguments, saw consistent handling of iterator construction.
      
      Reviewers: amckinley
      
      Reviewed By: amckinley
      
      Maniphest Tasks: T13326
      
      Differential Revision: https://secure.phabricator.com/D20614
      ccfc7470
    • epriestley's avatar
      (stable) Consider "all account members are disabled" to be a permanent failure... · d1704f04
      epriestley authored
      (stable) Consider "all account members are disabled" to be a permanent failure when billing a Phortune subscription
      
      Summary:
      Fixes T13327. Currently, when we try to bill an account and all members are disabled, we fail temporarily and the task retries forever.
      
      At least for now, just treat this as a permanent failure.
      
      Test Plan:
        - Used `bin/phortune invoice` to generate a normal invoice for a regular subscription.
        - Disabled all the account members, then tried again. Got a helpful permanent failure:
      
      ```
      $ ./bin/phortune invoice --subscription PHID-PSUB-kbedwt5cyepoc6tohjq5 --auto-range
      Set current time to Mon, Jun 24, 2:47 PM.
      Preparing to invoice subscription "localb.phacility.com" from Fri, May 31, 10:14 AM to Sun, Jun 30, 10:14 AM.
       WARNING
      Manually invoicing will double bill payment accounts if the range overlaps an
      existing or future invoice. This script is intended for testing and
      development, and should not be part of routine billing operations. If you
      continue, you may incorrectly overcharge customers.
      
          Really invoice this subscription? [y/N] y
      
      [2019-06-24 14:47:57] EXCEPTION: (PhabricatorWorkerPermanentFailureException) All members of the account ("PHID-ACNT-qp54y3unedoaxgkkjpj4") for this subscription ("PHID-PSUB-kbedwt5cyepoc6tohjq5") are disabled. at [<phabricator>/src/applications/phortune/worker/PhortuneSubscriptionWorker.php:88]
      arcanist(head=experimental, ref.master=d92fa96366c0, ref.experimental=db4cd55d4673), corgi(head=master, ref.master=6371578c9d32), instances(head=stable, ref.master=ba9e4a19df1c, ref.stable=37fb1f4917c7), libcore(), phabricator(head=master, ref.master=65bc481c, custom=11), phutil(head=master, ref.master=7adfe4e4f4a3), services(head=master, ref.master=5424383159ac)
        #0 PhortuneSubscriptionWorker::doWork() called at [<phabricator>/src/infrastructure/daemon/workers/PhabricatorWorker.php:124]
        #1 PhabricatorWorker::executeTask() called at [<phabricator>/src/infrastructure/daemon/workers/PhabricatorWorker.php:163]
        #2 PhabricatorWorker::scheduleTask(string, array, array) called at [<phabricator>/src/applications/phortune/management/PhabricatorPhortuneManagementInvoiceWorkflow.php:169]
        #3 PhabricatorPhortuneManagementInvoiceWorkflow::execute(PhutilArgumentParser) called at [<phutil>/src/parser/argument/PhutilArgumentParser.php:457]
        #4 PhutilArgumentParser::parseWorkflowsFull(array) called at [<phutil>/src/parser/argument/PhutilArgumentParser.php:349]
        #5 PhutilArgumentParser::parseWorkflows(array) called at [<phabricator>/scripts/setup/manage_phortune.php:21]
      $
      ```
      
      Reviewers: amckinley
      
      Reviewed By: amckinley
      
      Maniphest Tasks: T13327
      
      Differential Revision: https://secure.phabricator.com/D20613
      d1704f04
    • epriestley's avatar
      Make "bin/files" parsing of working set arguments more consistent · da0dfc05
      epriestley authored
      Summary:
      Fixes T13326. In D20571, I slightly generalized construction of an iterator over a set of files, but missed some code in other "bin/files ..." commands which was also affected.
      
      Today, basically all of these workflows define their own "--all" and "names" flags. Pull these definitions up and implement them more consistently.
      
      Test Plan: Ran multiple different `bin/files` commands with different combinations of arguments, saw consistent handling of iterator construction.
      
      Reviewers: amckinley
      
      Reviewed By: amckinley
      
      Maniphest Tasks: T13326
      
      Differential Revision: https://secure.phabricator.com/D20614
      da0dfc05
    • epriestley's avatar
      Consider "all account members are disabled" to be a permanent failure when... · a3397fb8
      epriestley authored
      Consider "all account members are disabled" to be a permanent failure when billing a Phortune subscription
      
      Summary:
      Fixes T13327. Currently, when we try to bill an account and all members are disabled, we fail temporarily and the task retries forever.
      
      At least for now, just treat this as a permanent failure.
      
      Test Plan:
        - Used `bin/phortune invoice` to generate a normal invoice for a regular subscription.
        - Disabled all the account members, then tried again. Got a helpful permanent failure:
      
      ```
      $ ./bin/phortune invoice --subscription PHID-PSUB-kbedwt5cyepoc6tohjq5 --auto-range
      Set current time to Mon, Jun 24, 2:47 PM.
      Preparing to invoice subscription "localb.phacility.com" from Fri, May 31, 10:14 AM to Sun, Jun 30, 10:14 AM.
       WARNING
      Manually invoicing will double bill payment accounts if the range overlaps an
      existing or future invoice. This script is intended for testing and
      development, and should not be part of routine billing operations. If you
      continue, you may incorrectly overcharge customers.
      
          Really invoice this subscription? [y/N] y
      
      [2019-06-24 14:47:57] EXCEPTION: (PhabricatorWorkerPermanentFailureException) All members of the account ("PHID-ACNT-qp54y3unedoaxgkkjpj4") for this subscription ("PHID-PSUB-kbedwt5cyepoc6tohjq5") are disabled. at [<phabricator>/src/applications/phortune/worker/PhortuneSubscriptionWorker.php:88]
      arcanist(head=experimental, ref.master=d92fa96366c0, ref.experimental=db4cd55d4673), corgi(head=master, ref.master=6371578c9d32), instances(head=stable, ref.master=ba9e4a19df1c, ref.stable=37fb1f4917c7), libcore(), phabricator(head=master, ref.master=65bc481c, custom=11), phutil(head=master, ref.master=7adfe4e4f4a3), services(head=master, ref.master=5424383159ac)
        #0 PhortuneSubscriptionWorker::doWork() called at [<phabricator>/src/infrastructure/daemon/workers/PhabricatorWorker.php:124]
        #1 PhabricatorWorker::executeTask() called at [<phabricator>/src/infrastructure/daemon/workers/PhabricatorWorker.php:163]
        #2 PhabricatorWorker::scheduleTask(string, array, array) called at [<phabricator>/src/applications/phortune/management/PhabricatorPhortuneManagementInvoiceWorkflow.php:169]
        #3 PhabricatorPhortuneManagementInvoiceWorkflow::execute(PhutilArgumentParser) called at [<phutil>/src/parser/argument/PhutilArgumentParser.php:457]
        #4 PhutilArgumentParser::parseWorkflowsFull(array) called at [<phutil>/src/parser/argument/PhutilArgumentParser.php:349]
        #5 PhutilArgumentParser::parseWorkflows(array) called at [<phabricator>/scripts/setup/manage_phortune.php:21]
      $
      ```
      
      Reviewers: amckinley
      
      Reviewed By: amckinley
      
      Maniphest Tasks: T13327
      
      Differential Revision: https://secure.phabricator.com/D20613
      a3397fb8
    • epriestley's avatar
      Remove "phd.pid-directory" configuration and stop passing "piddir" to daemons · 65bc481c
      epriestley authored
      Summary: Ref T13321. The daemons no longer write PID files, so we no longer need to pass any of this stuff to them.
      
      Test Plan: Grepped for affected symbols.
      
      Reviewers: amckinley
      
      Reviewed By: amckinley
      
      Maniphest Tasks: T13321
      
      Differential Revision: https://secure.phabricator.com/D20608
      65bc481c
    • epriestley's avatar
      Make "phd start" and "phd reload" use the process list, not PID files · 2498e373
      epriestley authored
      Summary:
      Ref T13321. This gets rid of the last pidfile readers in Phabricator; we just use the process list instead.
      
      These commands always only work on the current instance since they don't make much sense otherwise.
      
      Test Plan: Ran `bin/phd start` and `bin/phd reload` with and without daemons running.
      
      Reviewers: amckinley
      
      Reviewed By: amckinley
      
      Maniphest Tasks: T13321
      
      Differential Revision: https://secure.phabricator.com/D20606
      2498e373