ci: harden workflows and cancel in-progress workflows whenever new changes are pushed up

[G-Rath]

This just applies some standard stuff ensuring jobs only have the permissions they actually need and that in-progress jobs are cancelled whenever new changes are pushed up to reduce CI spend.

[nzlaura]

This looks good.

A non blocking question- were the permissions previously roo loose? I see you've updated to give the jobs read permissions 👍

[G-Rath]

were the permissions previously roo loose?

tl;dr: https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token

longer answer:

In the beginning, the default permission set was "permissive" which gave read/write access to most things - later GitHub introduced a "restricted" permission set which even later became the default for new repositories, but existing repositories had to manually switch to (since it could break existing workflows).

While technically it would be enough to just set that for each repository, it's not explicit in the workflow and requires us to have admin permissions on the repository (which we usually always do, but not always); so our convention is to always explicitly disable all permissions at the top level of a workflow and then explicitly configure the permissions required by each job.

In addition to ensuring jobs only have the access they actually need, it also makes things consistent - each job will always have the same permissions section (which is also why we place it as the very first property, since it'll always be there for every job), which you can audit at a glance.

[github-actions]

🎉 This PR is included in version 3.2.2 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