dotCMS / dotCMS/core

dotbot review: override review model roster via DOTBOT_REVIEW_MODELS instead of adding to it

Open Beginner friendly
#37,348 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

dotCMS : Workflow Team : Cloud Eng
Dominant language
Java
Stars
970
Forks
486
Avg merge
3d 33m
Merged PRs (30d)
170

Description

Problem

Our dotbot-review.yml passes review_models: ${{ vars.DOTBOT_REVIEW_MODELS }} to the review action. The action's review_models input is additive — the models in the repo VARIABLE run alongside the action's default roster, so setting DOTBOT_REVIEW_MODELS grows the reviewer set instead of replacing it (this is how a 3-reviewer roster happened on ovh-k8s-cluster PR #843).

Proposed fix

Adopt the pattern already proven in dotCMS/ovh-k8s-cluster's dotbot-review.yml:

  • When DOTBOT_REVIEW_MODELS is set, a pre-step renders .openrouter-review.yml from it. The action reads that file as its primary + extras — a full replacement of the roster. First entry = primary reviewer; the rest are the "fight" secondaries.
  • When DOTBOT_REVIEW_MODELS is unset (or parses empty, with a ::warning::), nothing is rendered and the action's own defaults stand.
  • Preserve the existing trigger gating unchanged: the workflow must still fire only when the PR : dotbot review label is on the PR (and re-run only when that specific label is added/removed — not on unrelated label churn). The ovh-k8s-cluster reference lacks this gating; do not copy its on: block.
  • Drop the review_models: input entirely.
  • Switch from wezell/openrouter-code-review-action to the forked dotcms/openrouter-code-review-action, and pass github_approval_token: ${{ secrets.DOTBOT_GITHUB_USER_PAT }} as the ovh-k8s-cluster workflow does.
Reference implementation (ovh-k8s-cluster)
- name: Override review roster from DOTBOT_REVIEW_MODELS (when set)
  if: ${{ vars.DOTBOT_REVIEW_MODELS != '' }}
  env:
    REVIEW_MODELS: ${{ vars.DOTBOT_REVIEW_MODELS }}
  run: |
    MODELS=()
    IFS=',' read -ra PARTS <<< "$REVIEW_MODELS"
    for p in "${PARTS[@]}"; do
      p="${p//[[:space:]]/}"
      [[ -n "${p}" ]] && MODELS+=("${p}")
    done
    if (( ${#MODELS[@]} == 0 )); then
      echo "::warning::DOTBOT_REVIEW_MODELS set but parsed empty — using action defaults"
      exit 0
    fi
    {
      echo "review:"
      echo "  model: ${MODELS[0]}"
      if (( ${#MODELS[@]} > 1 )); then
        echo "  models:"
        for m in "${MODELS[@]:1}"; do echo "    - ${m}"; done
      fi
    } > .openrouter-review.yml
    echo "Rendered .openrouter-review.yml from DOTBOT_REVIEW_MODELS:"
    cat .openrouter-review.yml
- name: dotbot autonomous review
  uses: dotcms/openrouter-code-review-action@a716ed1aaa24814e11ed684901b1f1525e8ee353
  with:
    mode: review
    openrouter_api_key: ${{ secrets.OPENROUTER_API_KEY }}
    github_approval_token: ${{ secrets.DOTBOT_GITHUB_USER_PAT }}
    reasoning_effort: medium
    web_search_mode: cached
    debug_level: 1

Notes

  • This repo's workflow has extra gating the ovh version lacks (label-gated if, fork skip, job-level concurrency) — keep all of that; only change the roster-override step and the action ref/inputs.
  • Keep the commit-SHA pinning convention for the action ref.
  • Needs DOTBOT_GITHUB_USER_PAT secret present in this repo (it is used elsewhere for dotbot).

Contributor guide

Open the contributing guide

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

Read .github/workflows/dotbot-review.yml first, then compare its roster handling with the linked ovh-k8s-cluster workflow and the existing label, fork, and concurrency gating. Done means the configured roster replaces the action defaults when populated, empty input warns and preserves defaults, the forked action and approval token are used, and the trigger gating remains unchanged.

Written by the indexing model from the issue text.

Assessment

Tech stack
github-actions, shell, yaml
Domain
ci-cd
Issue type
Bug
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Active
Clarity
Clearly specified
Newbie friendliness
87/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.