@epriestley Forgive me if you already got a notification about this, but I don't see your name as a subscriber so I wasn't sure if you would see it or not.

@epriestley, would you mind taking a look at this diff?

I just did a fresh install of Phabricator with only Slack OAuth enabled (no password login) and I'm running in to this, it says "Refused to load <url> because it does not appear in the form-action directive of the Content Security Policy." in the console when clicking the Log In or Register button to log in. Interestingly it didn't seem to have trouble registering for an account, but refuses to log in. Same issue on Chrome and in Safari. Restarted apache which didn't seem to make a difference.

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:

Maybe add some comments?

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

In D19740#244818, @joshuaspence wrote:

I think maybe we should keep it as an empty n_CLASS_ATTRIBUTES in case attributes are added later.

I think maybe we should keep it as an empty n_CLASS_ATTRIBUTES in case attributes are added later.

Automated landing didn't work so I'll do it the old-fashioned way.

• When the user specifies a bad "--class" like "--class xyz", suggest only engines which support export instead of all engines.

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.

(I'm also going to pick this to arcanist/wilds, but may stop picking everything individually in favor of some future "all remaining changes" change at some date in the future depending on how things go.)

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.