dot-release-rollback-check

Inspects merged PRs between two dotCMS versions to determine rollback safety.

950|482|Updated Mar 15, 2012
One-click install
npx skills add https://github.com/dotCMS/core --skill dot-release-rollback-check
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: dot-release-rollback-check
Source: https://github.com/dotCMS/core/tree/main/.claude/skills/dot-release-rollback-check
Command: npx skills add https://github.com/dotCMS/core --skill dot-release-rollback-check

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Rolling back a dotCMS release without knowing which merged PRs introduced database migrations, index changes, or API contract changes risks breaking the target environment. This Skill automates the audit by checking every PR merged between two versions for rollback-safety labels.

Core Features & Use Cases

  • PR Range Analysis: Extracts all merged PR numbers from the git commit range between two version SHAs, correctly handling backports and reverts.
  • Label-Based Classification: Categorizes each PR as SAFE, NOT_SAFE, CONFLICTING, or UNLABELED based on rollback-safety labels fetched via the GitHub CLI, flagging low-risk CI/infra changes separately.
  • Structured Verdict Report: Generates a Markdown report with risk notes per PR and a final YES / NO / CONDITIONAL rollback verdict, optionally saved as a text file.
  • Use Case: Before reverting a production deployment from 26.04.28-02_7149dce to 26.04.11-02_9650131, run the check to confirm no PR in the range carries a "Not Safe To Rollback" label.

Quick Start

Ask the assistant to check whether dotCMS release 26.04.28-02_7149dce can be safely rolled back to 26.04.11-02_9650131.

Frequently Asked Questions about dot-release-rollback-check

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I check if a dotCMS release can be rolled back safely?

Run the check with two version strings in YY.MM.DD-patch_commitsha format from inside a dotCMS/core checkout. It extracts merged PRs between the two commit SHAs, fetches their rollback-safety labels via the GitHub CLI, and returns a YES, NO, or CONDITIONAL verdict.

How are pull requests classified for rollback safety?

Each PR is classified by its labels: NOT_SAFE if it has a "Not Safe To Rollback" label, SAFE if it has a "Safe To Rollback" label, CONFLICTING if it has both, and UNLABELED if it has neither. Unlabeled CI or infra PRs are flagged as low-risk.

What version format does the rollback check require?

Versions must match the pattern YY.MM.DD-patch_commitsha, such as 26.04.28-02_7149dce. The short commit SHA after the underscore is used to compute the git commit range between the two versions.

Why does the rollback check fail to resolve commit SHAs?

SHA resolution fails when the local repository lacks the commits, usually because it has not fetched recently. The Skill runs git fetch --all and retries; if SHAs still cannot be resolved, verify the version strings and that you are inside a dotCMS/core checkout.

What does a CONDITIONAL rollback verdict mean?

CONDITIONAL means no PR is explicitly labeled NOT_SAFE, but there are PRs with conflicting labels or non-trivial unlabeled PRs. These require manual engineering review before proceeding with the rollback.