feat(Content Analytics) #35525 : Add docker-compose examples for Experiments and new CA infrastructure.

[jcastro-dotcms]

Summary

This is Part 2 of the work for #35525. It cleans up two issues introduced alongside the new Content Analytics docker-compose examples:

Changes

1. Fix stale directory reference in analytics/README.md

The README was pointing readers to the docker/ root of the dot-ca-event-manager repo, which is too broad. Updated to point directly to docker/analytics-infra-example/ — the actual directory containing the ClickHouse keeper, replica nodes, init scripts, and event manager service.

2. Remove hardcoded analytics env vars from single-node/docker-compose.yml

The generic single-node example had analytics-specific environment variables baked in:

DOT_ANALYTICS_BASE_URL: 'http://host.docker.internal:8080'
DOT_ANALYTICS_TENANT: 'cust-001'
DOT_ANALYTICS_PASSWORD: 'abc'
DOT_ANALYTICS_PROJECT: 'dev'
DOT_ALLOW_ACCESS_TO_PRIVATE_SUBNETS: 'true'
DOT_FEATURE_FLAG_CONTENT_ANALYTICS_AUTO_INJECT: 'true'

These don't belong in a general-purpose compose file — they expose internal credentials as defaults, enable a feature flag globally, and cause confusion for developers not working with analytics. These settings now live exclusively in the analytics-specific compose example where they are relevant.

Why it matters

• Developers following the single-node example no longer inherit analytics-specific flags they didn't ask for.
• The analytics README now gives a precise path rather than dumping developers at the repo root.
• Keeps each compose example focused and self-contained, which is the whole point of Add docker-compose examples for Experiments and new CA infrastructure #35525.

Testing

• Verify single-node/docker-compose.yml starts cleanly without the removed vars
• Confirm the analytics/README.md link resolves to the correct directory in dot-ca-event-manager

This PR fixes: #35525

This PR fixes: #35525

[claude]

Claude finished @jcastro-dotcms's task in 1m 3s —— View job

---

PR Review

Small, low-risk cleanup. A few notes worth a second look:

1. PR title vs. actual diff mismatch — Title says "Add docker-compose examples for Experiments and new CA infrastructure," but the only diff in this PR (branch suffix PR2) is a one-line README path update and removing 8 lines of analytics env vars from single-node/docker-compose.yml. No example is being added here. Either the title is stale (presumably the "add" landed in a prior PR) or commits are missing. Worth correcting the title so reviewers/changelog readers aren't misled.

2. External path reference is a broken-link risk — docker/docker-compose-examples/analytics/README.md:9 now points at docker/analytics-infra-example/ in dotCMS/dot-ca-event-manager. That path lives in another repo with its own lifecycle; if it gets renamed/moved, this doc silently rots. Two options:

