m[2] is the third element of m, rather than the second, so we have to
check instead that the len of m is at least 3.
Because the regular expression has two capture groups, the length of m
will always be 3, so currently the guard will always be true.
The "path" field of a GraphQL error object contains a mix of strings and
numbers and cannot be deserialized into `[]string`. Fortunately, we
don't need to rely on the "path" field and instead have the final error
message be constructed by aggregating human-readable "message" fields.
GitHub REST resources typically return full URLs to fetch related
resources at. We used to parse those URLs to find just the path portion
and pass that in to the `REST()` function, which only accepted paths. By
doing so, we are essential de-constructing a URL just to re-assemble it
again. While re-assembling it for Enterprise, though, we would
accidentally inject an extra `api/v3/` prefix where one was not needed.
The solution is just to use raw URLs as reported by the REST API with
no modifications. This extends the `REST()` function to accept full URLs
in addition to just paths to resources.
For asserting command output, exact string matches are preferred in most cases. In cases when a pattern match is needed, the test can use regexp ad hoc.
