I don't believe there are remaining outstanding requests for this.

Owners review and auditing now have 6 and 4 options respectively, which I think cover most of the needs here. They don't handle everything (e.g. excluding merge commits) but think we're mostly in a reasonable place now and don't have any current plans to add additional shorthands.

I think a possible model for the UI is to have some base ChartConfigurationEngine, similar to SearchEngine, which defines a set of fields. Some fields would be common (e.g., all time-series charts can have time controls for domains).

The concrete use cases that are currently filed are:

This is approximately coming into existence and this task no longer serves much of a purpose. See T13083 / T13279 for followups.

This now approximately exists and is no longer of much use as a standalone task. See T13279 and elsewhere for followups.

hmmm

Wow thank you for this. I came across a diff that mixed a lot of whitespace with minimal code change it's much easier to differentiate what happened.

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.

I believe this was resolved by D20327 / D20393.

I believe this has been fixed by D20327 / D20393 -- at least, the examples above no longer seem to reproduce any bad behavior.

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