fix: enable the hub environments feature flag in the test harness

[hilalbursalii]

Third in the camunda-hub#28600/#28601 series, but a different mechanism from #567 and #570.

Problem

Run 34576767973 (hub PR check for camunda-hub#28601, expose environments in public API v2) failed 13 tests across all three suites — every one of them a new environments endpoint:

Suite	Failures
positive	getEnvironments, getProjectEnvironments, getWorkspaceEnvironments, replaceWorkspaceEnvironments — expected 200, got 404
secured	8 × replaceWorkspaceEnvironments — expected 400, got 404
rbac	getEnvironments - Denied (no permission) — expected 403, got 404

The 404 body is the tell, and it is not the same 404 as the catalog ones #567/#570 dealt with:

{"timestamp":1789113618009,"status":404,"error":"Not Found","path":"/api/v2/environments"}

Spring's default error attributes, not hub's RFC-7807 ProblemDetail (type/title/instance) — so no handler matched, the route is absent. GET /api/v2/environments takes no path parameter at all, which rules out any fixture/key cause.

HubV2EnvironmentController is triple-gated:

@ConditionalOnProperty(name = {
    Constants.PROPERTY_PUBLIC_API_V2_ENABLED,
    Constants.PROPERTY_WORKSPACES_ENABLED,
    Constants.PROPERTY_ENVIRONMENTS_ENABLED
}, havingValue = "true")

and hub declares the third defaulting to off, with no Self-Managed override:

# restapi/config/config-common/src/main/resources/application-common.yml
environments-enabled: ${CAMUNDA_MODELER_FEATURE_ENVIRONMENTS_ENABLED:false}

Our harness enabled public-api-v2, workspaces, catalog, console, global-nav and dynamic clusters — never environments.

No hub bug. Flag-off is a deliberate, tested state: #28601 ships AbstractHubV2EnvironmentFlagOffIT, SaasHubV2EnvironmentFlagOffIT and SelfManagedHubV2EnvironmentFlagOffIT. The generator emits tests from the spec, which declares the paths unconditionally, so the harness has to opt in — the same shape as the comment already in this block: "the public API v2 is OFF by default in the image, so /api/v2 returns 404 until enabled."

Change

One flag in docker/docker-compose.hub.yml, plus a note on a footgun worth documenting: the two env-var spellings in this block are not interchangeable. Each flag is only readable under the name application-common.yml binds it to — workspaces and catalog use the bare FEATURE_X_ENABLED, while public-api-v2, console and environments use CAMUNDA_MODELER_FEATURE_X_ENABLED. The wrong spelling leaves the flag silently off, which looks identical to this failure.

Verification status — why this is a draft

The environments ops cannot be verified yet, and I would rather say so than imply otherwise:

• The PR check here runs against hub main, where #28601 is not merged — the endpoints are neither in the bundled spec nor in the image, so the flag is a no-op and the check only proves no regression.
• An on-demand run has the same ceiling: it runs the published camunda/hub:SNAPSHOT image, which does not contain the controller code at all while #28601 is open. Pointing hub_ref at the PR branch would put the paths in the spec but not the controller in the image, producing the same 404 for a different reason.
• Real proof needs a hub-PR dispatch on #28601 with this merged into the generator's default branch — repository_dispatch always runs the workflow from the default branch.

One case may still fail after the flag is on, for a genuinely different reason: replaceWorkspaceEnvironments (PUT, expects 200) sends generated environmentIds. If the SM service validates that those ids exist, it may then 400/404 and need a real environment fixture — the same resourceFixtures treatment #570 gave assetKey. The three GETs should be fine (SM environments come from a persisted inventory with a constant organization, so an empty list still satisfies 200 + schema), and the 8 secured cases don't depend on it — their envelope only needs the already-fixtured workspaceKey, which the failing URLs show was real.

Testing

• docker compose -f docker/docker-compose.hub.yml config -q clean; parsed the file back to confirm the flag lands as CAMUNDA_MODELER_FEATURE_ENVIRONMENTS_ENABLED=true.
• Checked no other file in this repo sets hub feature flags (the compose file is the only place), so there is no second copy to keep in sync.
• No generator code changed, so suite output is unaffected apart from the newly-reachable endpoints.

🤖 Generated with Claude Code

[slolatte]

Heads-up: this change has effectively landed via #577 (merged as bbff68b), which set the same flag on the same lines of docker/docker-compose.hub.yml. So this PR is now redundant and will conflict against main.

One difference worth recording before it closes, since your description makes a claim about it. #577 used CAMUNDA_HUB_FEATURE_ENVIRONMENTS_ENABLED rather than the CAMUNDA_MODELER_FEATURE_* spelling here. Both work, but not for the reason given above — checked against camunda/camunda-hub@feature/environments-phase1:

• Constants.PROPERTY_ENVIRONMENTS_ENABLED is camunda.hub.feature.environments-enabled, and the controllers are @ConditionalOnProperty(..., havingValue = "true") with no matchIfMissing — so off by default, unmatched route, 404. That part of your description is exactly right, and it's the part that mattered.
• application-common.yml has environments-enabled: false hardcoded with no ${FEATURE_*} placeholder, confirming FEATURE_ENVIRONMENTS_ENABLED would not have worked here, unlike the neighbouring FEATURE_WORKSPACES_ENABLED and FEATURE_CATALOG_ENABLED.
• But LegacyConfigPrefixEnvironmentPostProcessor re-publishes every CAMUNDA_MODELER_* key under the new prefix, so the two spellings are interchangeable — contrary to the note this PR adds saying "the two env-var spellings are not interchangeable — each flag is only readable under the name hub's application-common.yml binds it to". The post-processor is what makes them interchangeable; it logs a WARN naming the replacement, and CAMUNDA_HUB_* wins when both are set.

So the only practical difference is that CAMUNDA_HUB_* is the non-deprecated spelling and doesn't log a deprecation warning on startup. Flagging it mainly so the "not interchangeable" claim doesn't get carried into another PR as received wisdom.

Not closing this myself — that's yours to do.

---

Generated by Claude Code