• Pin to a tag/commit URL in that repo, or
• Link to a stable top-level entry point (e.g., that repo's README) which then directs to the example subdir.

3. Removed env vars from single-node/docker-compose.yml:65-72 — Pulling DOT_ANALYTICS_*, DOT_ALLOW_ACCESS_TO_PRIVATE_SUBNETS, and DOT_FEATURE_FLAG_CONTENT_ANALYTICS_AUTO_INJECT out of the single-node example is reasonable since analytics now has its own example. Two things to double-check:

• DOT_ALLOW_ACCESS_TO_PRIVATE_SUBNETS: 'true' — this is a security-relevant flag (allows the CMS to reach private/RFC1918 ranges, typically related to SSRF protections). Confirm that the default when unset is the safer value (disallow). If the default is "allow" you're fine; if removal flips behavior in a deployment that previously relied on this example, that's a regression. Worth verifying against the property's default in Config.
• Users who copy this example for local analytics testing now have no on-ramp; consider a short commented hint in the file pointing to the analytics/README.md.

4. Missing trailing newline in analytics/README.md (\ No newline at end of file in the diff). Cosmetic, but most linters/CI styles flag it.

Not blocking, but worth confirming: does the external repo's docker/analytics-infra-example/ actually exist at the time this merges? Easy to validate before merging.

If the title gets fixed and #3's security default is confirmed, this is good to go.
• branch

[jcastro-dotcms]

Claude finished @jcastro-dotcms's task in 1m 3s —— View job

PR Review

Small, low-risk cleanup. A few notes worth a second look:

1. PR title vs. actual diff mismatch — Title says "Add docker-compose examples for Experiments and new CA infrastructure," but the only diff in this PR (branch suffix PR2) is a one-line README path update and removing 8 lines of analytics env vars from single-node/docker-compose.yml. No example is being added here. Either the title is stale (presumably the "add" landed in a prior PR) or commits are missing. Worth correcting the title so reviewers/changelog readers aren't misled.

2. External path reference is a broken-link risk — docker/docker-compose-examples/analytics/README.md:9 now points at docker/analytics-infra-example/ in dotCMS/dot-ca-event-manager. That path lives in another repo with its own lifecycle; if it gets renamed/moved, this doc silently rots. Two options:

• Pin to a tag/commit URL in that repo, or
• Link to a stable top-level entry point (e.g., that repo's README) which then directs to the example subdir.

3. Removed env vars from single-node/docker-compose.yml:65-72 — Pulling DOT_ANALYTICS_*, DOT_ALLOW_ACCESS_TO_PRIVATE_SUBNETS, and DOT_FEATURE_FLAG_CONTENT_ANALYTICS_AUTO_INJECT out of the single-node example is reasonable since analytics now has its own example. Two things to double-check:

• DOT_ALLOW_ACCESS_TO_PRIVATE_SUBNETS: 'true' — this is a security-relevant flag (allows the CMS to reach private/RFC1918 ranges, typically related to SSRF protections). Confirm that the default when unset is the safer value (disallow). If the default is "allow" you're fine; if removal flips behavior in a deployment that previously relied on this example, that's a regression. Worth verifying against the property's default in Config.
• Users who copy this example for local analytics testing now have no on-ramp; consider a short commented hint in the file pointing to the analytics/README.md.

4. Missing trailing newline in analytics/README.md (\ No newline at end of file in the diff). Cosmetic, but most linters/CI styles flag it.

Not blocking, but worth confirming: does the external repo's docker/analytics-infra-example/ actually exist at the time this merges? Easy to validate before merging.

If the title gets fixed and #3's security default is confirmed, this is good to go. • branch

@claude regarding your feedback:

• This PR contains missing and minor changes that are part of a bigger change. That's why the title may differ from what was actually changed. This is fine.
• The External path reference will be solved as soon as the PR from the other repo is merged. This is fine and will be solved.
• The missing trailing newline can be ignored.

[claude]

Claude finished @jcastro-dotcms's task in 33s —— View job

---

Response to your feedback

Acknowledged on all three points — those are reasonable calls and consistent with the PR being part of a larger change set.

Quick confirmation on the one remaining item from my review (the security flag default):

I checked the codebase — the default for ALLOW_ACCESS_TO_PRIVATE_SUBNETS is false (the safer value) in every call site:

• CircuitBreakerUrl.java:78 — Config.getBooleanProperty("ALLOW_ACCESS_TO_PRIVATE_SUBNETS", false)
• XmlTool.java:156 — same default
• TempFileAPI.java:74 — same default

So removing DOT_ALLOW_ACCESS_TO_PRIVATE_SUBNETS: 'true' from single-node/docker-compose.yml flips that environment's behavior from allow → disallow private-subnet egress. That's actually a security improvement for the default single-node example (SSRF protection now applies), not a regression. Worth flagging only because anyone who was relying on that example for a setup that does need private-subnet calls (e.g., local analytics endpoints, internal services on the host network) will need to re-add it. Note experiments/docker-compose.yml:119 still sets it to 'true', so that path is preserved.

No further blockers from my side. Good to go once the linked external repo PR lands.

• Read trigger response
• Verify DOT_ALLOW_ACCESS_TO_PRIVATE_SUBNETS default in codebase
• Post final reply
  • branch