Add code coverage and matrix filters to omni action

[sehrope]

Adds action inputs to customize gradle arguments and filter the generated matrix.

Also adds uploading of code coverage step at the end of the omni ci action. It's set to execute only if the gradle args actually include jacoco. Code coverage is enabled by default so the daily scheduled executions should give us a nice history as well.

By default the matrix filters allow the entire matrix as it's intended to be executed once per day on the full set. Manual dispatches to start the omni action can filter whatever subset they want:

This let's you do things like "Only run on PG version 11", "Only run on JDK version 11", or "Only run on Zulu with SCRAM disable".

[davecramer]

what does * mean here, all of the distros ?

[sehrope]

Yes. Empty string or "*" (star) match everything for any filter. I added the star value as it looks a bit cleaner in the UI.

[sehrope]

Here's an example of the coverage reports: https://codecov.io/gh/sehrope/pgjdbc/tree/a3b65213f00aa74b5492e1d45ed1e84199fff5f4/pgjdbc/src/main/java/org/postgresql

[vlsi]

@sehrope , what do you think of adding a hard limit on the number of scheduled jobs? For instance, 10-20.

[sehrope]

@vlsi I'm against it because this thing is only running once a day or manually anyway. In either case we want the entire thing to run. Plus thanks to tweaking the test configs the total runtime is only 20 min anyway.

[davecramer]

20 min is amazing. I would have expected longer. If this is the case then I'm fine with it

[vlsi]

What is the total CI time the thing burns for one execution?

[sehrope]

It averages about 6-8 min per combination depending on options of which there's currently 27. With GitHub action parallel job execution the automated run from this morning took 17 min of wall time: https://github.com/pgjdbc/pgjdbc/actions/runs/841251297

For comparison, that's less wall time than the current main.yml action which one runs once per PR push. Total execution time is just about twice as much (189m for omni vs 91 for the most recent main). And this is once per day or manually triggered so even if it were to take longer it'd be fine as it's meant to be a more comprehensive test.

If we get notified that it's too much CI usage then we can address it then. I doubt that it's an issue though as I've seen significantly more expansive workflow usage on other projects and this is only daily anyway.

[vlsi]

Just in case, GitHub provides 2000 free CI minutes per month.
If a single job takes 6 minutes, and "omni" fires 27 jobs, then single execution consumes 162min which is 8% of the monthly limit.

Per-minute rate is $0.008 Linux which yields 162*0.008 = $1.3 per single execution.

Even though we do not push that often yet, I would like to avoid a case when "omni" burns all the CI time in a matter of couple executions.

[sehrope]

There's no limit for public repos. That "2000 free CI minutes" is for private repos: https://docs.github.com/en/github/setting-up-and-managing-billing-and-payments-on-github/about-billing-for-github-actions

GitHub Actions usage is free for both public repositories and self-hosted runners. For private repositories, each GitHub account receives a certain amount of free minutes and storage, depending on the product used with the account. Any usage beyond the included amounts is controlled by spending limits.

If there were a limit we would have hit it already as the per-PR push action uses 90+m per push and we've clearly had more than 23 pushes in a 30-day period.

In the off chance they do start enforcing a FOSS public repo limit I think we'll still be fine as I bet they'd grant an exception for the most popular driver for the world's most powerful open source database 😄.