contentID on Document should probably not be nullable. We can generate a Document PHID first, save the Content with the right Document PHID, then save the Document with the content ID. Deleted/moved/stub documents still have Content, I'm pretty sure -- oh, except we can't do, this because Content uses documentID, not documentPHID. So maybe kick the can down the road.

Oh, and also to the original use case, I'll at least add some kind of warning for this since "silently skip some patches" isn't a good behavior. I'm open to adding some other hint mechanisms on top of this later so linters can better pick which patch wins, but would like to motivate it with some specific, surgical examples. The original example, where one linter removes debugging code and one linter reformats it, is a good starting point: in this case, "remove" should have greater strength than "reformat" and we'd prefer to discard the reformat patch and apply only the removal patch.

I'll plan to make these changes:

After D19615, callers to harbormaster.sendmessage can specify "format": "remarkup" to get "details" rendered as remarkup (including {Fxxx}) instead of plain text.

The unit test results also don't currently show on individual builds, which is a little whack?

See T13189#240682 for some planning on the Unit Test result table.

See PHI710. This is a request for richer lint/unit results. It's likely entangled with T13088 but can probably be planned.

(Feature request with no support mana.)

I expect to add flags like "this doesn't block undrafting" and "this build doesn't matter" soon, and then possibly refine those. I'd consider revisiting this after those deploy, but am not excited about formalizing the idea of "only some of your tests failed so it's okay" or adding a check for each build (since this won't scale very far). The tooltip is reasonable but I'll just turn that into a note on T13088.

(Feature request with no support mana and no discussion.)

Feature request with no support mana and no discussion / unique insight.

Nothing really actionable here.

This is reasonable to build eventually, but there's currently no support mana behind it and this task doesn't have any unique context or discussion.

No support mana behind this and no unique information in the task.

This isn't an actionable task so I'm banishing it to the shadow realm.

We don't have any support mana behind this request, it's a good candidate for third-party development, and there's no unique information in this task so I'm just going to close it out.

This doesn't have a repro and will probably be fixed via rewrite / modernization in T13077 anyway.

"Draft" will get a writeup in T13077 shortly.

It's plausible that we might support this some day, but there's no clear pathway forward and no support mana behind this feature so I'm going to banish this task to the shadow realm. Herald provides a workaround in at least some cases.

"Disable User", specifically, is now granular.

See PHI690. An install would like access to Drydock lease metrics, notably the time a lease spent in queue. See also T13073, but this is more narrowly scoped.

I kicked some user/profile/account stuff to T13190.

I made this public since I've disclosed/discussed this elsewhere, including an indirect reference in the Spaces documentation, and I'm going to schedule it alongside some other stuff.

That one seemed straightforward.

Doing admin001 now.

Kicking secure001 now.

(It not being covered is covered by T12879.)

I think the only thing on secure or admin which isn't properly covered by deploy automation is the crontab on secure001:

I'm going to do admin001 and secure001 today.

I landed D19586 (the thing which breaks T13186) and pushed it here. This generally causes us to perform more policy checks, and may cause new policy exceptions which did not exist before (because the workflows relied implicitly on weak policy enforcement). If these crop up, the remedy is generally to explicitly weaken the required capability for the action.

I punted the rest of this to T13189.

The actual evidence about webhooks is a little spotty and it's possible that they "work" and are just undocumented and not officially supported. It's possible that CircleCI just needs a nudge to actually document/support them.

See T13188 for CircleCI 2.0. Upshot: they removed webhooks so we can no longer interact with them.