feat(reusable-on-code-change): derive the inputs a module should not have to declare

[baptistegrimaud]

What

Cut what a module has to declare to call reusable-on-code-change.yml. Inputs that repeat a fact the workflow can read from its own context are now derived; inputs that carried the same value in every caller got that value as their default.

Jahia/siteSettings goes from fourteen inputs to four:

with:
  module_id: siteSettings
  update_signature_execute: true
  integration_tests_provisioning_manifest: provisioning-manifest-build.yml
  integration_tests_testrail_project: Site Settings   # only takes effect once should_skip_testrail is false

That drops two inputs the workflow does not derive, on purpose. integration_tests_timeout: 45 is a cap rather than a target, and one shared timeout is the consistency this change is after. integration_tests_pagerduty_skip_notification: false is inert on a pull-request run: notifications also require CURRENT_BRANCH to be master, main or the primary release branch, and it is <n>-merge.

Derived instead of declared

Input	Now falls back to
module_branch (was required)	github.ref — the ref that triggered the caller
sonar_analysis_primary_release_branch (was main)	the base branch of the pull request, then the repository default branch, then main
integration_tests_artifact_prefix (was tests)	module_id
integration_tests_standalone_execute	runs when a provisioning manifest is given and no cluster run is requested

The fallbacks are resolved in the jobs (inputs.x || …), not in default:, so they stay context-safe.

Defaults retuned

Input	Was	Now	Why
static_analysis_auditci_level	moderate	critical	what 113 of the 144 on-code-change.yml in the organisation pass
integration_tests_should_skip_testrail	false	true	what a pull-request run wants, and every caller triggers on pull requests today
integration_tests_jahia_image	""	ghcr.io/jahia/jahia-ee-dev:8-SNAPSHOT	jahia_image is required downstream, and this is the value callers pass
integration_tests_artifact_prefix	tests	module_id	see above; it renames the test artifacts

integration_tests_should_use_build_artifacts is documented as deprecated and no longer forwarded to either test job: the underlying action carries deprecationMessage: This input is deprecated. Build artifacts are now downloaded if available and reads it nowhere, the integration-tests workflow never forwarded it either, and the download runs off build_artifacts unconditionally. integration_tests_should_skip_pagerduty gets the same treatment for a different reason — it is declared here but never forwarded to either test job, so setting it has never done anything.

Removes a trap rather than fixing a live bug

sonar_analysis_primary_release_branch becomes -Dsonar.pullrequest.base. A hardcoded main is the wrong new-code baseline for a pull request opened against a maintenance branch, and 14 repositories in the organisation still declare master. No repository experiences that today: both consumers pass the input explicitly, and the maintenance branches of the nearest migration target (Jahia/siteSettings 8_7_x, 8_12_x) still carry inline jobs, so a pull request against them uses their own workflow file, not this one. The fix is latent-correct — it stops the trap from being sprung by the migrations to come.

Untested end to end: no repository in the organisation passes a maintenance branch as sonar.pullrequest.base today, so whether SonarQube accepts one that has never had a branch analysis is unverified. Worth one throw-away pull request into 8_7_x after the migration reaches it.

Validated

Jahia/javascript-modules#726 — a throw-away pull request — calls this branch with four inputs instead of eleven. Its run 32485354032 — which resolved this branch at its head — is green, integration tests included, and each dropped input resolved as intended:

Dropped input	Observed in the run
module_branch	jobs checked out refs/pull/726/merge
sonar_analysis_primary_release_branch	sonar.pullrequest.base=main, from the base of the pull request
integration_tests_standalone_execute	the standalone job ran and passed, the cluster job stayed skipped
integration_tests_jahia_image	JAHIA_IMAGE=ghcr.io/jahia/jahia-ee-dev:8-SNAPSHOT
integration_tests_artifact_prefix	artifacts named standalone-javascript-modules-engine-1397, previously standalone-tests-<run>
integration_tests_should_skip_testrail	should_skip_testrail: true
integration_tests_should_use_build_artifacts	build-artifacts still downloaded, confirming the input is inert
static_analysis_auditci_level	audit-ci --skip-dev --critical

The integration_tests_cluster_execute path is reasoned, not exercised: no repository runs cluster tests through this workflow today.

What a migrating author must watch

• A module that gates on a severity below critical has to keep declaring it. Jahia/jahia-ui-root, Jahia/jahia-user-entries and Jahia/jahia-developer-tools pass auditci_level: high on their default branch, and Jahia/siteSettings does the same on 8_7_x, so maintenance branches need checking too. Dropping the input there would loosen the gate, and it would do so silently — fewer findings, no error. One repository has nothing to carry over and would loosen anyway: Jahia/jahia-authentication runs static-analysis with no level and has a root package.json, so it gates at moderate today and would move to critical on migration. 113 of the 144 on-code-change.yml in the organisation pass critical, which is what makes it the right default. The input description says so. Note this leaves the workflow default (critical) and the static-analysis action default (moderate) disagreeing — deliberately: retuning the action would silently loosen the gate for the ~45 repositories that call it directly, which belongs in its own change.
• Turning integration tests off is now done by removing the provisioning manifest, not by setting integration_tests_standalone_execute: false. With a manifest present and no cluster run requested, the standalone job runs regardless of that flag. A cluster-only setup still works by passing integration_tests_cluster_execute: true.
• The Jahia image default is passed down explicitly, so it also overrides whatever a module's own tests/docker-compose.yml falls back to. All 33 repositories that run integration tests from on-code-change.yml already set jahia_image explicitly, so no migrating module inherits this default by accident. It also closes a hole: Jahia/javascript-modules' tests/docker-compose.yml reads a bare ${JAHIA_IMAGE} with no fallback, so the previous empty default produced an invalid image reference. Note the flip side — a version-bearing tag as a shared default moves the Jahia-version decision from the module to the harness, and will retarget every caller that dropped the input when 9-SNAPSHOT arrives.
• update_signature_execute still has to be declared. See below.

Risk

Five defaults change behaviour for a caller that relied on them; passing the input explicitly keeps the old value.

Both current consumers are safe. Jahia/tools passes every retuned and derived input, so nothing changes for it at all. Jahia/javascript-modules passes all of them except integration_tests_artifact_prefix, so its test artifacts are renamed from standalone-tests-<run> to standalone-javascript-modules-engine-<run>; no workflow file in any non-archived repository of the organisation references standalone-tests or cluster-tests, though anything outside .github/workflows globbing the old name would miss.

Three migrations are open — Jahia/default#160 and Jahia/module-manager#203 are ready for review, Jahia/siteSettings#286 is draft. All three are immune whichever order things land in: the first two declare no integration_tests_* input at all and run no integration tests, and siteSettings passes each retuned input explicitly. They can be trimmed afterwards. About 45 repositories are still to migrate — retuning a default after they adopt it would be an org-wide event, which is the reason to do it now.

Not in this PR

The module signature. update_signature_execute still defaults to false, and the update-signature action is still a fixer that only acts on a [ci sign] commit, so it cannot fail a pull request whose signature is wrong. Making it verify, and gating the integration tests on it, needs a change to the action and a survey of which repositories would go red — its own PR. Until then a caller that wants the signature job must keep declaring update_signature_execute: true.