GitHub Actions should just build Linux, Mac, Windows per-push and PR

[icculus]

GitHub Actions should just build Linux, Mac, Windows as fast as possible per commit and PR, and once a day/hour/whatever we should do all builds, and things like static analysis and clang-tidy, etc.

This gets us really fast feedback when working and lets us do more janitorial work from time to time. Right now it takes way too long to do a basic sanity check on a commit.

Originally posted by @icculus in #3519 (comment)

[madebr]

As a 2nd tier goal, I think it would be nice to be able to trigger (all) workflows when some condition is met.
e.g. when somebody opens a pr concerning ps2, (at least) the ps2 workflow should run

[shish]

when somebody opens a pr concerning ps2, (at least) the ps2 workflow should run

For reference, you can filter triggers by paths like:

on:
  pull_request:
    paths:
    - '**/ps2/*'

You can also enable a manual trigger button on the GitHub Actions GUI like so:

on:
  workflow_dispatch:

So if we replaced ps2.yaml's current

on: [push, pull_request]

with

on:
  push:
  pull_request:
    paths:
    - '**/ps2/*'
    - '.github/workflows/ps2.yaml'
  workflow_dispatch:

Then that would run:

• on any push to the main repo
• on any pull request that touches PS2-specific files
• when the workflow itself is changed (debugging the workflows themselves is a pain without this...)
• when triggered manually (eg if you have a PR which doesn't touch PS2 files, but you want to test it on PS2 anyway)

[icculus]

Something I'm just realizing: GitHub Actions gives you 2000 minutes of CPU time per month for private repositories. They are free and unlimited for public repos.

It would still be nice to get faster feedback on commits, but this is no longer a concern of going over some limit.

So...is there a way to signal to GitHub Actions "I care about these builds most, please do them first and the rest are nice to see the results of eventually"? Maybe it doesn't matter, since there's probably a massive build farm churning through these tasks on GitHub's end.

[madebr]

So...is there a way to signal to GitHub Actions "I care about these builds most, please do them first and the rest are nice to see the results of eventually"? Maybe it doesn't matter, since there's probably a massive build farm churning through these tasks on GitHub's end.

I don't know of a way to prioritize a workflow job, there is an issue though.

[madebr]

I created a proof of concept to limit the number of platforms to build for at my fork.

example:

• specify nothing => build everything: https://github.com/madebr/SDL/actions/runs/4884564312
• commit message contains ci-run:android ==> build android: https://github.com/madebr/SDL/actions/runs/4884704047

It melds all workflows in one big file: this is done to make all build jobs depend on a master job.
It does not use workflow_dispatch, because there needs to remain a link between the event (=commit/pull request) and the run.

What platforms are build is controlled by ci-run:<job-name> text in the commit message.
By default, it builds SDL for all platforms. This should probably depend on the event type.

requested_jobs = extract_jobs_from_commit_message()
if not requested_jobs:
    requested_jobs = REDUCED_JOBS
if event.type == "push":
    if event.branch in ("main", "SDL2"):
        requested_jobs = ALL_JOBS
elif event.type == "pull_request":
    requested_jobs = ALL_JOBS

It (currently) has no finer granularity then platforms.

It has pros and cons.
pros:

• ability to not build all platforms
• you need to cancel only one workflow run when you (accidentally) pushed a faulty commit

cons;

• everything is in one file
• lots of duplicated code (which can probably be reduced by making use of workflow_call)
• too complicated? / Too custom? Does this already exist?