Bug: github-add-comment. produces too large task results

[mikem-of]

I'm using the github-add-comment to add comments to my PR and got hit with this error:

I'm getting this error:

STEP-POST-COMMENT
2026-03-18T16:01:24.110890856Z Sending this data to GitHub with POST:
2026-03-18T16:01:24.110890856Z {'body': '### 📦 Published npm packages\nUse the following commands to install them:\n\n- npm install xxx@0.0.1<#comment #comment=" published-npm-packages "></#comment>'}
2026-03-18T16:01:24.110890856Z a GitHub comment has been added to https://github.com/xxx/xxx/pull/123
2026-03-18T16:01:24.124258024Z 2026/03/18 16:01:24 Error while writing message: Termination message is above max allowed size 4096, caused by large task result.

This task writes two task results:

• catalog/task/github-add-comment/0.7/github-add-comment.yaml

  Line 27 in 255f9d3

  - name: OLD_COMMENT

• catalog/task/github-add-comment/0.7/github-add-comment.yaml

  Line 30 in 255f9d3

  - name: NEW_COMMENT

I downgraded to 0.3 as a workaround as that version does not write any task results.

[Odilhao]

Just hit this, at theforeman/candlepin-oci-images#42

[vdemeester]

Root cause

Versions 0.4–0.7 write the entire GitHub API response object to the task results:

• NEW_COMMENT gets resp.read() — the full JSON for the created/updated comment (body + user object, reactions, all *_url fields, timestamps, node_id, …).
• OLD_COMMENT (in the REPLACE=true path) gets str(matching_comment[0]) — the whole comment dict stringified.

Tekton stores step results in the pod's termination message, which is capped at 4096 bytes shared across all results of the step. A full comment response easily exceeds that, producing:

Error while writing message: Termination message is above max allowed size 4096, caused by large task result.

It's also a semantic bug: the results are documented as "the old/new text of the comment" but actually contain the full API object.

Fix

I've opened a fix that adds version 0.8 which writes only small, bounded values parsed from the response:

• COMMENT_ID — the numeric comment id
• COMMENT_URL — the comment html_url

This keeps the useful output (identifying/linking the comment) while staying well under the 4096 byte limit regardless of comment size.

Note the existing 0.3 workaround works only because that version writes no results at all.