Update shared-setup.adoc

[Rajakavitha1]

added the signoz. details.

Related PR:
owncloud/ocis#11927
#1212

tested and validated the ocis_full deployment.

[Rajakavitha1]

Hi @mmattel I have tested and validated and incorporated the changes you suggested in this PR for the docs partial

[DeepDiver1975]

🤖 Automated review by Claude Code review agent.

Overview

This PR adds a single NOTE: admonition to modules/ROOT/partials/depl-examples/ubuntu-compose/shared-setup.adoc, advising that OCIS_TRACING_ENDPOINT must be reachable from the oCIS Docker network and that, with SigNoz under Docker Compose, this is typically the signoz-otel-collector service. Net change is +3 lines, one file. The intent is clear and the addition is well-placed in the "Edit the Configuration File" section among other configuration notes.

Code quality / style

• AsciiDoc syntax is correct. The single-line NOTE: macro form is valid and matches the prevailing style in this file (e.g. lines 50, 247, 275, 346, 348). Inline monospace via backticks (`OCIS_TRACING_ENDPOINT`, `signoz-otel-collector`) is rendered correctly and is consistent with surrounding usage.
• The note is wrapped across two source lines. With the NOTE: (single-line macro) form, AsciiDoc treats a hard line break in the source as a normal space, so this renders fine. However, the line is broken mid-sentence after "the", which is slightly awkward to read in source. Optional: keep the sentence on one line or break at a more natural point. (Note: the + hard-break convention used elsewhere in the bullet list does not apply here and is correctly not used.)

Specific suggestions

1. Tie the note to a config variable that the reader is actually editing. The surrounding bullet list ("Only a few settings need to be configured") enumerates INSECURE, TRAEFIK_ACME_MAIL, OCIS_DOMAIN, SMTP_xxx, etc. OCIS_TRACING_ENDPOINT is mentioned only in this new note and appears nowhere else in the file. A reader following these instructions has no context for where/how to set it. Consider either adding a * \OCIS_TRACING_ENDPOINT`` bullet to the list, or rewording the note to reference SigNoz setup more explicitly so it doesn't read as orphaned.
2. Cross-reference the SigNoz/observability docs. Since this is the only SigNoz mention in the file, an xref: to the dedicated SigNoz/tracing setup page (cf. the related PR #1212) would help readers who don't already have SigNoz running. Without it, "When using SigNoz with Docker Compose" assumes prior setup that isn't introduced here.
3. Capitalization consistency. The file uses "oCIS" here but "Infinite Scale" in the adjacent SMTP_xxx bullet ("Infinite Scale will be able to send notifications"). Both names appear in these docs, but within one section it is worth checking which the docs style guide prefers and aligning.

Potential issues / risks

• Technical accuracy: signoz-otel-collector is the conventional service/container name in SigNoz's docker-compose setups, so the guidance is plausible. However, the exact service name depends on the SigNoz compose file version and the user's network topology; "typically" appropriately hedges this. Please confirm the name matches the SigNoz version referenced by the related oCIS PR (#11927) so the example stays accurate.
• Reachability claim: "reachable from the oCIS Docker network" is correct in spirit — if SigNoz runs in a separate compose project/network, the collector won't be resolvable by service name unless the networks are joined. The note could briefly acknowledge this (shared/external network) to avoid sending users down a DNS-resolution dead end.
• No broken links/xrefs introduced. The diff adds no xref: or link: targets, so there is nothing that could dangle. Existing xrefs are untouched.
• Low risk overall: docs-only, additive, no build-breaking syntax.

Overall this is a useful, low-risk addition. The main improvement opportunity is giving OCIS_TRACING_ENDPOINT a home in the configuration list (or an xref) so the note isn't context-free for readers who haven't already set up SigNoz.