1
0
Fork 0
mirror of https://we.phorge.it/source/arcanist.git synced 2024-12-18 11:30:54 +01:00
Commit graph

2433 commits

Author SHA1 Message Date
epriestley
d0eb822e37 Remove "--lintall" and "--only-new" flags to "arc diff"
Summary:
Ref T13544. These flags change the behavior of the "arc lint" subprocess.

I believe there is no reason to ever use "arc diff --lintall". If you want to find extra warnings to fix, you can use "arc lint --lintall" to express this intent.

Use of "arc diff --only-new" almost certainly means your linters are raising messages at "error" severity which should instead be raised at "warning" severity. If you only care about fixing a particular type of error in changed code, it should be raised as a "warning". The correct remedy is to adjust the severity, not use "--only-new", which is a very broad, slow, complicated hammer.

Test Plan: Searched for "lintall" and "only-new" in this workflow. These flags still exist in "arc lint", but may be changed in the future. Generated this change.

Maniphest Tasks: T13544

Differential Revision: https://secure.phabricator.com/D21298
2020-06-05 13:24:48 -07:00
epriestley
76dc154955 Remove lint and unit excuses and "--advice" and "--excuse" flags from "arc diff"
Summary:
Ref T13544. Long ago, "arc diff" started prompting the user to provide "excuses" when they submitted changes with failing lint or unit tests.

At the time, "arc" was generally more heavy-handed and the review workflow had fewer points where it provided feedback about lint and test issues.

As the workflow has evolved, there is now significantly more feedback (promotion behavior from Draft in Differential, warnings on "arc land", etc). These days, these prompts feel archaic and like they're just getting in the way.

When lint/unit have Harbormaster-triggered components, this prompt is also too early (since Harbormaster tests may fail or raise lint messages later). A modern version of this would look more like putting revisions in some kind of locked state until authors explain issues. It's possible that's worth building, but I'd like to see more interest in it. I suspect this feature is largely just a "nag" feature these days with few benefits.

Test Plan: Grepped for "advice", "excuse", "handleServerMessage", "sendMessage", "getSkipExcuse", "getErrorExcuse", got no hits. Generated this revision.

Maniphest Tasks: T13544

Differential Revision: https://secure.phabricator.com/D21297
2020-06-05 13:22:00 -07:00
epriestley
ff3cea78ee Remove "--use-commit-message/-C" from "arc diff"
Summary:
Ref T13544. This flag was introduced in D1385 (2012) as part of a workflow which no longer exists. I can't recall anyone ever reporting an issue which involves its use and believe it is likely unused. It's not obvious to me why someone would use it in modern "arc".

(The same goal can be accomplished with "--message-file ...", although this requires more steps.)

Test Plan: Grepped for "use-commit-message" and "getCommitMessageFromCommit", ran "arc diff".

Maniphest Tasks: T13544

Differential Revision: https://secure.phabricator.com/D21296
2020-06-05 13:22:00 -07:00
epriestley
6af46f289a Support short aliases and repeatable arguments in Arcanist Workflow arguments
Summary: Ref T13546. Add support for short "-x" flags and repeatable "--say moo --say quack" flags.

Test Plan: In future changes, used "arc diff -m" and "arc land --onto ... --onto ...".

Maniphest Tasks: T13546

Differential Revision: https://secure.phabricator.com/D21310
2020-06-05 12:47:43 -07:00
epriestley
7c80a9006d Add a "%?" ("hint") conversion to "tsprintf()"
Summary: Ref T13546. Future "arc land" workflows use this element to provide "hint" or "next step" suggestions to make error resolution easier.

Test Plan: Ran future "arc land" workflows, saw tips like "use --revision to do such-and-such" or "add these files to .gitignore".

Maniphest Tasks: T13546

Differential Revision: https://secure.phabricator.com/D21309
2020-06-05 12:22:09 -07:00
epriestley
0e82474007 Support appending arbitrary lines to DisplayRef output
Summary:
Ref T13546. Several substeps in the new "arc land" flow benefit from this. For example:

  - When prompting "land revisions you don't own?", it's used to show authors.
  - When prompting "land revisions in the wrong state?", it's used to show the current states.

Test Plan: Ran future "arc land" workflows, got relevant contextual information via this mechanism.

Maniphest Tasks: T13546

