Page MenuHomePhabricator

[DRAFT] Implement `arc try` workflow using staging repositories
AbandonedPublic

Authored by hach-que on Jun 1 2015, 5:50 PM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, Nov 20, 9:38 AM
Unknown Object (File)
Sat, Nov 16, 12:17 PM
Unknown Object (File)
Tue, Nov 12, 2:45 PM
Unknown Object (File)
Fri, Nov 8, 11:45 AM
Unknown Object (File)
Sun, Nov 3, 7:19 PM
Unknown Object (File)
Sat, Oct 26, 6:07 AM
Unknown Object (File)
Oct 14 2024, 9:46 PM
Unknown Object (File)
Oct 1 2024, 1:19 AM

Details

Reviewers
epriestley
Group Reviewers
Blessed Reviewers
Summary

This implements a very basic arc try workflow, which pushes the current HEAD to the staging repository URL and starts a manual Harbormaster build on it. The build plan to execute is configured with the "try.buildplanid" configuration option in .arcconfig (but probably should have an optional argument as well).

Test Plan

Tested it locally with arc try.

Diff Detail

Repository
rARC Arcanist
Branch
harbormaster-try-2
Lint
Lint Passed
Unit
Tests Passed
Build Status
Buildable 6426
Build 6448: [Placeholder Plan] Wait for 30 Seconds

Event Timeline

hach-que retitled this revision from to [DRAFT] Implement `arc try` workflow using staging repositories.
hach-que updated this object.
hach-que edited the test plan for this revision. (Show Details)

Can we still discuss the name of the command? I kind of feel "try" is too short/important for this.
maybe "run-build" or "try-build" or "build-head"?

epriestley added a reviewer: epriestley.

I don't plan to upstream this:

  • It requires manually configuring exactly one build plan. Although this could be improved, it can't really ever share the configuration with the normal pipeline. A major advantage of triggering this through arc diff --try is that we can just run revision plans normally, using normal rules, without any additional configuration. I think having a single source of authority about which plans run is important, and that many installs will have multiple plans, changing configuration, or both.
  • It requires you to sit and wait for results, and doesn't really provide a way to walk away and review them later. A major advantage of triggering this through arc diff --try is that you get a persistent object which you can return to later to review results.
This revision now requires changes to proceed.Jun 5 2015, 2:18 PM

Specifically, the larger plan is:

  • Implement a "draft" revision state (T2543) which doesn't add reviewers yet or trigger Herald rules.
  • Add a workflow whereby arc diff submits revisions into the "draft" state and runs builds on them.
    • Depending on flags, config, etc., maybe this is default or maybe it's --try, and maybe when the builds pass the revision automatically moves into review or maybe not, and if it's --try the flag might have a different name like --build-first.

Yeah that makes sense. This was far more of a proof of concept than anything else. (I don't think I even added you as a reviewer when submitting this, but I think Herald automatically added you)

That said, this is pretty neat.