[CI] Determine best practices for large CI workflows in GitHub Actions

[mehcode]

Goals

• Build sqlx and its direct dependents (sqlx-core, sqlx-macros)

  • Build with no feature flags
  • Build with all feature ( all types and all databases ) plus runtime-RUNTIME for each runtime

• Run unit tests under all feature flag for sqlx-core

• Check format on everything with rustfmt

• Run integration tests on multiple database versions for sqlx

• Build cargo-sqlx and run any of its unit tests ( keeping this separate as it's technically a user of sqlx )

• Build examples under the latest database version

---

I wonder if it would be better to do a workflow per "goal" ?

[mehcode]

After thinking this over, we need to move off of Github Actions. We basically need ( to stay sane ) a dozen workflows but that execute in a flow so that we don't run 40 jobs at once where 39 will fail because the project doesn't pass cargo check.

Anyone have any good ideas?

[bjeanes]

I think I can help with this. I have set up GH workflows where cargo check/cargo test is run before having a matrix build for cross-compilation.

I think a similar strategy could work here where a simple smoke test is run and if that is successful a matrix could be kicked off to run builds/tests in a variety of situations.

EDIT: I attached some examples in another comment below but in reviewing your existing workflows there isn't anything novel in my suggestion. Your workflows could be refactored a bit to lean more on matrices to de-dupe but the gains would likely be minimal. That being said, I don't know of any alternative to GitHub Workflows which would make a build for such a complicated set of heterogeneous scenarios any less complicated.

[bjeanes]

Is MSRV vs stable vs nightly another axis here?