try partitions

[SteffenDE]

No description provided.

[SteffenDE]

@rhcarvalho it works!

[rhcarvalho]

@SteffenDE nice 👏 down to 3min.

Did you consider partitioning by DB? That was my strategy, because the pulling of DB images is sequential, taking 37-53s of the 3min on all 6 integration test jobs.

[SteffenDE]

We can try, though we have a lot more postgres tests than the other DBs

[rhcarvalho]

We can combine both per-DB and test partitions (e.g. for Postgres use 2 partitions).

Or we can decide to stop here, we went from 10min to 3min this week :)

[SteffenDE]

It seems indeed about 30 seconds faster, though just partitioning overall is less to think about

#6835

[rhcarvalho]

This was something I thought about this week. The previous approach was abort the other Elixir/OTP if one fails.

With or without partitions, fail-fast: false gives us complete visibility trading off CPU time. The only constraint here is 2,000 free Actions minutes per month:

• https://docs.github.com/en/actions/reference/limits#storage-limits-for-all-github-hosted-runners
• https://docs.github.com/en/billing/concepts/product-billing/github-actions#free-use-of-github-actions (same table)

[rhcarvalho]

If you do something like this we only need to write the versions once (I have something like this in a local branch):

Suggested change

	elixir: ["1.18.4", "1.20.4"]
	include:
	- elixir: "1.18.4"
	otp: "27.3.4.3"
	versions:
	- elixir: "1.18.4"
	otp: "27.3.4.3"

Then update the usage sites to be matrix.versions.elixir, etc.

Makes it easier to bump the versions without accidents.

[rhcarvalho]

This looks funny, the same job for push and pull_request triggers...

I'll fix it. It should be only pushes on main, I suspect?