To those still interested, Spinnaker (OSS from Netflix + Google) is targeting the Deployment part of this flow (everything after a Release Candidate is created).
It only handled "cloud" deployments, and offers as much complexity as you can ever want, including "Wait for human approval", Canary deployments, blue-green, etc.

Please use the Discourse forum for this kind of discussion.

Gentle ping here again :) Has anyone managed to get a webhook triggered on a phabricator git repo, once-per-push, not once-per-each-commit ?

(This seems stable now, and there's no specific action here.)

PHI1159 would like build failures exposed to Herald to trigger audits. See also PHI953. See also PHI901.

In PHI1008, when commit X reverts commit Y, we don't write a revert edge between X and revisions associated with Y. We should.

Argh, big thanks. Indeed that was not obvious at all to me.

Leaving the "Assign To: [...]" field blank will remove assignees, but this is not obvious:

I believe there is very little reason for the "Autoclose" and "Publish" behaviors to actually be separate. That is, there are very few use cases where users want a commit to trigger only Herald or only feed or only audits. These use cases do exist (see T9210 for an example of "Herald, No Feed") but they're overwhelmingly niche and off-label.

In T6722#197239, @avivey wrote:

I think a more powerful approach is to support some kind of "templates", so that we can create a new "Android App" repo or "COM Module" repo directly, similar to how IDEs have project templates.

This could be made slightly cleaner with a setSummary() to set a shorter summary:

The git fetch change in D20421 does actually affect non-bare repositories:

This is expected: the revision is not newly created.

This is expected: the revision is not newly created.

hmmmmmm

APIs: Currently, diffusion.repository.search does not expose staging information.

With changes in T13277, I think we're ready to start making ref staging the default behavior in hosted repositories even without T8093 (which will give us some tools to improve things later, but seems like it's generally in good shape).

When there are no refs in a repository, the server does not appear to send a capabilities frame:

Empirically, on modern git:

This is a duplicate of T8936 and resolved by D20420.

D20433 deprecates "Track Only", mooting this.

After D20420, we accept these refs.

D20420 accepts these refs. We don't show notes in the UI, but we have no outstanding customer requests for this.

See T13277. I'm moving us away from "Track Only", and our behavior is already reasonable under "Fetch Rules" + "Permanent Refs".