Differential Revision: https://secure.phabricator.com/D21308
2020-06-05 12:22:09 -07:00
epriestley
fc3974ed70 Impose a HardpointEngine future parallelism limit
Summary:
Ref T13546. If we try to resolve several hundred hardpoint queries which execute subprocesses, we can currently hit system limits.

For now, limit resolution to 32 simultaneous futures. In the future, this should switch to `FuturePool` and possibly become more nuanced.

Test Plan: In a future change, ran `arc land --into-empty ...` to land thousands of commits. Before change, got a "proc_open()" error when launching too many simultaneous subprocesses. After change, this "worked".

Maniphest Tasks: T13546

Differential Revision: https://secure.phabricator.com/D21307
2020-06-05 12:15:47 -07:00
epriestley
7378e2baad Remove special casing of "arc --version"
Summary: See PHI1765. You can find version information with "arc version". Remove this undocumented special-case.

Test Plan:
  - Ran `arc --version`, no longer got a workflow API exception.
  - Searched the documentation for references to `arc --version` (instead of `arc version`), found none.

Differential Revision: https://secure.phabricator.com/D21306
2020-06-02 08:58:06 -07:00
epriestley
0da1a2e17d Allow PhutilArrayCheck to accept a list of objects as a context
Summary: This simplifies merging a list-of-lists, which is a common pattern when asking a list of extensions to each provide some kind of list of items.

Test Plan: Used elsewhere in Piledriver.

Differential Revision: https://secure.phabricator.com/D21294
2020-05-30 03:37:42 -07:00
epriestley
a0c346bf63 Add a support class to simplify typechecking list-of-objects return values
Summary:
With some frequency, code wants to assert that some "$o->m()" returns a list of objects of type X, possibly with unique values for some "getKey()"-style method result.

Existing checks via `PhutilTypeMap` and `assert_instances_of()` aren't quite powerful enough to do this while producing an easily understandable error state. We want to know that the error arose from a call to "$o->m()" in particular.

Test Plan: Currently used elsewhere, in Piledriver code.

Differential Revision: https://secure.phabricator.com/D21293
2020-05-28 07:33:23 -07:00
epriestley
c76cfc8c82 Mark the wildcard argument to "arc liberate" as a path argument for shell completion
Summary: This is a path argument, and shell completion should suggest tabs.

Test Plan: Typed "arc liberate s<tab>", got path suggestions.

Differential Revision: https://secure.phabricator.com/D21292
2020-05-28 07:33:12 -07:00
epriestley
fce72b9c89 Make lint tests handle paths better and distinguish between "0" and "null" more carefully
Summary:
Ref T13543. Currently, the `cpplint` tests do not function because `cpplint` is passed a path which does not end in a suffix it recognizes.

Change the tempfile / path code to pass `linter path/to/example.c`-style linters a path they expect.

Then, correct some older code which was playing it fast-and-loose with "null" vs "0".

Test Plan: Ran `arc unit --everything`, got a clean bill of health on all the linters I have installed. (This is probably not all tests, since I have only a subset of linters installed locally that we have code for.)

Maniphest Tasks: T13543

Differential Revision: https://secure.phabricator.com/D21291
2020-05-27 12:38:11 -07:00
epriestley
e69aa32603 Fix an issue when rendering a lint message which removes whitespace at the end of a file
Summary:
Ref T13543. If a file ends in spaces and no newline, we'll emit a message suggesting removal of the spaces. This will effectively remove the line, but the code will then attempt to highlight text within the line.

Prior to D21044 this continued without raising an error and produced a reasonable result, but it now fatals. Insetad, don't try to highlight lines which no longer exist.

Test Plan: See T13543 for details.

Maniphest Tasks: T13543

Differential Revision: https://secure.phabricator.com/D21290
2020-05-27 11:28:16 -07:00
epriestley
25ee39b657 In the "cpplint" binding, raise messages on "line 0" without a line
Summary:
Ref T13543. The "cpplint.py" script may emit messages on line 0, but Arcanist doesn't accept these messages.

This is a small piece of a whole set of broader issues, but stop the bleeding for now.

Test Plan:
  - Ran `arc lint example.h` on a file with no `#ifndef` guard, and `cpplint` configured.
  - Cpplint raised a message at line "0".
  - Before change: arc choked when trying to render this.
  - After change: arc survives rendering.

