This approximately exists now via T11968.

This is somewhat implemented by D21315, which is headed to master soon. See also T13546 and T12876.

Thanks! I didn't know it could be done from the web UI.

You can open the revision in the web UI and "Request Review". You can use arc diff --browse ... to open the web UI automatically.

We just found a real issue with this, different from what I mentioned above: We had an issue with our CI machine, and to fix it we needed to make a diff. But as the CI machine is not working, the diff won't build, which means we can't accept the diff that will solve the issue.

Is there a way to disable this option via a config in the server or a CLI parameter?

In T550#202580, @epriestley wrote:

I'm planning to support this in the arc experimental branch, although initial support won't be optimized. We can look at ControlPath and/or adding batching to the protocol layer to improve performance once it works.

Any update on when this is going to reach stable? We're ~16 weeks past the earlier estimate...

The complexity of handling this makes adding a "the whole repository is caught up, deal with it" from T4453#13 sort of step more attractive. This would be far easier to motivate if we had more stuff that suffered from similar issues, though.

You will soon be able to give builds different "Hold Drafts" behaviors. See T13258.

I do have a real-life example where the prose diff engine rendered a suboptimal diff. I was able to fix it by changing the maximum length of the edit distance matrix from 128 to 256.

A specific subcase here is when the binding to an Almanac host has been disabled. We should possibly test this during Interface construction, treat it as a failure, then recover from it.

I think this has failed to collect any compelling use cases in several years and don't plan to pursue it.

@bgamari Did you ever find a solution?

In T8510#200946, @aklapper wrote:

In https://phabricator.wikimedia.org/T76732#2803813 ksmith brings up that "In the search bar in the toolbar at the top of the screen, searching for "Maps" brings up Maps as the third option. Searching for "Discovery" brings up Discovery as the second option."

@epriestley, can you confirm that the above patch should disable the draft state? I have applied it to GHC's Phabricator deployment yet we are still seeing Differentials opened in draft state.

GHC recently upgraded its Phabricator installation and has been rather unpleasantly affected by this feature. We have multi-hour CI jobs, which often queue to a day or so of builds. Making contributors wait this long before receiving feedback is turning out to be rather problematic.

See Planning.

Is there someone working on this feature?

I'm going to roll this forward into T13069, which discusses remaining work for "mail stamps".

No.

@epriestley Are there any more concrete plans for this "nonblocking" builds? That is something we would like to utilise for one of our projects. Actually quite important as waiting for builds there is slowing us down quite a bit now.

Thank you. Will update the WMF task with this information.

The tools to perform this export are available in that project already. We don't plan to run the tools for you, since this just makes the workflow more complicated: you already have access to the tools you need to do this yourself.

(Another possibility is to add behavior to arc to control this.)

Maybe. Another possibility is to mark builds as "nonblocking" in some sense. There are some other open requests for defining "advisory" or "noncritical" builds where build failure doesn't cause the Buildable to report a failed result overall. If we end up adding this state to builds anyway, it probably makes sense to include a "Does Not Block Review" flag to the "Does Not Fail Buildable" / "Does Not Block Dependent Builds" / "Failure Is Totally Meaningless" / Whatever flags.

The harbormaster builds that we have running on revision creation can sometimes be rather slow; they're builds in our primary CI system, but with less of a priority than jobs in the submit queue. This will result in 10-30 minute delays for every revision in our monorepo. I understand the preference for only adding configuration settings when absolutely necessary, but since this may result in a significant time sink for any installs with expensive builds, is it worth keeping something around like differential.initial-state?

From T10109, we shouldn't make revisions "Buildable" to Herald if the update is an automatic update in response to a commit being discovered.

After all that stuff:

This is technically accurate but real awkward for humans:

A very rough version of this is now in master, but only active if phabricator.show-prototypes is on. These are some of the (substantial) remaining issues I'm aware of, and there are probably others:

An unusual case here is Herald rules which take the "Send me an email" action, and act "only the first time". Their current behavior will be to activate when the draft is created, have their mail killed later in the pipeline when the Editor declines to generate any, and then never fire again.

I've landed the two scary migration changes (D18418, D18419) and deployed them here without any obvious issues arising. The actual effects here are: