Releases · scality/bert-e

Fix NEVER_REPEAT bypassing history check in _send_comment

`if dont_repeat_if_in_history:` treats None as falsy, so
InformationExceptions with dont_repeat_if_in_history=NEVER_REPEAT=None
skip the duplicate check and post on every evaluation cycle.  Each new
comment triggers a webhook that re-triggers bert-e, causing an infinite
loop.

Assets 2

15 Apr 10:19

charlesprost

4.0.0-beta.15

a2cc82a

4.0.0-beta.15 Pre-release

Pre-release

● ## Pre-GA hotfix branch support

This branch teaches bert-e to handle hotfix/X.Y.Z branches that are created before the GA
tag exists — a workflow where a hotfix branch is cut from a development branch early to receive a
patch series, with the waterflow continuing on a different development branch.

The problem

When hotfix/10.0.0 is created before the 10.0.0.0 GA tag is published, bert-e had no concept
of a "pre-GA hotfix." Three concrete bugs resulted:

Wrong queue branch name — the queue integration branch was named q/w/PR/10.0.0.-1/...
because HotfixBranch.hfrev defaulted to -1. The PR could never be found or merged.
Wrong target version for development branches — development/10 kept targeting 10.0.0
instead of 10.1.0, because the hotfix branch was invisible to the cascade version calculation.
Re-queuing after GA tag — once the 10.0.0.0 tag was pushed and hfrev advanced from 0
to 1, already_in_queue would compute a new queue name (10.0.0.1) that didn't exist and
re-queue the already-queued PR.

What changed

Core cascade logic (`branches.py`, `queueing.py`)

HotfixBranch.hfrev now defaults to 0 (pre-GA) instead of -1. version is initialised to
X.Y.Z.0. update_versions already advances hfrev past any existing tag, so post-GA
behaviour is preserved.
For PRs targeting a development branch, hotfix branches are stored as phantom entries in
the cascade. This lets _update_major_versions see minor=0 from hotfix/10.0.0 and produce
the correct target 10.1.0 for development/10 without hotfix ever appearing as a merge
destination.
get_queue_integration_branch uses isinstance(dst, HotfixBranch) (was hfrev > 0) so pre-GA
hotfix PRs get the correct q/w/PR/10.0.0.0/... queue name.
already_in_queue falls back to a git branch -r --list origin/q/w/{id}/X.Y.Z.* prefix scan
after the exact-match lookup, so a PR queued pre-GA is still found after hfrev advances.
Phantom hotfix entries are updated by update_versions so their hfrev/version stay fresh
when a GA tag arrives.

Jira fix-version check (`jira.py`)

The new workflow requires tickets to carry three fix versions simultaneously, e.g. 9.5.3 +
10.0.0.0 + 10.1.0. The rules are:

Hotfix branch PRs must carry the exact 4-digit target version (10.0.0.0 pre-GA, 10.0.0.1
post-GA first hotfix, …). 3-digit aliases are rejected.
Development branch PRs strip any phantom hotfix version (10.0.0.0) from the check before
comparing against expected versions, so the dev PR can pass alongside the hotfix entry.
When the ticket contains a X.Y.Z.0 phantom hotfix version, bert-e posts a one-time
informational comment (code 223, PendingHotfixVersionReminder, never repeats) reminding the
developer to open a cherry-pick PR to the hotfix branch.

User-facing messages (`queued.md`, `successful_merge.md`)

Both the "In the queue" and "Successfully merged" comments now include a warning block listing any
hotfix branches that need a separate cherry-pick PR, when applicable.

Housekeeping

create_branch.py: skip the archive-tag check for hotfix branches (their tags use a different
format) and fix the branch_from base version to avoid double .0.
pipes.quote → shlex.quote (deprecated since Python 3.3).
Fast-forward merges enforced in local clones regardless of the host git config (merge.ff).

Tests

Test	What it covers
`test_pr_hotfix_pre_ga`	End-to-end: PR to `hotfix/10.0.0` pre-GA queues under `10.0.0.0`, builds, merges
`test_pr_hotfix_no_requeue_after_ga`	GA tag push does not re-queue an already-queued PR
`test_dev_pr_reminder_about_pre_ga_hotfix`	Dev-branch PR gets the hotfix cherry-pick reminder
`test_branch_cascade_dev_with_pre_ga_hotfix`	`development/10` targets `10.1.0` when `hotfix/10.0.0` exists pre-GA
`test_phantom_hotfix_hfrev_updated_by_ga_tag`	Phantom hfrev advances when GA tag arrives
`test_branch_cascade_target_hotfix` (extended)	Pre-GA case: no `6.6.6.X` tag → target version `6.6.6.0`
`test_queueing.py` (new unit test)	`isinstance` guard prevents dev branches with `hfrev=0` from using hotfix queue name
`test_jira.py` (14 unit tests)	Pre/post-GA acceptance, 3-digit rejection, phantom exclusion for dev PRs