Maniphest Tasks: T13543

Differential Revision: https://secure.phabricator.com/D21289
2020-05-27 10:59:10 -07:00
epriestley
e3030ebcad Allow construction of a ConduitEngine with a bare ConduitClient
Summary:
See PHI1735. "ConduitEngine" was once a future pool, but this has moved to "HardpointEngine". This class may no longer make much sense.

In Phacility code, "bin/host upload" depends on using the Uploader, which needs a "ConduitEngine", not a "ConduitClient". This workflow may use asymmetric key signing, which "ConduitEngine" does not support.

To unblock PHI1735, provide glue code between "Client" and "Engine". But a "more correct" change is probably removal of "Engine".

Test Plan:
  - Ran `bin/host upload`, uploaded files (with additional changes to wrap the Client).
  - Created this revision.

Differential Revision: https://secure.phabricator.com/D21260
2020-05-15 08:24:10 -07:00
Aviv Eyal
2d8156a727 update SSL error messge re:libphutil
Test Plan: ╰(*°▽°*)╯

Reviewers: epriestley, #blessed_reviewers

Reviewed By: epriestley, #blessed_reviewers

Subscribers: Korvin

Differential Revision: https://secure.phabricator.com/D21258
2020-05-15 12:15:50 +00:00
epriestley
b76b9c4065 Add "HTTPSFuture->addCurlOption()" for raw access to "curl_setopt()"
Summary: Fixes T13533. This is a narrow, fragile API for a particular Kerberos use case on one install.

Test Plan:
- Set a non-scalar key, got an exception.
- Set <"duck", "quack">, got an exception from cURL that the value was invalid.
- Set a bunch of made-up options to arbitrary values, no errors. cURL accepts anything so there's nothing we can do about this.
- Set `CURLOPT_NOBODY` and saw the request behavior change, demonstrating that the call can produce effects.

Maniphest Tasks: T13533

Differential Revision: https://secure.phabricator.com/D21251
2020-05-14 09:16:36 -07:00
epriestley
6937d38947 Fix an initialization issue in VectorTree
Summary: Ref T13520. In unusual cases where there are no changes in a changeset list (e.g., empty commits) we can fatal when trying to iterate over an empty list of vectors.

Test Plan:
  - Created an empty commit.
  - Used "git show | pbcopy" to create a diff from it.
  - Viewed it in the web UI.
  - Before: fatal when iterating on `null`.
  - After: clean page.

Maniphest Tasks: T13520

Differential Revision: https://secure.phabricator.com/D21221
2020-05-04 15:50:26 -07:00
epriestley
af9faba02f Add "--browse" and "--input" to "arc paste", and remove "--json" (which had no effect)
Summary:
Ref T13528. For consistency with other commands ("arc upload", "arc diff"), support a "--browse" flag to "arc paste".

Support "--input" as a more robust alternative to `x | y` (see T6996).

Test Plan: Ran `arc paste --browse --input X`, got a new paste in a browser window. Ran other variations of flags and parameters.

Maniphest Tasks: T13528

Differential Revision: https://secure.phabricator.com/D21203
2020-05-01 09:13:20 -07:00
epriestley
c0d151e0e9 Add "--browse" to "arc upload" and update behavior, particularly "--json"
Summary:
Ref T13528. Provide a "--browse" flag to open files after they are uploaded.

Update the code to use modern query strategies.

This impacts the output of "--json", which was just raw "file.info" output before and could not represent the same path being passed several times (`arc upload X X`).

Test Plan: Ran `arc upload` with `--browse` and `--json`.

Maniphest Tasks: T13528

Differential Revision: https://secure.phabricator.com/D21202
2020-05-01 09:13:01 -07:00
epriestley
5448fe2165 When recent PHP raises a "broken pipe" error in ExecFuture, treat it as a blocked stdin
Summary:
Ref T13528. If we start a subprocess that immediately exits and then write to it, we can get a broken pipe error.

Recent versions of PHP appear to raise this as an actual warning, and recent changes upgrade the warning to a runtime exception.

I can't find any way to tell if the RuntimeException is a broken pipe or something else, except by examining the text of the error string.

At least for now, treat this like a "blocked pipe" condition. Since the subprocess has exited and the bytes didn't write, this should generally be reasonable.

