Smarter triggering of CI

[VeckoTheGecko]

I think we can be smarter with the way that we are triggering CI. This is our current approach:

name: ci
on:
  push:
    branches:
      - "main"
      - "test-me/*"
  pull_request:
  schedule:
    - cron: "0 7 * * 1" # Run every Monday at 7:00 UTC

Every push to a PR triggers our entire CI. This results in wasted compute (note our CI runs 4 core 16 Gb machines) especially for pull requests that have a lot of back and forth - or PRs that make minor changes.

I think that we should still have green checks before merging - we don't want to compromise on quality - I just think that we need more flexibility to control when we request for these green checks.

I propose that we update the GitHub PR template to automatically label pull requests when they're made with "skip-ci" . When CI starts running, if it finds this skip-ci it will skip the CI. This label can be removed by the PR author (or another dev) when they want to opt into CI for that pull request.

[erikvansebille]

Agree, very good idea to limit the (environmental )impact of our dev work!