This currently appears to be mooted by T13188.

I think you can cherry-pick those changes safely. I suspect further changes connected to T13211 and/or T10884 in the near future are likely to be difficult to cherry-pick, though, so ideally you should try to upgrade.

To pull the list down (this takes a while since we can only grab 100 results at a time and the API takes a while to respond):

See PHI926, where a GSuite-backed install has seen multiple "550 No Such User" bounces to the same address even though the address exists. It's currently unclear if this is an issue in Mailgun, GSuite, the series of tubes between the two, or elsewhere.

@epriestley : our current phabricator version is c46be2a70b4db72d61e76690ef095384de2c3f91 that was landed on 04/13, will there be any issues if we directly cherry pick the recent two versions without pulling any other changes?
rP51073b972ece: Try to route cluster writes to nodes which won't need to synchronize first.Wed, Oct 17, 3:08 PM
rPbc6c8c0e93a7: Explicitly shuffle nodes before selecting one for cluster sync.

One idea here: T12961 and T13012 are security issues related to the misuse of -- in argument lists. I think there was one more (less severe issue?) with Git elsewhere, too.

This is entirely reasonable, the only reason it doesn't already exist is that the lease owner may be any of several different types of objects (I think: user, repository, another Drydock object, maybe null?) and we don't have a convenient UI datasource for letting users type to select any one of these various object types.

¯\_(ツ)_/¯

I think that workflow is pretty strongly undesirable: it suggests users make an incorrect change (e.g., suggest a patch which violates the style guideline) and they're expected to answer "Y" to it.

One additional perspective on this:

See-Also: https://circleci.com/ideas/?idea=CCI-I-430
See-Also: https://discuss.circleci.com/t/webhook-support-removed-from-documentation-still-supported/19984

I think this is all done but want to let things run against bastion007 for a bit before I tear down bastion005.

I also needed to copy the old master.key from bastion005 to bastion007 in /core/lib/keystore/.

I turned bastion.phacility.net and bastion-external.phacillity.net into CNAME records and pointed them at the new bastions.

There's a minor deadlock on bastion deployment with the current scripts: during deploy, we run deploy-key to copy the deploy key from the bastion to the target host during deployment, so that we don't need to put the entire keystore on normal cluster nodes, and so that we don't need to have the keystore on the control host (staff laptop) outside the cluster.

https://discourse.phabricator-community.org/t/differential-ui-tooltip-flicks-on-hover/1970 has some css witchcraft to make this not happen.

I cycled all the hosts except bastion. saux001 needs to be vetted a bit (it handles "Land Revision" from the web UI) but it isn't critical if it needs a bit more work.

I 'm going to get these underway once the deploy finishes.

For now, I just hard-wiped the cache and regenerated the documentation again. ¯\_(ツ)_/¯

The file cache says that these files have already been parsed and contain no atoms, so the rest of the program behavior is expected after that. I'm not sure how this state came to exist.

• DivinerPublisher->publishAtoms() is being passed nothing, so it's correctly deleting everything.
• The graph cache is empty.
• The actual atom.cache file on disk is empty.
• The input to the cache is empty.
• The files aren't being passed to the atomizer rules (although the rules appear to be applying correctly).

So, so far it looks like the database is in a "good" state but the publish workflow incorrectly deleted all the articles. From previous efforts, I believe dropping the cache fixes this issue.

But note that the graphHash and nodeHash columns are 0, which I believe is a signal that these nodes have been deleted (I haven't touched this code in a while).

Oh, the contrib stuff got separated into a different book and has fully unpublished:

The "Contributor Introduction" document, specifically, seems to have unpublished. Let me see what I can dig up about the current database state.

"Yes", but post- T13098.

@epriestley, would you be open to making the chunk size configurable? Changing the chunk size from 32 to 512 reduced the amount of time required for us to lint ~1500 TypeScript files from 370 seconds to 66 seconds.

In retrospect, I should have rigged the hash for the the "Remove libphutil" commit to have some cool recognizable prefix like de1e7ed, since half of arcanist/ now ends up there on git blame.

Also, guess what this checkbox does on Windows 10?

Consider this script:

This was almost certainly resolved by D16273.