I think that stuff isn't linking because someone is pushing their own branches to the upstream staging repository, making the commits ambiguous. That is, e3f89279f912 is ambiguous as either rPe3f89279f912 or rSTAGINGe3f89279f912.

Ah, thanks! To hit this, I think we need to push a mixture of changes:

The only way I can see to get to an error state is if both branches had the same head before the push? I'm not sure how to build that state, although maybe I'm just missing some subtlety of hg branch or some sequence of merge/close operations which can force it.

Using mercurial push a set of commits that updates multiple branches at the same time

This report does not include valid reproduction instructions. These instructions are required; see Providing Reproduction Steps for help.

I can't reproduce this. Here's what I did:

c( ⁰ 〰 ⁰ )੭

I requested SES limits of about 2X what we currently need and AWS gave us about 10X, so things look good so far on that front.

I did a chunk of this work as part of T10629 and we're in better shape on accepting SSL-terminated traffic now.

I've probably updated the notification server certificate, too?

T10659 discusses another complex custom rule for mapping branch names to tasks in an unusual way.

CDN stuff is maybe-sorted.

Something on the CDN side has grown deeply unhappy, looking into it.

Seems OK. Swapping DNS shortly.

This appears to have deployed cleanly. I'm going to test notifications and SSH, and then I'll rebind DNS if they look good.

I'm going to deploy this host with rSERVICES + cluster awareness so it can accept SSL-terminated traffic. If I got something wrong, we may be down for a few minutes.

This is a little bit tricky because notifications use the same hostname, we don't have a wildcard certificate, and we can't (apparently) terminate SSL on the load balancer and pass it through with websockets.

The upstream provider gave me a not-quite-English canned response:

I've issued all instances a 24-hour credit for the service disruption. This will be reflected on the next invoice you receive.

Our original upstream provider enabled the account again, also without explanation. Outbound queues are flushing now, but will take some time to completely de-queue because of backoff behavior in the queue.

T9704 also discusses slowness on inserting the tests. That may be unnecessarily slow right now, but I don't expect clients to submit unlimited numbers of tests in one API call. Instead, submit tests in chunks (say, of 1K tests per page or whatever) by calling harbormaster.sendmessage repeatedly with a work status.

We don't currently have a sortable column on the unit message table, since pass, fail, etc., aren't naturally sortable by any key MySQL can construct.

This is probably not a true race in the strict technical sense, I suspect you can reproduce it by doing one of these at walking speed:

I think it's very unlikely that we'll ever write some kind of script to just fix this stuff. I suspect such a script is impossible to write (i.e., the "correct" value for most fields is ambiguous) and that maintaining it is very difficult.

I don't particularly love ASIDE as the trigger, maybe MEMO is a little better? But it doesn't really capture the intent particularly well, I think.

I think this option would very rarely see use, and @avivey's suggestion (arc browse D1234 + use web UI) is a pretty good workaround.

T7789 has some discussion, but there's now a clear pathway forward here which doesn't require anything too drastic. Specifically:

I added you to Community so you should have task edit powers now.

Whoops, thanks. This got rebased across 200 years of changes and I didn't re-test creating a credential. D15512 should fix it.

"Is merge commit" detects this.

See T5726, T10363.

just convinced that Phab search didn't work and feeling powerless over it

See also T4103.

CircleCI fixed build_parameters in their API so support is now in HEAD of master. There's probably some remaining work but it seems to work properly locally. Let us know if you run into issues with it.

Sounds like this is resolved one way or the other. In the general case, "Another Herald rule" effectively allows you to group, negate, and combine conditions in addition to reusing/including them.

You can use two rules:

This should be fixed in HEAD of master. Let us know if you're still seeing issues after updating. Thanks for the report!

I think this should be fixed in HEAD, let us know if you're still seeing it after updating. Thanks for the report!

This is already documented, do you have any suggestions for improving the existing documentation?

Yeah, I think changing text size inline often tends to look pretty bad since line heights get all messed up, too.

Note that you can do this today:

We're planning to do this at some point:

Do you have some examples of things you'd like to use this for?

Yeah -- it's not very clear on its own, but this comment is specifically referring to that issue:

Closing this in favor of followups.

We are vanishingly unlikely to pursue this naturally. It is very complex and we do not consider it valuable. We have never seen similar requests from other installs, and this UI seems far worse for most users because it makes discovery difficult.

We can resolve this by parsing the query and rewriting the query we submit to the engine as "+x +y" if ft_boolean_syntax has not been adjusted.