Test Plan:
  - Viewed a file in Paste with an extension that Pygments does not have a lexer for.
  - This causes Pygments to exit immediately with an "unrecognized lexer" error. This closes the pipe, and the next write will fail with a broken pipe error.
  - Before patch: fatal on broken pipe.
  - After patch: clean resolution of the future and error condition.

Maniphest Tasks: T13528

Differential Revision: https://secure.phabricator.com/D21199
2020-05-01 09:12:43 -07:00
epriestley
a77cfb023d When a proxy future wraps a future which throws an exception, resolve with an exception
Summary:
Ref T13528. When you call `$future->resolve()`, we currently guarantee it is resolved by calling `FutureIterator->resolveAll()`.

`resolveAll()` does not actually "resolve()" futures: it guarantees that they are ready to "resolve()", but does not actually call "resolve()".

In particular, this means it does not throw exceptions.

This can lead to a case where a Future has "resolve()" called directly (e.g., via a FutureProxy), uses "FutureIterator" to resolve itself, throws an exception inside "FutureIterator", the exception is captured and attached to the Futuer, then the outer future tries to access results. This fails since it's out-of-order.

This can happen in practice with syntax highlighting futures, which may proxy pygments futures.

Instead, "resolveAll()" before testing for exaceptions.

Test Plan:
  - Locally, tried to highlight a Paste with an unrecognized lexer extension using Pygments.
  - Before patch: fatal when trying to access results of a Future with no results (because it has an exception instead).
  - After patch: resolution throws the held exception properly.
  - (See also next change.)

Maniphest Tasks: T13528

Differential Revision: https://secure.phabricator.com/D21198
2020-05-01 09:12:22 -07:00
epriestley
696ec3f975 Work around "mb_check_encoding(<stringlike-object>)" warning in particular versions of PHP
Summary: Fixes T13527. Some versions of PHP strictly require that we pass a string value, and reject "stringlike" objects (objects which implement "__toString()").

Test Plan: Ran unit test, although this is somewhat aspirational because my local PHP version isn't affected.

Maniphest Tasks: T13527

Differential Revision: https://secure.phabricator.com/D21193
2020-04-30 07:19:45 -07:00
epriestley
284139a24e Restore the ":(attr:filter=lfs)" test for LFS
Summary:
See D21190. The ".gitattributes" approach fails when ".gitattributes" is in a subdirectory (or global). These are probably unusual cases, but at least one is known in the wild.

Instead:

  - Restore the ":(attr:filter=lfs)" test, which seems to be the fastest accurate test available in modern Git.
  - If the test fails, assume the repository is not LFS. This only impacts users running very old versions of Git.

Test Plan:
  - In LFS and non-LFS repositories, created diffs. Saw correct detection again.
  - Broke the command on purpose, saw LFS detection conclude "no LFS", but not fail disastrously.

Subscribers: ptarjan

Differential Revision: https://secure.phabricator.com/D21192
2020-04-29 21:04:44 -07:00
epriestley
ade9b51a1f Detect LFS by looking for tracks in ".gitattributes" instead of using "ls-tree"
Summary:
See PHI1718. See also <https://discourse.phabricator-community.org/t/arc-diff-fails-due-to-git-cmd-fails/3680/>.

Currently, `arc diff` detects Git LFS with `git ls-files -z -- ':(attr:filter=lfs)'` magic. This is an accurate test, but does not work on older Git.

Try a simpler, dumber test and see if that will work. If this also has issues, we can try this stuff:

  - do version detection;
  - pipe the whole tree to `git check-attr`;
  - try a command like `git lfs ls-files` instead, which is probably a wrapper on one of these other commands.

Test Plan:
  - In a non-LFS repository, ran "arc diff" and saw the repository detect as non-LFS.
  - In an LFS repository, ran "arc diff" and saw the repository detect as LFS.

Differential Revision: https://secure.phabricator.com/D21190
2020-04-29 16:23:44 -07:00
epriestley
6ec09b2f48 Replace "PhutilFileTree" with a more abstract "VectorTree"
Summary:
Ref T13520. Replace "FileTree" with a "VectorTree" that does roughly the same thing. The major goals are:

  - Compress trees which contain sequences of child directories with no sibilings.
  - Build hierarchies of paths where path components may include renames.

