Notification Policy: Github PR Comment improvements

The label feature:add_plan_pr_comment is noted deprecated in the documentation. We evaluated to replace it by a notification policy like recommended. However we struggled to have an usable result:

• View in the example with a third column “Changes” containing changes in JSON is mostly unreadable, it produces long inline JSON.

• Deduplication doesn’t seem to work (comment is posted once but doesn’t seem updated afterward).

• If we want to mimic the feature:add_plan_pr_comment label result, we can’t. spacelift::logs::planning placeholder can be used but can’t be modified inside the rego policy code (probably replaced afterwards).

  • with feature:add_plan_pr_comment label, plan longer than 65535 characters is stripped from the beginning in order to always keep the end (the visual OpenTofu diff). With spacelift::logs::planning, the stripping is done by the Github API (normal behavior when comment is higher than the limit), so the end of the plan is stripped (with many changes, only the lines with “Reading...“, “Refreshing state...“, “Read complete after 1s [id=608519287]” remain, and the visual OpenTofu diff is cut).

  • with feature:add_plan_pr_comment label, a new comment is created when a new run is done and older comments are minimized. With notification policy, a new comment is created but older stay active and visible when no deduplication key is set (when set, no new comment or update are done => see point above).

It would be good to have a way to obtain the planning logs without the refresh part or a way to manipulate them from the rego policy (e.g., in order to strip them to 65535 but from then end).

Also, the deduplication/handling of older comments should work like the feature:add_plan_pr_comment label (i.e., add a new comment with new run and hide/minimize the older ones).