Plumb liveness health-check-interval module parameter

[IvanBorislavovDimitrov]

Description:

Introduces a new MTA module-level parameter health-check-interval (Integer, seconds) and plumbs it end-to-end through the deploy service so it reaches the liveness health check on Cloud Foundry. This brings parity with Cloud Foundry's native health-check-interval setting and with the already-supported readiness counterpart (readiness-health-check-interval). Until now the value was silently ignored when present in an MTA descriptor.

The implementation mirrors the existing readiness-health-check-interval pipeline at every layer:

1. SupportedParameters — adds the HEALTH_CHECK_INTERVAL = "health-check-interval" constant and includes it in MODULE_PARAMETERS so the descriptor parser recognises it as a valid module parameter (no "unsupported parameter" warning).
2. StagingParametersParser — reads the value via PropertiesUtil.getPropertyValue(...), casts to Integer, and sets it on the ImmutableStaging builder. Default (parameter omitted) is null ⇒ no value is sent to CF and CF's default applies.
3. Staging — gains a @Nullable Integer getHealthCheckInterval() accessor in the liveness block, alongside getHealthCheckTimeout() etc.
4. CloudControllerRestClientImpl.buildHealthCheck — the outbound liveness Data.builder() chain now also calls .interval(staging.getHealthCheckInterval()), mirroring the readiness chain.
5. CloudProcess — gains the matching getHealthCheckInterval() accessor.
6. RawCloudProcess.derive — reads interval from the inbound CF liveness Data and propagates it via ImmutableCloudProcess.builder().
7. HealthCheckInfo — gains an interval field with getInterval() accessor, included in equals(...). StagingApplicationAttributeUpdater's liveness comparison already delegates to HealthCheckInfo.equals, so re-stage detection on a changed interval works automatically — no source change is required in the updater.
8. AdditionalModuleParametersReporter — adds a symmetric liveness log helper reportUsageOfHealthCheckParameters with the same field order and Dynatrace-observed comment as the readiness helper, so log analysis tools can match both branches identically.

The CF Java client 5.16.0.RELEASE shared org.cloudfoundry.client.v3.processes.Data already exposes getInterval() and Builder.interval(Integer) — no client upgrade was required.

Backward compatibility

The change is purely additive. Descriptors that do not declare health-check-interval continue to deploy unchanged: the parser sets the field to null, the outbound builder receives null, and CF's default health-check interval applies. Wire and descriptor formats are unchanged.

Tests

17 new/updated JUnit 5 cases across three modules, all passing locally:

• multiapps-controller-client — new HealthCheckInfoTest (10 cases) covers fromStaging / fromProcess populating the new interval field, type defaulting, null propagation, and the updated equals contract.
• multiapps-controller-core — StagingParametersParserTest extended (2 cases) to assert parsing + null default for health-check-interval.
• multiapps-controller-process — new AdditionalModuleParametersReporterTest (5 cases) verifies the new liveness branch is entered, tolerates a null interval, is skipped when health-check-type is missing, coexists with the readiness branch, and tolerates an empty parameter map.

Verification:

mvn -pl multiapps-controller-client,multiapps-controller-core,multiapps-controller-process \
    -am test \
    -Dtest='HealthCheckInfoTest,StagingParametersParserTest,AdditionalModuleParametersReporterTest' \
    -Dsurefire.failIfNoSpecifiedTests=false

→ BUILD SUCCESS, 17 tests run, 0 failures.

Issue:

JIRA: LMCROSSITXSADEPLOY-3316

[IvanBorislavovDimitrov]

MTA Quality Report — PR #1849

Jira: LMCROSSITXSADEPLOY-3316 — Introduce Health check interval
Backlog alignment: PASS

• Implements Jira scope? yes — End-to-end plumbing of the new health-check-interval module parameter (parser → Staging → outbound CF REST → inbound RawCloudProcess → HealthCheckInfo equality → log reporter) matches the Jira scenario exactly.
• Changes outside Jira scope? no — Every modified file is on the health-check-interval path and mirrors the established readiness-health-check-interval pipeline.

---

Code Review

No code-review findings (confidence ≥ 80).

The diff is a faithful additive mirror of the existing readiness-health-check-interval plumbing. The new constant is added to MODULE_PARAMETERS, parsed via the same PropertiesUtil.getPropertyValue pattern, propagated via builder, included in HealthCheckInfo.equals (so re-stage detection works without further changes to StagingApplicationAttributeUpdater), and the log reporter has a Dynatrace-observed sibling helper with the same field order as the readiness helper.

Minor stylistic note (not flagged): AdditionalModuleParametersReporter reads each parameter through three chained module.getParameters().get(...) calls — could be hoisted to a local Map — but the readiness branch directly above does it the same way, so consistency wins.

---

Security

No issues found. The change adds an Integer carried through internal POJOs and forwarded to the CF API. No new endpoints, no auth changes, no credential handling, no user-controlled I/O paths, no injection surface. The log statement uses MessageFormat with parameters, identical to the readiness sibling.

---

SonarCloud

SonarCloud check run ("Build and analyze") was still in_progress at the time of this scan — no quality-gate verdict or annotations are available yet. Re-run the quality agent once analysis finishes.

Check	Status
Build and analyze (SonarCloud)	in_progress
build	in_progress
Analyze (java)	in_progress
Check Commit Message	success

---

Dependency CVEs

No new CVEs — this PR does not modify any dependency files (pom.xml, build.gradle, lockfiles).

---

Verdict: READY TO MERGE pending SonarCloud quality gate.

Posted by adi-dev-workflow / mta-quality-agent.

[sonarqubecloud]

Quality Gate passed

Issues
3 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud