Move CI to GitHub Actions

[jippi]

👋 Hello friends,

This PR moves CI from Circle CI to GitHub Actions and introduces a couple of new steps

• db tests that migrations apply cleanly against supported databases
  • mariadb:latest
  • mariadb:11
  • mariadb:10
  • mysql:latest
  • mysql:8.3
  • mysql:8.0
  • postgres:16
  • postgres:15
  • postgres:14
• php tests that
  • Supported PHP version (8.2 + 8.3) installs, builds, and tests passes cleanly
  • All files pass php -l (syntax check)
  • Tests all PHP files for code style against https://laravel.com/docs/10.x/pint
  • Uses same PHP image (https://hub.docker.com/_/php) and tooling as Refactor Docker/Compose #4844 to keep it consistent

Also lays the foundation for future tests using the various databases directly (or at all) in the future.

Further more, using GitHub Actions makes it easier for forks (since they likely also use GItHub) and it makes the testing output and status much more accessible to contributors directly, without going to 3rd party tools.

There are many opportunities to expand and improve our CI experience, having it managed in GitHub Actions will be a first important step for that.

Questions

1. Do we want to use Pint for code style? Something else? nothing at all?

• It seems to fail a lot currently https://github.com/jippi/pixelfed/actions/runs/7863233864/job/21453616057#step:10:1
• FAIL ............................ 1158 files, 1 error, 1000 style issues
• Example PR applying pint to Pixelfed can be found here: Format codebase with laravel/pint (Followup to #4921) #4922

[jippi]

Seems like 3.1 added PHP 8.2 support and 3.2 added PHP 8.3 supporting

With basically nothing else happening between those releases otherwise

[jippi]

this is just sorting keys alphabetically

[ThisIsMissEm]

I think these can be merged? They do the same thing?

[jippi]

there is a couple of differences between the MySQL and PostgreSQL jobs - and while it can be merged, I think the complexity of that isn't worth taking on vs a more verbose, but simple-to-follow step. CI should be as dumb as possible to keep it easy to debug and flexible.

• Different "health checks"
• Different DB "environment keys" (not PF ones, but the DB container image)

[ThisIsMissEm]

I'd probably recommend splitting this into a lint and test jobs, such that you can fail the workflow fast on linting issues? Though you are using fail-fast false below?

[jippi]

I merged the two into for a couple of reasons:

1. Avoiding confusing "cause and effect" situations where a syntax error caused many pipelines to fail (and having to figure out which) - or tests failing under PHP 8.x fail but not on PHP 8.y due to some syntax/issue.
2. There is no point in running tests (or its pipeline) if there is a syntax error, so it shortens full pipeline runtime from end-to-end.
3. Fewer CI jobs kicking off at the same time, to keep the number of CI jobs ~low.

I'm going to pull out the pint part for now though, as @dansup seem to want to do this a different way / timing.