Having a missing on section doesn't appear to be a valid workflow at all, so it probably doesn't matter what we do in this case. So not erroring is perfectly fine. Not suggesting changing anything here but just trying to confirm my understanding.

Ah ok! I thought it might be valid - some strange stuff seems to be. I'll add a comment based on this feedback.

Is this definitely something we want to warn about, or should it if (!hasPush && hasPullRequest)?

I'm thinking about a workflow like

on: [workflow_dispatch]

so it's entirely manual. That would seem fine to me.

If you add this then adding the above as a test case would be good.

Ah, nice catch! Thanks ❤️

Why doc.on.pull_request instead of hasPullRequest?

It probably helps the type checker be convinced you're accessing something that exists, but in that case why not use doc.on.pull_request !== undefined to define hasPullRequest and then you might get that for free here too.

Also, the type of doc.on.pull_request is WorkflowTrigger | null | undefined so you're missing another bad case potentially.

Ah, I should probably add a comment! 🤔 🤦 Null actually means 'all branches' where undefined means 'not configured'. I thought I added a test case to show this but even if I did, it's not very clear.

Checking against undefined is intentional here as we want to skip the mismatched branches check if pull_requests are not enabled.

Since errorCodes is always used in the form t.deepEqual(...errorCodes(...)) would it make things simpler to change this to

import { ExecutionContext } from "ava";

function errorCodesDeepEqual(
  t: ExecutionContext,
  actual: actionsutil.CodedError[],
  expected: actionsutil.CodedError[]
){
  t.deepEqual(actual.map(({ code }) => code), expected.map(({ code }) => code));
}

I originally wrote it that way but then the error message points into that helper function instead of the test, which forces you to find the line number by hand and then look it up in the test file. 😞

I looked into extending the test library but it is minimialist to the point of brutalism. I couldn't extend it and keep the typechecker happy, and it involved a prototype overload which seemed dirty.

Ah fair. Making the test failures more readable is pretty helpful. Feel free to leave this as it is. My suggestion here was only because I thought it might be cleaner and not because there's anything bad about what's there currently.