We're kinda-sort doing builds for commits now:

I'm going to close this out since I think everything here is now reasonably represented elsewhere:

Here's a similar failure case:

It's possible, but I'd guess they're probably not related if I had to.

D14189 should fix the button.

Oh, never mind -- pretty sure I figured it out.

I'm not immediately able to reproduce that status icon issue, what does the icon say when you hover over it?

For the first half of this, see T9430 / D14013 / T9372.

After D14187, we will continue evaluation if you enter no text (i.e., just hit enter at the prompt).

Also note that remarkup has a parser cache, so older mentions won't automatically be fixed right away (the bad parse is cached).

I think D14186 will fix this. Let me know if you catch anything else wonky after that lands -- I got some indirect test coverage on this, but might need to go beef things up a bit if I missed something.

Ah, I think that's parsing as K4 (Passphrase Credential #4) plus some other stuff. We allow hyphens after an object reference (like "T9479-should be fixed ASAP").

Oh, it may be a little more involved than that. I think the user in the original report (C933103) is conflicting with the Countdown rule.

I think the actual rule is "if a username is at least 8 characters long and contains only [a-fA-F0-9]".

We technically have builds now:

What response are you expecting? The method returns void (meaning "no data") and that's a "success" response (no error occurred).

Quick progress update here: Owners packages now have configurable custom fields, so you can add one like this:

Resources still do not have expiration behaviors.

One idea is that we could let you designate peers (either explicitly, or implicitly by sharing administrative control with them? -- but probably explicitly) who are permitted to strip your MFA tokens.

There's no way to do this. It would allow anyone with commit access to XSS other users and take over their accounts.

Pretty sure this was only possible after the introduction of .arclint.

T7248 was a case of a user with neither the mysql nor mysqli extensions installed.

We don't plan to accommodate this particular workflow in the upstream, per se. Beyond @chad's links, see also T1508.

If users have MFA configured, I think it's important that we not let an attacker avoid MFA checks on operations (including adding SSH keys) by using Conduit. So if we had a method for adding SSH keys we'd either have to deactivate it when we hit an MFA block, or implement CLI MFA somehow (seems tricky/complex?) or have it add a "request" and then require the user to confirm that they want to add the key via MFA from the web UI after passing MFA, maybe (this feels bad to me for a bunch of reasons, though).

It would be easier to implement this if we say the second form is required (enter JSON -> parse JSON -> interpolate the variable in stirings), but I think it's not intuitive that you can't just type {$me.phid} into a field like authorPHID. Certainly, I'd expect that if the console supported variables they'd be proper-value-variables, not string-interpolation-variables, since string interpolation is completely useless except that it's easier to implement.

I can't remember off the top of my head, but I thought we had a way to pass flags to external linters. Something like this:

In T8975#138256, @epriestley wrote:

We haven't seen other requests for this and I don't think it's very straightforward. Consider these JSON values:

[{$me.phid}]
["{$me.phid}"]

The former value is not valid JSON though?

Aha, so the users are also different, and they're real users (not bots)?

I don't understand this use case. Why do you have unique keys per-VM?

Pretty sure this was fixed during T2769. I can't reproduce it at HEAD:

D14173 explains upstream attitudes toward exit codes in greater detail.

All result pages have a "Hide Query" button now, I think since the last redesign.

I'm just going to close this, I think T1460 has similar discussion already.

We haven't seen reports about this from other installs or experienced it ourselves, and we've run an instanced production cluster with a mixture of workloads for more than 6 months now. All the daemon stuff has also changed a lot over the course of the last two years since this was originally reported.

T8818 was a specific example of a user hitting open_basedir issues.

I think this is a duplicate of T9260, and was likely resolved by D14169.

bin/files compact shouldn't normally do much of anything; the better fix might be to identify what's causing these files to be written despite being compactable and stop it from doing that. My expectation is that all file writing callsites should automatically reuse storage if possible in modern code.

Never mind, there's already such a note.

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

From discussion on IRC, I think this was a UI issue (these parsers do not block the queue, it just isn't clear that "Leased" includes tasks being actively worked on and tasks waiting on lease expiry), not a queue issue? We can improve this UI but I'm probably not going to touch it until I can collect some more stuff there (cf T7307).

We haven't seen other requests for this and I don't think it's very straightforward. Consider these JSON values:

Oh, I didn't look at the stack trace carefully when dealing with T9458. I think the fix for that (D14142) almost certainly resolved this, too.

I think this isn't our responsibility.

I think the way forward here is likely:

We've removed the dot rules from the upstream for security reasons (see T9408) so this is no longer relevant, although it is a concern we might want to address in T4190.

There's some relevant information on the progress on the Drydock side of this here: T9252#138215

These things are now complete:

API keys are now all cycled (except ReCAPTCHA, which doesn't seem to be cyclable and is a ~zero-value target anyway) and everything seems to have swapped over cleanly.

(Testing inbound mail...)

(Testing S3 / SES keys on this host...)

Oh, I guess there isn't actually a "test plan" Herald field. We could add one easily enough. I was thinking:

Either Phabricator should allow pulling from Inactive repositories (I see no reason to prevent pulls, but preventing pushes is probably reasonable),

In T9331#138095, @epriestley wrote:

Workarounds like the one above (or just writing similar Herald rules) seem reasonable to me, if not ideal.