Currently we have over 1500 active herald rules. Over 1000 of them are global.
Some rules triggers builds on Jenkins. Some rules assigns responsible persons/ccs/projects for tasks. Most rules are global and we allow our users modify them.

ApplicationEditor (T9132) and Nuance (T8783) are both scheduled for implementation before the end of the year and might offer alternatives here, too. With ApplicationEditor you could create 500 "create task" forms (instead of 500 teams) and have each form prepopulate with appropriate assignees, subscribers, projects, etc. With Nuance, you could create 500 queues (instead of 500 teams) and give each queue custom routing rules (and potentially have them just create tasks directly and not actually use Nuance).

One note is that the transcript cost only includes the cost to evaluate the rules, not the cost to load the rules. The intent of the field was to catch rules which were unusually expensive to evaluate, but in the case of a large number of very simple rules, I would expect that the cost to load and build objects for rules would dominate the cost to evaluate them.

In many cases, we must run Herald rules synchronously in the same process performing a write which triggers the rules. In some cases, this is strictly required: for example, when you push a commit, we clearly must evaluate at least some rules before we accept it, because a rule may say "don't accept this commit". If a rule may cause a "don't accept this commit" effect, we obviously must evaluate it before we accept the commit.

@chad ^^

good point. Unfortunately, the mailing list is already set up and migrating that might be more effort than needed (there are all the existing links; subscribers; guidelines etc).

Would this work?

Sorry, that was badly phrased. My apologies.

In T9582#140572, @devd wrote:

this works. The only problem is that every response will create a new task. I can hack around it, I think, but was wondering if there was a way to tell Phabricator to not create a task in those cases.

this works. The only problem is that every response will create a new task. I can hack around it, I think, but was wondering if there was a way to tell Phabricator to not create a task in those cases.

ohh cool! yeah .. let me try this out. thanks @chad

Currently we have over 1500 active herald rules. Over 1000 of them are global.

Can you give some better insight on how you use Herald? I'd like to understand the core problem (hard to find rule X) vs. just randomly adding features that might not solve the problem.

@joshuaspence the issue for me is that the commits made to fix the failed audit naturally do not occur until after the audit has failed, and so can't be in the same commit.

Yeah I don't know why you would want to duplicate Audit details to Maniphest. Do these commits have a single merge commit which could be audited instead?

Yes, T4026 would be perfect.

I think you can write a custom HeraldAdapter to do what you want in the meantime, trying to see if we've documented that somewhere yet.

It sounds like you want T4026 then?

@chad the issue is that subsequent commits (made to fix concerns raised) are not easily linked to the commit that raised concerns and are harder for auditors to view in context with the commit they had originally audited.

@nick.udell I'm still not really understanding the problem. It sounds like you're just copying information from Audit to Maniphest but I don't see what problem duplicating the information solves. If I have a commit with a Raised Concern, it's on my dashboard to address and I have all pertinent information to assign a new review to resolve the issue.

Please check out our guide on requesting features in Phabricator. Specifically, it's helpful for us to understand what problem you are having with Phabricator and then we can look at various solutions. Right now I don't have any clear idea on what problem duplicating Audit into Maniphest could solve.

Yeah, at least as written. You could tweak the logic or I can swap it for something else if that's easier.

@epriestley thank you so much!

• We now accept any 2xx status as success.
• For (1) and (2) above, there is currently no support in the upstream, but builds can be parameterized after D14222. See T9352 for discussion and an example of how to write a custom Herald action which does this.

The way to do multiple builds per package is to use a remarkup custom field and separate them with newlines, correct?

• The way to do multiple builds per package is to use a remarkup custom field and separate them with newlines, correct?
• The herald rule should be "Always" instead of something to do with packages because CustomDifferentialRunPackageBuildsHeraldAction has sufficient logic of it's own?

After D14222, the updated P1860 should pass parameters properly. Here's a target getting a build parameter:

As of now, I'm hacking around this by having a flask app that listens to harbormaster calls and in turn calls jenkins before returning 200 to harbormaster.

My plan is to allow parameterization at the build level; D13635 is an implementation of that but it has some other stuff mixed in and needs to be pulled apart a bit. I think this change is straightforward overall, though.

Aren't 2xx statuses considered "success" in HTTP protocol, despite values of "xx"?

