Effectively, I think this is a variant of T9067. I'm going to patch this narrowly since it's straightforward.

Actually, I'm less sure that this is credential-related.

There's a specific issue with a subset of commit-related mail not using the right credentials to hit the API locally. Here's a characteristic trace:

Looking into this now, this is likely related to key cycling (see T7399 for details). I suspect something is just out of sync or needs to be restarted, let me figure out what's up.

General plans here:

• rCORE no longer contains any live SSH key material (nor are any keys in the repository history live).

This part seems to have gone cleanly:

I think all the pushing is complete now. Ran into two issues:

I'm resuming work here. Next steps are:

Does this reproduce at HEAD, after T9455?

Generally, for any system where you control the action of the remote end of it and can trigger builds, you can write a build process today like:

I'm going to merge this into T7869 since that has a more complete view of things and our Jenkins plan looks like it's shaping up to pretty much be "tell people to use @sectioneight's plugin", give or take.

I'm just going to merge this into T9456 since I think that's a more complete view of things now. Short version is that my current plan is:

Although we still have a long way to go here, after D14136 the result of the sequence of steps above is a little better:

D14137 (with the new prompt) is now in master. It will promote to stable in about a week. You can grab it with arc upgrade.

Please describe the root problem you are facing when filing feature requests, not just your desired solution:

D14137 replaces the prompt with this one:

Actually it looks like these states aren't distinguishable from git diff --raw:

Our behavior here is strictly wrong. We ask you a question:

Ah, okay, so the missing steps are something like this:

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

I've pushed some non-production and semi-production services (aux, sbuild, bastion, admin) but sorting out deployment keys took a little longer than I anticipated (I don't want to put the general cluster deployment key on the sbuild tier at all) and we're edging into normal working hours for a larger portion of Phacility users so I'm going to hold off on more service cycling until tomorrow.

Cool. Let us know if you run into anything else.

There's no easy way to browse configuration without being an administrator because some configuration may be vaguely sensitive, and some of it depends on other configuration or module availability so we don't (and, broadly, can't, at least in its current form) export it as flat documentation in a text file or HTML or whatever.

My guess is that differential.allow-reopen is set to false (the default value), which disables the "Reopen" action. If you (or an administrator) change this setting to true in the Config application that should enable the action.

When you scroll to the bottom of a revision page (the URL should look like /D123), you should see something like this:

• I've generated new keys (rKEYSTORE851c37c6).
• I've added the public keys to the relevant users/devices.
• I've realigned rCORE to always read keys from conf/keystore/ and am now going to start cycling services. If I got things right, they'll transparently pick up the new keys.

I am fully separating these credentials now in preparation for deploying sbuild with rCORE. Specifically:

Ah, I think you're right. I thought that cow just had a nice thick neck (a sign of good breeding), but her tail is a little bristly.

Yeah, I think it's very unlikely that we'll require hovering to reveal document hierarchy (or, eventually, parent projects) since two results called "Onboarding" (or, in the future, "Sprint 32") are completely indistinguishable right now. This use case feels much stronger to me as a material usability issue than snippeting.

(Had those task numbers swapped on my clipboard, fixed.)

I'm going to merge this into T8646, which has some discussion about improving the amount of context available in search results, particularly for Phriction results. See also T9416 for a similar request to this one with some discussion.

Yes. This project does not use Composer. See T6012. See also T5055.

It worked!

Yeah, that makes sense. I think this is straightforward and won't create a big ball of mess or anything, so I'll see if I can slip it in somewhere.

Does restarting apache (or php-fpm, if using php-fpm) fix this?

This tier now exists and rCORE knows how to deploy hosts inside it.

The upstream will not help you resolve issues with third-party extensions (see T5447). You need to report these issues to the extension maintainer, not here in the upstream.

This is now up, and rCORE knows how to deploy instances in this tier.