chore(ci): run dependency:analyze in its own parallel job

[stian-sandvold]

Why

The unit-test job runs two Maven invocations back to back:

- name: Run unit tests
  run: mvn clean test ... --activate-profiles unit-test
- name: Run dependency analysis
  run: mvn dependency:analyze --file ./dhis-2/pom.xml

dependency:analyze (the standalone goal) forks its own build up to test-compile. So that second step quietly recompiles the entire reactor a second time, inside the unit-test job, just to run a dependency check that has nothing to do with unit tests. On recent runs that step costs ~1m35s.

What this does

• Removes the dependency:analyze step from unit-test.
• Adds a dedicated dependency-analysis job that runs mvn dependency:analyze on its own runner, in parallel with the test jobs.
• Adds the new job to the Slack-on-failure notification's needs list so a failure on master is still reported.

The check still runs on every PR and push, with the same fail-on-warning behaviour (<failOnWarning>true</failOnWarning> is configured on the plugin in dhis-2/pom.xml, including the same ignoredUnusedDeclaredDependencies allowlist) — it just no longer sits on the unit-test critical path.

Effect

• unit-test drops ~1m35s and the confusing hidden recompile.
• The dependency check moves off to a parallel job. The integration jobs gate the overall workflow, so a ~3–4 min analysis job runs for free on wall-clock.

Note: this does not change the overall workflow wall-clock (the integration jobs are the critical path, not unit-test) — it's a cleanup that speeds up the unit-test check itself and removes a hidden second compile.

For a maintainer to check

If dependency:analyze (previously surfaced under the unit-test check) was a required status check in branch protection, the new dependency-analysis check name needs to be added there so it stays required.

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[enricocolasante]

Effect

• unit-test drops ~1m35s and the confusing hidden recompile.
• The dependency check moves off to a parallel job. The integration jobs gate the overall workflow, so a ~3–4 min analysis job runs for free on wall-clock.

The analysis job is faster than 3~4 minutes, right? Because it is true that it will run in parallel so the overall time do not change, but if we add a new job with that big overhead, it could be a shot in the feet when there are multiple PRs running.

[enricocolasante]

Are you going to make dependency-analysis job required after the PR is merged?

[stian-sandvold]

Yeah, I'll make it required after!