It seems the change from setting the result to FAIL to throwing an exception in the case where the server does not return 200 is skipping some code after the call that was overriding the result to WAITING in the case where a build was set to wait for result. Probably this was a bug in the case where the result was already set to fail.

Although the return code check against exactly 200 has always been there, integration with jenkins was working as expected before rPd735c7adf2d5897d3ae08f3aba12774030c0d3b1

@epriestley Any jenkins job that has to be built with parameters returns a 201 created, https://issues.jenkins-ci.org/browse/JENKINS-22849
it is turning out to be difficult to make it return 200 to a client even with a reverse proxy in front. Just wanted to know if you'd like to reconsider the decision to support 2xx or at the least, 201?
I wonder how @sectioneight's plugin works around this.

ah, i see!
I got too excited and created D14200

The build step will probably let you configure that eventually, but I don't expect to change that any time in the near future.

@epriestley thanks of the immediate response, looks like jenkins is sending back a 201 Created. I can try to mask it as a 200 but do you think there is value in allowing 2xx status codes on harbormaster's side?

We fail if the server returns an HTTP status other than 200, exactly. Since it's returning a "Location" header, it's probably returning a 3xx status alongside it. The behavior you describe is consistent with the HTTP request returning a non-200 status.

@chad @epriestley got my setup working with sending messages about the builds via 'work' type result to harbormaster.sendmessage but still seeing the build's status as 'Failed' and the same log..
I'm not running any unit tests locally and no unit.engine is specified in my .arcconfig.. is that the reason?

@chad @epriestley So, before closing this task, I have a question about how exactly harbormaster listens for messages, I have a build plan that makes a post call to jenkins with some parameters, the response (in the message log) appears to be the head response from jenkins server

Server: nginx/1.2.4
2	Date: Wed, 30 Sep 2015 00:36:58 GMT
3	Content-Length: 0
4	Location: http://10.21.42.131/queue/item/72/
5	Connection: keep-alive
6	X-Content-Type-Options: nosniff
7	Set-Cookie: JSESSIONID.9a9706df=1s6zk8yhj6ggc1wtjv17yqmov0;Path=/;HttpOnly
8	Expires: Thu, 01 Jan 1970 00:00:00 GMT

@epriestley Ah, I see! I thought there was some error that's not being printed. I was expecting something like "message sent". Thanks for clearing that.

What response are you expecting? The method returns void (meaning "no data") and that's a "success" response (no error occurred).

@chad thanks for pointing, I just did, I've looked at the uber plugin before, but for our transition, I wanted to know if any of what I was asking above could be possible before we start entirely relying on that plugin. Also, have you seen that issue with harbormaster.sendmessage previously?

Have you read T9456

Quick progress update here: Owners packages now have configurable custom fields, so you can add one like this:

Pretty sure this was fixed during T2769. I can't reproduce it at HEAD:

I think this is a duplicate of T9260, and was likely resolved by D14169.

Oh, I didn't look at the stack trace carefully when dealing with T9458. I think the fix for that (D14142) almost certainly resolved this, too.

ehh

No clue how to repro. I'll accept a diff to get the rule ID/PHID into the error message if you want.

Sgtm

I'm don't see why the number-of-rules is relevant

I'm don't see why the number-of-rules is relevant

These aren't linked partially because in the general case, the policy model for Herald rules is a little murky:

Ah you are right. You can see the set of conditions that were checked for the rule.
In my particular case, I wanted to find the rule that was adding me as a subscriber and disable it.
I ended up typing "/herald/rule/(rulenumber)" into my URL bar to get to the page of the rule.

This has been live for about a month without any followup concerns.

Sounds like T1731

@cspeckmin
we don't use LDAP. we just have different account names
for example, my phabricator username is aelam which is based on github, and my company svn username is wanglun. I can't make the two usernames base on a same email address. And I don't know the way you said LDAP . so phabricator will trade me as two different people

The email itself is isolated to the one action: movement on a workboard. There is a second e-mail however which refers to the closure of a task. The two are effectively grouped together and happened quickly, but two separate emails were sent. The other email's headers:

It looks like some other activity also occurred in the same transaction set. Does the email reveal what it is? That is, do the first two lines look like this?

For example:

Can you show me the mail headers for the mail you received but did not expect to receive? In particular, the X-Phabricator-Mail-Tags header?