dotCMS / dotCMS/ai-workflows

Make sticky comments toggleable (enable/disable per repo)

Open
#45 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
Dominant language
No language data
Stars
1
Forks
0
Avg merge
4h 4m
Merged PRs (30d)
1

Description

Summary

Add an orchestrator input to enable/disable sticky comments per-repo (or per-invocation), so a review can post a new comment each run instead of updating one in place.

Motivation

@wezell wants sticky comments off for his OVH repo. He prefers the interleaved history timeline on the PR: review → commit with fix → next review → commit, etc. Sticky comments collapse that into a single self-updating comment, erasing the back-and-forth that he uses to follow how the PR evolved.

Today sticky behavior is effectively always-on:

  • Anthropic path (claude-executor.yml) hardcodes use_sticky_comment: "true".
  • Bedrock generic (bedrock-generic-executor.yml) and Codex (codex-executor.yml) always run their /tmp find-or-update sticky helper.

There's a sticky_namespace input but no way to turn stickiness off.

Proposal

Add a boolean sticky_comments input to claude-orchestrator.yml (default true to preserve current behavior) and thread it to all three executor paths:

  • Anthropic: map to use_sticky_comment: ${{ inputs.sticky_comments }}.
  • Bedrock generic / Codex: when false, skip the find-or-update step and just create a fresh comment (post instead of patch).

Repos that want the timeline (OVH) set sticky_comments: false in their caller workflow.

Acceptance criteria

  • sticky_comments input on the orchestrator, default true (no behavior change for existing consumers).
  • When false, each review run posts a new PR comment on all three executor paths.
  • When true, behavior is unchanged (single updating comment, sticky_namespace still respected).
  • Documented in CLAUDE.md / ARCHITECTURE.md alongside sticky_namespace.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading claude-orchestrator.yml, then compare claude-executor.yml, bedrock-generic-executor.yml, and codex-executor.yml to trace sticky_comments and sticky_namespace. Verify how each path finds, updates, or posts comments. Done means the default preserves sticky behavior, false posts a new comment on all three paths, and the option is documented in CLAUDE.md or ARCHITECTURE.md.

Written by the indexing model from the issue text.

Assessment

Tech stack
github-actions
Domain
ci-cd, documentation
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Clearly specified
Newbie friendliness
68/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.