[session 2] docs(platform.ci-cd): back-merge main into develop before cutting a release #46

2026-07-20T10:12:14-04:00

hiveiq commented

2026-07-20 10:12:14 -04:00

Session: 2

Why

A hotfix merged straight to main is not in develop. Nothing warns you the branches have diverged — the bill arrives at the next release, as a conflict on the prod branch.

hiveops-remote, 2026-07-20. main had 5 commits develop had never seen (OWASP suppressions #17, jackson-bom fix #16, jackson bump #14, cd-main rework #12, sonar-pr removal #15) against develop's 9, including the hiveops-bom 1.0.2 → 1.0.8 bumps. Both sides had fixed the same jackson/spring/tomcat CVEs by different routes — main suppressed them, develop bumped the BOM — so develop → main conflicted in pom.xml with main's hotfixes at risk of being clobbered by an older develop state.

Resolved via back-merge first (hiveops-remote#18, merged); main-not-in-develop is now 0.

What

New section in platform.ci-cd, placed after Branch lifecycle (same family of trap):

The two read-only probes — git rev-list --count origin/develop..origin/main and git merge-tree --write-tree exit code — to run before assuming a release is clean
The back-merge-first ordering as a table (resolve on develop where CI validates and nothing is prod-bound, then cut the release)
Why resolving a divergence inside the release PR is the wrong place: unreviewed merge resolution landing on the branch production builds from, where a wrong --ours/--theirs silently reverts a shipped hotfix
The second-order effect: hotfixes bypassing the develop PR flow lose their issue paperwork. hiveops-agent#62, hiveops-bom#6 and hiveops-devices#55/#60 all sat open with a shipped fix, no Verify Fix and no milestone.

Docs only — one file, 37 lines added, no code or schema changes.

Refs hiveops-remote#18, hiveops-bom#6, hiveops-agent#62.

Session: 2 ## Why A hotfix merged straight to `main` is not in `develop`. Nothing warns you the branches have diverged — the bill arrives at the next release, as a **conflict on the prod branch**. **`hiveops-remote`, 2026-07-20.** `main` had 5 commits `develop` had never seen (OWASP suppressions #17, jackson-bom fix #16, jackson bump #14, cd-main rework #12, sonar-pr removal #15) against `develop`'s 9, including the `hiveops-bom` 1.0.2 → 1.0.8 bumps. Both sides had fixed **the same** jackson/spring/tomcat CVEs by different routes — `main` suppressed them, `develop` bumped the BOM — so `develop → main` conflicted in `pom.xml` with `main`'s hotfixes at risk of being clobbered by an older `develop` state. Resolved via back-merge first (hiveops-remote#18, merged); `main`-not-in-`develop` is now 0. ## What New section in `platform.ci-cd`, placed after **Branch lifecycle** (same family of trap): - The two **read-only probes** — `git rev-list --count origin/develop..origin/main` and `git merge-tree --write-tree` exit code — to run *before* assuming a release is clean - The back-merge-first ordering as a table (resolve on `develop` where CI validates and nothing is prod-bound, then cut the release) - Why resolving a divergence **inside** the release PR is the wrong place: unreviewed merge resolution landing on the branch production builds from, where a wrong `--ours`/`--theirs` silently reverts a shipped hotfix - The second-order effect: hotfixes bypassing the `develop` PR flow **lose their issue paperwork**. `hiveops-agent#62`, `hiveops-bom#6` and `hiveops-devices#55`/`#60` all sat open with a shipped fix, no `Verify Fix` and no milestone. Docs only — one file, 37 lines added, no code or schema changes. Refs hiveops-remote#18, hiveops-bom#6, hiveops-agent#62.

hiveiq added 1 commit 2026-07-20 10:12:14 -04:00

docs(platform.ci-cd): back-merge main into develop before cutting a release e4b894a848

Hotfixes merged straight to `main` are not in `develop`. Nothing warns you
they have diverged; the bill arrives at the next release, as a conflict on
the prod branch.

hiveops-remote hit this on 2026-07-20: main had 5 commits develop had never
seen (OWASP suppressions, jackson-bom fix, jackson bump, cd-main rework,
sonar-pr removal) against develop's 9 including the hiveops-bom 1.0.2 -> 1.0.8
bumps. Both sides had fixed the SAME jackson/spring/tomcat CVEs by different
routes — main suppressed, develop bumped — so develop -> main conflicted in
pom.xml with main's hotfixes at risk of being clobbered.

Documents the two read-only probes (rev-list count, merge-tree exit code),
the back-merge-first ordering, and why resolving a divergence inside the
release PR is the wrong place for it.

Also records the second-order effect: hotfixes that bypass the develop PR
flow lose their issue paperwork. agent#62, bom#6 and devices#55/#60 all sat
open with a shipped fix, no Verify Fix label and no milestone.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

johannes approved these changes 2026-07-20 10:13:00 -04:00

hiveiq merged commit fb352c01d2 into develop

2026-07-20 10:14:21 -04:00

hiveiq deleted branch docs/backmerge-before-release

2026-07-20 10:14:21 -04:00

hiveiq referenced this issue from a commit

2026-07-25 18:05:52 -04:00

docs(agent-proxy): agent token validation resilience (#30, #46, #48)

hiveiq referenced this pull request

2026-07-25 18:05:52 -04:00

[session 2] docs(agent-proxy): agent token validation resilience (#30, #46, #48) #67

hiveiq referenced this issue from a commit