Page MenuHomePhabricator
Create Task
Maniphest T11407

Make is possible to react to commits being parsed
Closed, ResolvedPublic
Actions

Description

Differential's custom fields and the owners custom field enjoy first class support, explicitly copying their properties to a commit after a revision is landed. Currently, if you have your own custom fields which you associate with revisions, and you would also like those fields to be later associated with commits, you have to jump through many, many strange hoops, or just resort to polling.

It would be nice if it were possible to associate things with a commit after it has been parsed/published/populated.

Concrete use case:

  • We have a custom field defined which associates a maniphest task with a revision and acts as an "ok someone in the field tested this" piece of data which we can all easily see on the revision
  • Once the revision lands, we want that same task to be explicitly called out as associated with the commit and searchable / filterable, so proxying through the revision won't work

I managed to get that working anyways, but it was not fun, and required polling.

Related Objects

Event Timeline

yelirekim created this task.Jul 31 2016, 9:53 PM
epriestley added a subscriber: epriestley.Jul 31 2016, 10:14 PM

I'd like to make the Diffusion UI more field-focused (T9713). which is maybe adjacent, although not directly related.

You can likely do this today by writing a custom Herald action and then running it with an "Always" condition -- that's after it has been parsed/populated, although before it is published. It seems like pre-publish is OK for this use case, though? This isn't perfect but doesn't require polling, at least.

chad added projects: Diffusion, Herald.Aug 2 2016, 4:49 PM
Herald added a subscriber: eadler. · View Herald TranscriptAug 2 2016, 4:49 PM
epriestley closed this task as Resolved.Aug 10 2016, 9:06 PM
epriestley claimed this task.

You could also do this with no custom code by using Herald to trigger a Harbormaster build and having that make an HTTP request to something which runs the logic, or theoretically by using feed.http-hooks or Doorkeeper (although these are probably better after T10363).

I could also maybe imagine supporting some kind of autorun Herald action which implicitly behaves like it has an "Always" global rule written for it, but I don't like that this would require a lot of Herald code to potentially test if it was running inside a "real" rule or not. The cost of writing an "Always run all the hooks I want" rule seems small, and it means they're easy to disable or make conditional, they show up in transcripts, etc.

Anyway, presuming one of these is better than polling, maybe? Or let me know if this is all still bad.

Phabricator · Built by Phacility