Probably a better approach would be to have the first step of the Jenkinsfile check the commit log vs the last build commit and if the all commits since the last build match a regex, then record the build as whatever the last build status was / user configurable.

If the branch source hid branches where the last commit matched a regex, then you would end up deleting the branch job - which is not what you want.

We don't know the changelog until the build is started and it would be costly to constantly check the changelog (requiring a full git clone for some repository hosting providers)

It would be - to my mind - relatively simple to have a pipeline step that checks the changelog against a regex and stops the build early if all commits since last build match the supplied regex.

Would that be an acceptable solution?

It would if it was possible to perform this check before the "build started" status was sent to Github. I'm not sure when such message is sent right now.

If the branch source hid branches where the last commit matched a regex, then you would end up deleting the branch job - which is not what you want.

This could be alleviated to some extent by setting "Days to keep old items" under Orphaned Item Strategy.

It would also be handy to skip some pull requests entirely (not even creating a job branch for them), for instance when the PR description contains "skip ci" or other regex specified in the job configuration.

That's not something you could do inside the Jenkinsfile at present, as I understand it.  Also, it sidesteps the whole "scanning the changelog" problem, because the PR description can be fetched from the GitHub API (and it's part of the webhook payload, if you're using webhooks).