Story (Required)

As a <Pipelines-as-Code administrator>, trying to <diagnose a failed PipelineRun>, I want <the error log snippet in the GitHub Check Run to be truncated to prevent API failures and for its line count to be configurable>.

This story addresses a bug where long error logs cause the GitHub Check Run update to fail due to a character limit in the GitHub API. This leaves users with no feedback on their Pull Request. By truncating the log and making the line count configurable, we ensure the Check Run always posts successfully and give administrators control over the verbosity of the error snippets.

Background (Required)

The GitHub Checks API has a 65,535 character limit for the content of a check run. When a PipelineRun fails, Pipelines-as-Code attempts to fetch a log snippet from the failing task to display in the check run's summary. If the task's log output (e.g., a long stack trace) exceeds this limit, the API call to GitHub fails. Consequently, the check run status is not updated, and the user is left without crucial failure information on their PR.

Currently, the number of lines fetched for this snippet is hardcoded. This story aims to fix the API failure by truncating the snippet and also introduces a new configuration key to allow administrators to control how many lines are fetched.

Out of scope

• Applying this logic to other SCM providers that do not have this limitation.
• Creating a UI for this configuration; it will be managed via the `ConfigMap` only.

Approach (Required)

1. Introduce a Safeguard: In the log collection logic (`pkg/kubeinteraction/status/task_status.go`), enforce a hard character limit of 65,535. Before posting the status, check the length of the generated log snippet and truncate it if it exceeds the limit. This ensures the GitHub API call will not fail due to oversized content.
2. Add New Configuration:

• Introduce a new key `error-log-snippet-number-of-lines` in the `pipelines-as-code` `ConfigMap`.
• Set a safe default value of `3`.
• Add the corresponding `ErrorLogSnippetNumberOfLines` field to the `Settings` struct in `pkg/params/settings/config.go`.
  3. Implement Configuration:
• Remove the hardcoded number of lines in `pkg/reconciler/status.go`.
• Update the reconciler to use the new `ErrorLogSnippetNumberOfLines` value from the settings when calling `CollectFailedTasksLogSnippet`.
  4. Update Documentation and Tests:
• Update the settings documentation to include the new `error-log-snippet-number-of-lines` key, explaining its purpose, default value, and the reason for the GitHub character limit.
• Update unit tests in `pkg/params/settings/config_test.go` to cover the new setting.

Dependencies

• None.

Acceptance Criteria (Mandatory)

• Given a PipelineRun fails and produces a log snippet longer than 65,535 characters,
• When Pipelines-as-Code processes the failure to update the status,
• Then the GitHub Check Run is created/updated successfully, and the log snippet is truncated to fit within the limit.

• Given an administrator sets `error-log-snippet-number-of-lines: "10"` in the `pipelines-as-code` `ConfigMap`,
• When a PipelineRun fails,
• Then the error snippet in the GitHub Check Run should contain 10 lines from the failed task's log (unless truncated by the character limit).

• Given the `error-log-snippet-number-of-lines` key is not present in the `ConfigMap`,
• When a PipelineRun fails,
• Then the system defaults to showing 3 lines in the error snippet.

INVEST Checklist

Dependencies identified

Blockers noted and expected delivery timelines set

Design is implementable

Acceptance criteria agreed upon

Story estimated

Legend

Unknown

Verified

Unsatisfied

Done Checklist

Code is completed, reviewed, documented and checked in
Unit and integration test automation have been delivered and running cleanly in continuous integration/staging/canary environment
Continuous Delivery pipeline(s) is able to proceed with new code included
Customer facing documentation, API docs etc. are produced/updated, reviewed and published
Acceptance criteria are met