Change Details

Long ago, Herald had some inconsistent behaviors: - For commits, it triggered (at most) once when the commit was discovered. - For revisions, it triggered when the revision was updated. - For other objects, it triggered on every update. We've removed the inconsistency in revision behavior and Differential now triggers on every update. Commits should probably also trigger on every update, so you can write rules like `[ Project tags ][ include ][ xyz ]` and get an action if someone //later// adds that tag to a commit. However, if we just ship this, existing rules like "Run Build Plan" will start firing on every comment. We also would probably need a "commit is published" condition. This is pretty much the same as T13041 so maybe we could just reuse that? This is easy, but disruptive, and seems generally very low-priority since it primarily serves the idol of consistency today rather than any actual use cases.

Long ago, Herald had some inconsistent behaviors: - For commits, it triggered (at most) once when the commit was discovered. - For revisions, it triggered when the revision was updated. - For other objects, it triggered on every update. We've removed the inconsistency in revision behavior and Differential now triggers on every update. Commits should probably also trigger on every update, so you can write rules like `[ Project tags ][ include ][ xyz ]` and get an action if someone //later// adds that tag to a commit. However, if we just ship this, existing rules like "Run Build Plan" will start firing on every comment. We also would probably need a "commit is published" condition. This is pretty much the same as T13041 so maybe we could just reuse that? This is easy, but disruptive, and seems generally very low-priority since it primarily serves the idol of consistency today rather than any actual use cases. --- Related, see PHI1264. If users interact with an unpublished commit after it has imported, it currently does not send email/notifications/etc. This is incorrect: explicit user interaction with unpublished commits should work normally.

Long ago, Herald had some inconsistent behaviors: - For commits, it triggered (at most) once when the commit was discovered. - For revisions, it triggered when the revision was updated. - For other objects, it triggered on every update. We've removed the inconsistency in revision behavior and Differential now triggers on every update. Commits should probably also trigger on every update, so you can write rules like `[ Project tags ][ include ][ xyz ]` and get an action if someone //later// adds that tag to a commit. However, if we just ship this, existing rules like "Run Build Plan" will start firing on every comment. We also would probably need a "commit is published" condition. This is pretty much the same as T13041 so maybe we could just reuse that? This is easy, but disruptive, and seems generally very low-priority since it primarily serves the idol of consistency today rather than any actual use cases. --- Related, see PHI1264. If users interact with an unpublished commit after it has imported, it currently does not send email/notifications/etc. This is incorrect: explicit user interaction with unpublished commits should work normally.