feat(logs): pass preferences to external providers

[akashchamp]

Changes

Passes the user's timestamp and selected log-level preferences to external log providers.

• Adds timestamps=<true|false> and repeated logLevel parameters to external log URLs.
• Propagates the preferences through PipelineRun and TaskRun fallback requests and external raw-log links.
• Documents the optional parameters for external providers. Only namespace, podName, and container are required; providers may ignore the rest.
• Adds URL, fallback, and toolbar coverage.
• Removes the externalLogsURL and isUsingExternalLogs props that were passed to the run-level LogsToolbar instead of the StepLogToolbar in an earlier refactoring.

Fixes #4981

Validation: targeted tests (137), the full test suite (614 passing, 1 skipped), lint, and production build pass. A live UI check requires an authenticated Tekton cluster and configured external log provider; neither is available on the remote host, so no cluster state or credentials were changed.

Submitter Checklist

• Docs included for this user-facing change
• Tests included for changed functionality
• Follows the commit message standard
• Meets the Tekton contributor standards (including functionality, content, code)
• Has a kind label
• Release notes block below has been updated for this user-facing change
• Release notes do not require action from users switching to the new release

Release Notes

External log providers can now receive the user's timestamp and log-level preferences.

AI disclosure

This PR was developed with AI assistance, disclosed per the Tekton AI contribution policy:

• The original implementation (code, tests, and docs) was generated with OpenAI Codex. This is recorded by the Assisted-by: Codex commit trailer; the earlier PR feat(logs): pass preferences to external providers. Fixes #4981 #5227 was opened from a codex/... branch.
• The revision addressing review feedback (the showTimestamps rename, the single-object argument for fetchLogsFallback, removing the misplaced LogsToolbar props, the header years, and the docs wording) was made with Claude Code (Anthropic), recorded by the Assisted-by: Claude Code commit trailer.

For the revised change, npm run lint and the full vitest suite were run locally and pass.

[tekton-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
To complete the pull request process, please assign kaushalnavneet after the PR has been reviewed.
You can assign the PR to them by writing /assign @kaushalnavneet in a comment when ready.

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

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[AlanGreene]

@akashchamp as mentioned on your previous PR, the Tekton community has an AI contribution policy that requires AI usage to be disclosed.

As far as I can see, all that has changed in this PR compared to the previous one is that you have renamed the branch to remove reference to 'codex'.

Please review the policy and update your PR appropriately to comply with the requirements. There is no need to close the PR and open a new one, you should be able to edit the commit message and PR description instead.

[akashchamp]

@AlanGreene I have updated the description

[AlanGreene]

Thanks for the PR @akashchamp, overall it looks good. I've added a few comments with minor suggestions, let me know if you have any questions.

[akashchamp]

Thanks for the pointer to the policy. I have updated the commit message with Assisted-by trailers for the tools used (Codex for the original implementation and Claude Code for the revision addressing your review) and added a matching AI disclosure section to the PR description that states the extent of the assistance. The review comments have been addressed in the same commit.

[AlanGreene]

A live UI check requires an authenticated Tekton cluster and configured external log provider; neither is available on the remote host, so no cluster state or credentials were changed.

This seems to suggest that this change hasn't actually been validated in a live environment. Is that correct?

The logs persistence walk-through provides an example of how an environment can be configured to validate this change end to end.

At a minimum, the Dashboard deployment can be updated to provide a dummy value for the external-logs URL. Once the Dashboard has restarted to pick up the config change, verify in the browser that the log fallback process still works as expected when a TaskRun pod has been deleted, and that the resulting URL via the logs proxy contains the expected params.