What
nifi-operator hit two consecutive bugs in release.yml's chart-lint-helm job
during 0.4.0-dev, fixed in nifi-operator#95 and #96. Those fixes landed only in
nifi. The same latent defects remain in the other 14 repositories.
Verified against each repo's main:
| Repo | || true guard | ROOT_COMMIT | Status |
|---|---|---|---|
| nifi-operator | 2 | 2 | fixed |
| doris-operator | 2 | 0 | partial — has the guard, missing since_commit |
| the other 13 | 0 | 0 | both bugs present |
The two bugs
1. The first-release branch is unreachable (nifi#95)
PREVIOUS_TAG=$(git tag --sort=-v:refname | grep -A1 "^${CURRENT_TAG}$" | tail -n1 | grep -v '\-dev$')
The step runs under bash -e. When the tag being released is the only tag in
the repo, the trailing grep -v matches nothing, exits 1, and kills the step —
before the "First release detected" branch a few lines below can run. The branch
written for exactly this case is unreachable precisely when it is needed.
2. The first-release branch sets no since_commit (nifi#96)
Once reachable, it sets changed and target_branch but not since_commit.
Every step below passes that through to ct, so the next one runs
ct list-changed --since "" --target-branch main and dies with git exit 128.
Why this is not urgent but should not be left
Neither bug fires for a repo that already has stable tags — the grep -v finds a
previous release and the first-release branch is never entered. All 14 repos are
in that state today, which is why 0.4.0 shipped fine.
It fires for a repo whose only tag is the one being released. That is any new
operator's first release. dolphinscheduler-operator came close this cycle: it
had 0.1.0/0.2.0 from earlier work, so the lookup found something. A genuinely
new operator would have hit both bugs in sequence, exactly as nifi did — and each
only becomes visible after the previous one is fixed.
Suggested fix
Port nifi's two changes to the remaining 14 repos:
PREVIOUS_TAG=$(... | grep -v '\-dev$' || true)
and in the first-release branch:
ROOT_COMMIT=$(git rev-list --max-parents=0 HEAD | tail -n1)
echo "since_commit=$ROOT_COMMIT" >> "$GITHUB_OUTPUT"
See nifi-operator#95 and #96 for the reasoning and verification.
Context
Found during the 0.4.0 release. Filed rather than fixed inline because it affects
no current release path — but it is a guaranteed trap for the next new operator.
🤖 Generated with Claude Code
What
nifi-operator hit two consecutive bugs in
release.yml'schart-lint-helmjobduring 0.4.0-dev, fixed in nifi-operator#95 and #96. Those fixes landed only in
nifi. The same latent defects remain in the other 14 repositories.
Verified against each repo's
main:| Repo |
|| trueguard |ROOT_COMMIT| Status ||---|---|---|---|
| nifi-operator | 2 | 2 | fixed |
| doris-operator | 2 | 0 | partial — has the guard, missing since_commit |
| the other 13 | 0 | 0 | both bugs present |
The two bugs
1. The first-release branch is unreachable (nifi#95)
PREVIOUS_TAG=$(git tag --sort=-v:refname | grep -A1 "^${CURRENT_TAG}$" | tail -n1 | grep -v '\-dev$')The step runs under
bash -e. When the tag being released is the only tag inthe repo, the trailing
grep -vmatches nothing, exits 1, and kills the step —before the "First release detected" branch a few lines below can run. The branch
written for exactly this case is unreachable precisely when it is needed.
2. The first-release branch sets no
since_commit(nifi#96)Once reachable, it sets
changedandtarget_branchbut notsince_commit.Every step below passes that through to ct, so the next one runs
ct list-changed --since "" --target-branch mainand dies with git exit 128.Why this is not urgent but should not be left
Neither bug fires for a repo that already has stable tags — the
grep -vfinds aprevious release and the first-release branch is never entered. All 14 repos are
in that state today, which is why 0.4.0 shipped fine.
It fires for a repo whose only tag is the one being released. That is any new
operator's first release. dolphinscheduler-operator came close this cycle: it
had
0.1.0/0.2.0from earlier work, so the lookup found something. A genuinelynew operator would have hit both bugs in sequence, exactly as nifi did — and each
only becomes visible after the previous one is fixed.
Suggested fix
Port nifi's two changes to the remaining 14 repos:
PREVIOUS_TAG=$(... | grep -v '\-dev$' || true)and in the first-release branch:
See nifi-operator#95 and #96 for the reasoning and verification.
Context
Found during the 0.4.0 release. Filed rather than fixed inline because it affects
no current release path — but it is a guaranteed trap for the next new operator.
🤖 Generated with Claude Code