This is approximately similar to "FileTree" and similar to client logic in the new paths panel.

Test Plan: See next change.

Maniphest Tasks: T13520

Differential Revision: https://secure.phabricator.com/D21182
2020-04-28 12:09:56 -07:00
epriestley
b81818b287 Accommodate PHP 7.4 changes to certain "preg_match_all()" calls
Summary:
Ref T13518. The result format of this call changed in PHP 7.4, which causes us to emit "-1" matches because "-1" survives `array_filter()`.

Filter results in a way that should survive both result formats.

Test Plan: Ran `arc unit --everything` under PHP 7.4.

Maniphest Tasks: T13518

Differential Revision: https://secure.phabricator.com/D21173
2020-04-26 08:40:08 -07:00
epriestley
bf76fa547d Make "arc <workflow> --help" work again for workflows which haven't updated yet
Summary:
See <https://discourse.phabricator-community.org/t/help-is-no-longer-present-for-arc-subcommands-in-todays-stable/3786>.

The "--help" flag ends up falling through to the old "arcanist.php", where it becomes lost. Catch it earlier so "arc diff --help" prints diff help, for instance.

Test Plan: Ran `arc help diff`, `arc diff --help`, `arc --help diff`, and similar commands for updated workflows; got help.

Differential Revision: https://secure.phabricator.com/D21168
2020-04-25 08:57:28 -07:00
epriestley
68f050bd14 Allow HTTPFuture callers to disable processing of "Content-Encoding" response headers
Summary: Ref T13507. In Phabricator, we perform a specific "Accept-Encoding: gzip" setup test and want to manually decode the result. Allow callers to disable handling of "Content-Encoding".

Test Plan: Ran all Phabricator setup checks.

Maniphest Tasks: T13507

Differential Revision: https://secure.phabricator.com/D21121
2020-04-15 06:28:25 -07:00
epriestley
377ed2ed8d If the Conduit server asserts it has the "gzip" capability, compress requests
Summary:
Ref T13507. For various messy reasons we can't blindly assume the server supports "gzip" -- but if the server tells us it does, we're on firmer ground.

If the server returns an "X-Conduit-Capabilities: gzip" header and we have compression support locally, compress subsequent requests.

This restores D21073, which was reverted by D21076.

Test Plan: With a gzip-asserting server, added debugging code and ran various "arc" commands. Saw the 2nd..Nth calls hit compression code.

Maniphest Tasks: T13507

Differential Revision: https://secure.phabricator.com/D21119
2020-04-14 16:50:54 -07:00
epriestley
a77da426af If the Conduit client supports gzip, make calls with "Accept-Encoding: gzip"
Summary:
Ref T13507. Add "Accept-Encoding: gzip" to requests if we can decompress responses.

When we receive a compressed response, decompress it.

Test Plan: Added debugging code, ran some commands, saw smaller payloads over the wire and inline decompression.

Maniphest Tasks: T13507

Differential Revision: https://secure.phabricator.com/D21118
2020-04-14 16:23:53 -07:00
epriestley
890b57de1e In "phutil_loggable_string()", encode every byte above 0x7F
Summary:
Ref T13507. Currently, this function is a bit conservative about what it encodes, and passing it a string of binary garbage may result in an output which is not valid UTF8.

This could be refined somewhat, since it's less than ideal if the input has valid UTF8. The ideal behavior for byte sequences where all bytes are larger than 0x7F is probably a variation of "phutil_utf8ize()" that replaces bytes with "<0xXX>" instead of the Unicode error glyph.

For now, just err on the side of mangling.

Test Plan: Dumped various binary payloads in the new gzip setup check, saw sensible output in the web UI.

Maniphest Tasks: T13507

Differential Revision: https://secure.phabricator.com/D21117
2020-04-14 16:03:12 -07:00
epriestley
9d0100bda7 Only inject legacy Arcanist workflows into "help" if run from the context of an Arcanist runtime
Summary: Ref T13490. This code is reachable from Phabricator binaries; only inject the legacy stuff if we're in an Arcanist stack.

Test Plan: Ran `bin/conduit help` from `phabricator/`.

Maniphest Tasks: T13490

