Haven't seen any more issues since rolling the server; I'll keep my eyes peeled.

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

We haven't seen any other users find this confusing.

As a general note, Azure appears to have both SAML and OAuth flavors. D10297 / D10289 implement the OAuth flavors, and don't invoke the messy SAML problem. I'm not sure if these providers are equivalent or not.

Current state of the world is:

I think we can do this gradually by:

(This is likely an example of the issue.)

Oh, this was already fixed at HEAD (rP06aa3a0a1b). I pushed this server, should be good now.

Thanks, I'll look into this.

Just wanted to clarify as I'm not entirely sure that I understand... So we currently have a puppet role named phabricator_worker which runs phd daemons. As a step in our puppet scripts, we basically run /usr/src/phabricator/bin/almanac register --device=worker.phabricator.example.com --private-key=/path/to/private.key.

This code looks good to me in a technical sense, we just don't want to take over maintaining it. Two minor suggestions:

Per T9827, I currently believe this would be used by only one install and don't want to bring it upstream without seeing much broader interest first.

We haven't seen other requests in this vein from other users, and are not aware of a more general interest in using JSON bindings to write linters. From your problem description, it sounds like you have a fairly unusual and specific need within your project. We haven't seen other projects report similar needs, and I think this is isn't a good candidate for bringing upstream: we don't want to upstream code which will only be used by one install, and I have no reason to believe that these bindings will see wider use.

This probably requires $types[] = PhabricatorTransactions::TYPE_EDGE; in PonderAnswerEditor->getTransactionTypes(). It would be vaguely nice to do this more automatically/consistently, but probably not worth pursuing some grander approach at this time. T9789 is probably on the horizon and represents a better opportunity.

This obscurity is currently intentional, for policy/security reasons. I don't want to leak anything sensitive into the relatively-accessible web UI.

See Contributing Feature Requests. Please describe the specific, concrete problem you're encountering.

Fixed by D14527.

To move forward, we should split this into two tasks:

These cases aren't closely related.

See Contributing Code.

In T9784#145136, @andrask wrote:

@joshuaspence what do you think about this issue?

("No time specified" in Phame is a bit odd too, but I think that's been fixed already)

Why can't your publish step just check if the commit is on master (or even if it's HEAD of master) and no-op if it isn't?

I'm assuming that @terrismotox is just playing around.

There was a minor config issue with db005 but I sorted that out; no users were affected.

The 005 nodes are in production. I'm not going to bother with web002 for now but I'll probably do the other half of that the next time I do ops stuff.

This message no longer exists at HEAD. Upgrade Phabricator.

Awesome, thanks for the report!

I've brought up the 005 nodes. I also brought up web002 while I was in there, although we don't appear to be near capacity on web001 yet.

That's the patch from earlier, yell if you spot any issues with it.

Deeply tragic.

@mbishopim3, yeah, looks like you're lucky winner #2 on this. Your workaround (creating the database) was correct.

I'm going to repurpose this as "get that data in the database so we're better prepared if this happens again", but feel free to follow up if you go on a hunting expedition or hit the issue in the meantime.

My specific plan here is:

If we do this, one has to be designated "primary" (like Projects) so we can get a consistent default /u/xyz when rendering. This broadly seems like a lot of work for not a lot of payoff, to me, at least today.

It sounds like this use case (using Harbormaster to build a GitHub project, and not using Differential) is far afield from the use cases I consider core. There are a large number of existing tools (Travis, CircleCI) which are purpose-built to address this use case.

You can manually update phabricator_user.user_externalaccount to change the external account ID reference.

For what it's worth, we have a very similar setup (40ish repositories in Phabricator, all hosted in Gitlab). We have not observed any performance issues such as those described in this ticket.

Since we don't have access to whatever GitLab is measuring, we can't understand this issue in greater detail. Particularly, we can not reproduce the underlying heavy load in a way we can examine. We have not seen similar reports from other users, except @jcarrillo7, who has not filed any details. We have many installs with hundreds of repositories and my expectation is that the operation is cheap, so I suspect this may be an issue unique to GitLab.

My next step would be to put more crumbs in the UI, but we're missing a little data right now. Basically, I'd do this:

huge amount of traffic