This is now fully configured.

I ultimately don't think there's any really reasonable way we can fix this that doesn't have a cost and complexity far greater than the benefit.

This has been live for some time without any apparent issues.

We haven't seen further reports of this in more than two months, so I don't plan to mitigate it at the application level.

Presuming resolved by getPathChangedLines($path) + -lines.

This request doesn't describe a root problem, so we can't develop a solution to it. We haven't received any new information in more than a month. See Describing Root Problems and Contributing Feature Requests for help describing root problems and filing feature requests that the usptream can accept.

We can't reproduce this and we haven't learned any new information in more than a month, so I'm going to close it.

This report does not include reproduction steps. Bug reports must include complete, self-contained reproduction steps to be accepted by the upstream. See Providing Reproduction Steps for help.

I'm going to merge this into T10563 which is narrower but more actionable.

We don't have enough information about this problem to design a solution, and haven't received more information in more than a month. See Describing Root Problems and Contributing Feature Requests for details on how to submit an actionable feature request.

Take a look at this and see how far you can get? It might be really easy but it might also be very involved.

It's currently impossible to sort badges by rarity because they rarities are internally 'grey', 'white', 'green', etc., and there is no natural order to these. For example, MySQL has no idea what order 'indigo', 'orange' and 'yellow' should go in, except alphabetical, which is not actually the correct order.

Sounds good, let us know if you run into anything else.

For completeness, T10651 is the earlier report.

I think this should now be resolved in HEAD of master. It will likely promote to stable in about 24 hours.

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.