Differential Revision: https://secure.phabricator.com/D21113
2020-04-14 13:24:00 -07:00
epriestley
d408a80ae1 Update "arc paste" for Toolsets
Summary: Ref T13490. More-or-less straightforward upgrade to modern calls.

Test Plan: Created and viewed pastes.

Maniphest Tasks: T13490

Differential Revision: https://secure.phabricator.com/D21104
2020-04-13 15:01:51 -07:00
epriestley
c8dd2a3753 Crudely bridge legacy workflows into "arc help"
Summary:
Ref T13490. One of the biggest issues users are hitting in modern "arc" is that workflows don't appear in "arc help" until they're updated.

Since there's still some work to do and gluing them in isn't terribly difficult, at least get things connected for now.

Test Plan: Ran "arc help", "arc help diff".

Maniphest Tasks: T13490

Differential Revision: https://secure.phabricator.com/D21101
2020-04-13 11:41:05 -07:00
epriestley
196f8f54ce Remove "backout", "close", "flag", "start", "stop", "time", and "revert" workflows
Summary: Ref T13490. These workflows don't seem worth the maintenance cost, see T13488 for discussion.

Test Plan: Grepped for methods which looked like they might only be called by these flows, only dug up the backout stuff.

Maniphest Tasks: T13490

Differential Revision: https://secure.phabricator.com/D21100
2020-04-13 07:09:49 -07:00
epriestley
4719341c27 Upgrade (most) Differential API callsites to "differential.revision.search"
Summary: Ref T13490. The "RevisionRef" is currently based on "differential.query" data, but all calls other than the hash-based lookup can move to "differential.revision.search".

Test Plan: Ran revision workflows like `arc inspect` and `arc browse`.

Maniphest Tasks: T13490

Differential Revision: https://secure.phabricator.com/D21099
2020-04-13 06:42:25 -07:00
epriestley
ab589ab31d Restore "%d" support to "tsprintf()"
Summary: Ref T13490. I recently made "tsprintf()" more strict, but we do sometimes use "%d" and this is reasonable to support.

Test Plan: Ran "arc branch".

Maniphest Tasks: T13490

Differential Revision: https://secure.phabricator.com/D21098
2020-04-13 04:35:59 -07:00
epriestley
21e80a635d Upgrade "arc download" to Toolsets
Summary:
Ref T13490. This is mostly straightforward.

  - Drop "--show" in favor of "--as -".
  - Drop support for 4+ year old "file.info" API.
  - Use modern stream-to-disk support so we get a real progress bar and don't need to buffer files into memory.

Test Plan: Downloaded various files, including large files.

Maniphest Tasks: T13490

Differential Revision: https://secure.phabricator.com/D21097
2020-04-12 16:18:03 -07:00
epriestley
076f7be484 Update "arc call-conduit" for Toolsets
Summary: Ref T13490. Fairly straightforward update.

Test Plan: Made various Conduit calls.

Maniphest Tasks: T13490

Differential Revision: https://secure.phabricator.com/D21096
2020-04-12 16:17:47 -07:00
epriestley
0f2e277cd9 Update "arc amend" for Toolsets
Summary: Ref T13490. Moves "arc amend" to Toolsets with modern ref/hardpoint code.

Test Plan: Ran "arc amend --show", "--revision", etc. Hit all the prompts and errors, probably?

Maniphest Tasks: T13490

Differential Revision: https://secure.phabricator.com/D21095
2020-04-12 13:48:26 -07:00
epriestley
ff4c1e7c81 Add a "SymbolEngine" to support top-level ref resolution by symbol
Summary:
Ref T13490. I'm continuing to move toward modernizing "amend", which needs to load some objects by symbol at top level.

Add an API to support this.

Test Plan: Added an API caller to "arc inspect", ran it and hit the new code. Things seemed to work.

Maniphest Tasks: T13490

Differential Revision: https://secure.phabricator.com/D21094
2020-04-12 13:48:09 -07:00
epriestley
5fc50c226a Add some support code for printing refs to stdout
Summary: Ref T13490. Make terminal strings work more like HTML does in Phabricator, and make it easier to display refs.

Test Plan: Added some display code, ran `arc inspect` to hit it, saw a nice ref printed.

Maniphest Tasks: T13490

