feat: implement /status command with full PR status report (BERTE-539)

[matthiasL-scality]

Summary

• Replaces the stub /status command with a real implementation that reports the live state of all merge prerequisites
• Reports: approvals (with details on missing approvals), integration branch build results, Jira fix-version correctness, and integration history health
• Each check is shown as a table row with a pass/fail indicator and inline details on failure

Details

commands.py

• _StatusItem: lightweight data class for a single status row (uses setattr(self, 'pass', ...) because pass is a Python keyword)
• _check_approvals_status: mirrors the check_approvals enforcement logic to report who/what is blocking approval
• _check_builds_status: reports worst build state across integration branches; skipped if no branches or no build key configured
• _check_fix_versions_status: checks Jira fix versions; skipped if Jira is not configured or checks are disabled
• _check_history_status: detects integration branch history drift (same logic as _reset); skipped if no integration branches
• _build_status_report: orchestrates all checks after cloning the repo and building the branch cascade

status_report.md: updated template to render inline failure details next to the :exclamation: indicator

Test plan

• test_status_command_reports_missing_approvals — status shows failing approvals when no approvals given
• test_status_command_approvals_pass_when_bypassed — status shows passing approvals when bypass options are set
• test_status_command_history_check — status includes history check and correctly detects when a reset is needed
• Full TestBertE suite passes (206 tests)

🤖 Generated with Claude Code

[claude]

LGTM

Review by Claude Code

[codecov]

Codecov Report

❌ Patch coverage is 99.73753% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 89.98%. Comparing base (ba48bc9) to head (5a58d98).

Files with missing lines	Patch %	Lines
bert_e/tests/test_bert_e.py	99.57%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #276      +/-   ##
==========================================
+ Coverage   89.62%   89.98%   +0.35%     
==========================================
  Files          81       81              
  Lines       10614    10981     +367     
==========================================
+ Hits         9513     9881     +368     
+ Misses       1101     1100       -1     

Flag	Coverage Δ
integration	87.78% <99.73%> (+0.54%)	⬆️
tests	87.74% <99.73%> (+0.55%)	⬆️
tests-BuildFailedTest	25.83% <7.34%> (-0.81%)	⬇️
tests-QuickTest	33.04% <7.34%> (-1.12%)	⬇️
tests-RepositoryTests	25.51% <7.34%> (-0.79%)	⬇️
tests-TaskQueueTests	49.51% <7.34%> (-1.85%)	⬇️
tests-TestBertE	66.96% <99.73%> (+1.46%)	⬆️
tests-TestQueueing	51.63% <7.34%> (-1.94%)	⬇️
tests-api-mock	14.82% <0.00%> (-0.52%)	⬇️
tests-noqueue	78.39% <99.73%> (+0.96%)	⬆️
tests-noqueue-BuildFailedTest	25.83% <7.34%> (-0.81%)	⬇️
tests-noqueue-QuickTest	33.04% <7.34%> (-1.12%)	⬇️
tests-noqueue-RepositoryTests	25.51% <7.34%> (-0.79%)	⬇️
tests-noqueue-TaskQueueTests	49.51% <7.34%> (-1.85%)	⬇️
tests-noqueue-TestBertE	63.49% <99.73%> (+1.60%)	⬆️
tests-noqueue-TestQueueing	25.53% <7.34%> (-0.79%)	⬇️
tests-server	27.38% <2.62%> (-0.86%)	⬇️
unittests	41.98% <2.62%> (-1.36%)	⬇️
utests	27.25% <2.62%> (-0.85%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[claude]

• _check_approvals_status diverges from enforcement logic when all approval bypasses are active: the enforcement check_approvals early-returns before evaluating change requests, but the status function always checks them — so the status command can report failing approvals where enforcement would actually pass
  • Add an early-return matching check_approvals lines 571-575: when all bypasses are met and unanimity is off, return a passing _StatusItem immediately

Review by Claude Code

[claude]

• Broad except Exception: in _check_fix_versions_status silently omits the fix-version check from the report on unexpected errors, unlike the enforcement flow which lets them propagate
  - Narrow the catch to the specific Jira/request exceptions that can occur here
  - History-checking loop in _check_history_status is duplicated from _reset
  - Extract a shared helper so changes to the ancestry analysis stay in sync
  - Test coverage: builds are only tested under bypass_build_status, and fix versions only for the missing-key case
  - Consider adding tests for non-bypass build states (FAILED, INPROGRESS) and incorrect fix-version mismatches
  
  Review by Claude Code

[claude]

• _check_approvals_status constructs leaders as {str(u) for u in ...} (strings) while the enforcement code in __init__.py:589 uses set(job.settings.project_leaders) (raw UserDict objects). If str(UserDict) doesn't match the approval string format, the status report could disagree with actual merge-gating.
  • Use the same type as the enforcement code, or extract leader-set construction into a shared helper.
• _build_status_report doesn't handle exceptions from clone_git_repo/build_branch_cascade. If cloning fails, the already-computed approvals status is lost.
  • Wrap the clone/cascade calls in try/except to return a partial report on failure.

Review by Claude Code

[claude]

LGTM

Approval logic in _check_approvals_status faithfully mirrors the original check_approvals gate (same early-return, same leader/peer/author counting, same unanimity check). The _has_foreign_commit extraction is functionally equivalent to the original inline code in _reset. Exception handling in the status path is appropriately defensive — broad except Exception on the clone/cascade is logged with full traceback and returns a partial report rather than crashing. Test coverage is thorough (12 new tests covering approvals, builds, Jira, history, and graceful degradation on failures).

Review by Claude Code

[claude]

LGTM

Review by Claude Code

[claude]

LGTM

The status-reporting logic in _check_approvals_status accurately mirrors check_approvals enforcement, the _has_foreign_commit extraction preserves the original algorithm, and edge cases (partial reports on clone failure, Jira unreachable, bypasses) are well handled. Test coverage is thorough across 17 new test cases.

Review by Claude Code

[eg-ayoub]

I notice that some of these checks duplicate logic found in other files, for example the check_fix_versions logic, is that intentional ?
otherwise, the implementation looks good to me.

[matthiasL-scality]

@eg-ayoub Good question — the duplication is intentional but it varies by check:

_check_fix_versions_status does not duplicate the logic. It calls the existing check_fix_versions from jira.py directly and catches the exceptions it raises to convert them into a _StatusItem. The guard conditions (Jira config presence, bypass_jira_check, disable_version_checks) are slightly mirrored at the top, but the business logic stays in one place.

_check_approvals_status does duplicate the approval logic from check_approvals in __init__.py. This is a constraint of the design: the enforcement path uses exceptions as control flow (raises on the first failure and stops), while the status report must collect all issues and return them as a single object. There is no clean way to reuse the enforcement code for reporting without a larger refactor of check_approvals — and the risk of regressions on that critical path does not seem worth it at this stage.

The _has_foreign_commit extraction is actually a reduction of duplication: the same algorithm previously lived inline in _reset, and is now shared with the history status check.