🏭 Split GHA jobs and extract composite actions

[SimonMarquis]

Main advantages:

• improves GHA readability: less code in the main workflow files
• improves maintainability: composite actions are self contained
• reduces copy/paste mistakes & oversights (e.g. java version was set to 17 and 21)
• slight increase in total build time, but reduces the perceived parallelized time.

Extracted composite actions:

• setup-gradle
• setup-gradle-managed-devices
• setup-gradle-properties
• setup-java
• setup-kvm

Jobs split into more granular groups:

Current workflows

• test_and_apk: :build-logic:convention:check, spotlessCheck, dependencyGuard, dependencyGuardBaseline, verifyRoborazziDemoDebug, recordRoborazziDemoDebug, testDemoDebug, :lint:test, :app:assemble, :app:lintProdRelease, :app-nia-catalog:lintRelease, :lint:lint, :app:checkProdReleaseBadging
• androidTest: connectedDemoDebugAndroidTest, testDemoDebugUnitTest, createDemoDebugCombinedCoverageReport

New workflows

• checks: :build-logic:convention:check, spotlessCheck, dependencyGuard, dependencyGuardBaseline, :app:checkProdReleaseBadging
• assemble: :app:assemble
• lint: :app:lintProdRelease, :app-nia-catalog:lintRelease, :lint:lint
• unit-tests: verifyRoborazziDemoDebug, recordRoborazziDemoDebug, testDemoDebug, :lint:test
• instrumented-tests: connectedDemoDebugAndroidTest, testDemoDebugUnitTest, createDemoDebugCombinedCoverageReport

---

For the required checked jobs, this fan-in method can be applied to simplify the required checks configuration.

[SimonMarquis]

@dturner please take a look at this PR when you have time :)

[JoseAlcerreca]

Thanks for the PR Simon.

I'd say this adds complexity in exchange for readability. As it stands, the file is easy to understand and developers can copy-paste into their projects.

I don't think it's long enough or the code repetition is annoying enough to require this refactoring. I wouldn't merge, but happy to discuss.

[dturner]

I don't feel strongly either way. I think we should fix any mistakes and oversights but don't think the new format improves things that much. It's useful to see all the steps in a single workflow file.

[SimonMarquis]

Composite actions extraction aside (I can see it not being beginner friendly, and not a 1-step copy/paste), do you still see a benefit of showing how to properly split CI pipelines into semantic groups and also allow faster overall execution time?

[dturner]

Yes, I do like the new semantic groups.

[SimonMarquis]

I've restored the workflows by inlining the composite actions as requested.

Regarding this, how do you want to proceed?

For the required checked jobs, this fan-in method can be applied to simplify the required checks configuration.

Do you want to update the repository configuration (required checks) with all the new jobs, or do we add a single final-status job?