We'll probably have the use case in the near future to allow developers to allocate resources (such as a VM for running functional tests or deploying their code onto). In this case we'll probably need:
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Resolved | epriestley | T8089 Unprototype Harbormaster (v1) | ||
| Resolved | epriestley | T8097 Allow external systems to report results into Harbormaster | ||
| Resolved | None | T7419 Provide a straightforward way to create and update CI test statuses for a revision | ||
| Wontfix | epriestley | T4591 Allow Harbormaster to source GitHub pull requests as buildables | ||
| Resolved | epriestley | T5479 Unbeta Phragment | ||
| Duplicate | None | T7869 Support CircleCI webhooks for Test results (so that one can run unit tests asynchronously) | ||
| Resolved | epriestley | T1049 Implement Harbormaster | ||
| Wontfix | epriestley | T1816 Support downloading a compressed working copy (tar/zip) of a repository at a specific commit or tag | ||
| Resolved | epriestley | T2015 Implement Drydock | ||
| Duplicate | None | T6193 Allow Arcanist to allocate resources through Drydock |
Pretty sure this is the same as T6076; I'm going to merge that here.
I don't plan to pursue this any time soon, although it's presumably straightforward after Drydock is mature enough to have an API, and may become trivial (via arc call-conduit) before then since Drydock/Harbormaster actions generally act via Conduit anyway. If the required APIs are non-specialized, this is probably blocked by T5955 + T7715, but I'd guess that the relevant APIs are probably specialized.
(I'd also generally expect these use cases to act via Harbormaster (roughly, "run build X on my current working copy state"), since the pathway there seems short and straightforward (push to staging area, create some kind of Buildable, dump that into Harbormaster) and that seems like the command users would want to run, not arc drydock allocate-resource.)