Differential Revision: https://secure.phabricator.com/D21093
2020-04-12 13:44:46 -07:00
epriestley
088b157444 Add ref lookup for username symbols
Summary:
Ref T13490. I'm attempting to update "arc amend", but it needs to fetch revision authors to raise an "amending a revision you don't own" error.

Support user-symbol resolution.

Along the way, this introduces some infrastructure for abstracting away iteration over a multi-page Conduit result set.

Test Plan:
  - Ran "arc inspect ..." for various "user(...)" queries.
  - Set page size to 3 and issued a general query, saw the future page it away properly.

Maniphest Tasks: T13490

Differential Revision: https://secure.phabricator.com/D21092
2020-04-12 13:42:51 -07:00
epriestley
1f18f25fa5 Add a "RevisionSymbolRef", revision commit messages, and make "--explore" recursive
Summary:
Ref T13490.

  - Support resolution of revision symbols into revision objects.
  - Align commit inspection better against commit symbols.
  - Make "arc inspect --explore" recursively load all object hardpoints.
  - Add a "commit message" hardpoint to "RevisionRef".

Test Plan: Used "arc inspect" to resolve commits and revisions. Used "--explore" to see the whole tree.

Maniphest Tasks: T13490

Differential Revision: https://secure.phabricator.com/D21091
2020-04-12 13:24:32 -07:00
epriestley
4cc05c377d Add a "CommitSymbolRef" for resolving symbolic commits into stable commit hashes
Summary:
Ref T13490. Frequently, we know the symbolic name of a commit (like "master") but need the immutable identifier for it (the commit hash).

Provide a Ref and Query for doing this lookup.

Test Plan: Ran `arc inspect symbol(...)` with various symbols, saw appropriate resolutions, nulls, or errors.

Maniphest Tasks: T13490

Differential Revision: https://secure.phabricator.com/D21090
2020-04-12 13:19:53 -07:00
epriestley
92be6df0eb Add a mode to "ExecFuture" that makes "resolvex()" semantics the default
Summary:
Ref T13490. "ExecFuture" can raise a "CommandException" when the subprocess fails. In most cases, this is desirable, since we usually do not expect subprocesses to fail.

Currently, "execx()" (which raises these exceptions) is the synchronous default (with the more verbose "exec_manual()" as an alternative if you expect the command may return an error code), but the Future variation has no way to hint that external resolution should raise an exception if the process exits with an error.

Since the "HardpointEngine" yield construct can resolve external futures, add a mode for this to simplify implementing "HardpointQuery" classes a bit. Without this, they either need to retain "$futures" and manually call "resolvex()", or check the "$err" result and throw some other exception, both of which are low-value boilerplate (queries that want to do this still can, of course).

This is basically like providing a hint that the futures should be resolved with "resolvex()" instead of "resolve()".

Also, make this the default behavior of a new "$api->newFuture()" wrapper.

Test Plan: Intentionally broke a command in a HardpointQuery, got a sensible exception automatically during external future resolution.

Maniphest Tasks: T13490

Differential Revision: https://secure.phabricator.com/D21089
2020-04-12 13:18:11 -07:00
epriestley
73f48aca74 Allow "loadHardpoints()" to accept a single ref and/or a single hardpoint
Summary: Ref T13490. There's more `array(...)` happening in this API than necessary. Sugar it slightly.

Test Plan: Grepped for "loadHardpoints()", ran a couple workflows.

Maniphest Tasks: T13490

Differential Revision: https://secure.phabricator.com/D21088
2020-04-12 13:17:41 -07:00
epriestley
6e24e10bdb Remove obsolete definitions of "defineHardpoints()" in older Ref objects
Summary: Ref T13490. A few older "defineHardpoint()" calls are sticking around. They no longer have callers; get rid of them.

Test Plan: Grepped for this symbol, no hits.

Maniphest Tasks: T13490

Differential Revision: https://secure.phabricator.com/D21087
2020-04-12 13:16:22 -07:00
epriestley
9a198ffcc5 Update "feature", "branch", and "bookmark" flows to report properly in "arc help"
Summary:
Ref T13490. These workflows are aliases of one another, which is a little silly, but currently all identify as "arc feature" in "arc help".

Straighten that out, at least.

Test Plan: Ran "arc help", "arc branch".

Maniphest Tasks: T13490

Differential Revision: https://secure.phabricator.com/D21086
2020-04-12 13:16:07 -07:00