Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 27.75%. Comparing base (f407f97) to head (688febc).
⚠️ Report is 90 commits behind head on main.

@@            Coverage Diff             @@
##             main    #3884      +/-   ##
==========================================
+ Coverage   26.33%   27.75%   +1.41%     
==========================================
  Files         465      477      +12     
  Lines       24951    25679     +728     
==========================================
+ Hits         6572     7128     +556     
- Misses      17661    17822     +161     
- Partials      718      729      +11     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

/retest

/lgtm

@enarha @khrm PTAL

New changes are detected. LGTM label has been removed.

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
To complete the pull request process, please ask for approval from jkhelil after the PR has been reviewed.

The full list of commands accepted by this bot can be found here.

Tide was flagging this as unmergeable because the branch had a merge commit from syncing upstream/main, which a clean rebase can't replay past a later commit (39604bf5d) touching the same function. Rebased onto current main and resolved it so history is linear again — no logic changes, the two touched files are byte-identical to what was already passing CI here. Tests and build still pass locally.

/assign @jkhelil

Rebased and green — let me know if anything else would help move this toward approval.

@enarha @khrm Could you please take a look?

Fair point — if logs already land in storage some other way (an external forwarder, or a LokiStack-based viewer), pushing through the Watcher too would be redundant, and leaving watcher.logs_api off by default there is correct. The conflict is with #2600 itself and the PVC example in TektonResult.md: those only set the top-level logs_api with nothing else configured to get logs in, so the feature silently never stores anything. Would you rather I drop this default and instead fix the docs to have users set watcher.logs_api explicitly, so we don't risk flipping behavior on upgrade for anyone currently relying on the existing default (e.g. LokiStack users)?

@khrm Done in 688febc, which replaces the original commit. The setDefaults change and its test are gone, so the watcher default is unchanged and the PR is docs only now:

• docs/TektonResult.md: a note under the spec example says that the top-level logs_api only enables the API server's logs API, that the watcher forwards logs only with watcher.logs_api: true (default false), that it can stay unset when another forwarder such as Vector or Fluentd with LokiStack stores the logs, and that log forwarding by the watcher is expected to be removed in a future release. The example now sets watcher.logs_api: true with a comment pointing to the note.
• docs/TektonConfig.md: the result.watcher example sets logs_api: true with the same comment, and the logs_api row of the watcher table says the same in short.

Title and description are updated to match.