[ALI88708]

No description provided.

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

• Configuration used: Repository UI
• Review profile: CHILL
• Plan: Advanced
• Run ID: a2f6e93a-4cf2-4c4d-b33c-66c74f261325

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Add Carrot credits or activate Agent usage billing to use Autofix

[coderabbitai]

This pull request was merged because it matched the criteria for the rule CloudMesh Engineering Rules (Triage Rules).

[ALI88708]

FreeBSD gate: found and fixed before the LTS could claim it

docs/LTS.md makes the BSD VM part of the release gate — "a green full suite
on Windows, Linux, and the BSD VM" — but the FreeBSD workflow only ever
triggered on feature/bsd-support. No released commit had ever been checked
on FreeBSD: the policy was satisfied by assertion, not by a green run.

Turning the gate on for the released tag found two things, one of them a real
defect in the gate itself.

1. The E2E script had a version frozen in it

The first FreeBSD run of the released tag failed:

1067 passed, 46 skipped in 51.71s          <- the pytest suite was green
==== Phase 1/4: controller
[E2E] $ python3 -m pip install -q -e .
CloudMesh 4.1.2
[E2E] FAILED: cm --version did not report 4.0.0

scripts/bsd_e2e.sh asserted that cm --version reports 4.0.0 — a number
written when the BSD support branch was cut. The released code was fine; the
check was stale, and it had been failing on every version bump since, which
is exactly how a gate stops being a gate.

The expected version is now read from pyproject.toml, so the check follows
the release instead of contradicting it.

2. The gate never ran on the branches that ship

bsd.yml now triggers on main and release/**, and on pull requests
targeting them, so a FreeBSD break is caught before it lands rather than
after.

Result on the released tag

BSD / v4.1.2 / workflow_dispatch   ->  success
  1069 passed, 46 skipped in 32.48s
  [OK] cm --version
  Phase 2/4: node installer and rc.d
  Phase 3/4: loopback agent
  Phase 4/4: SSH server path
  BSD E2E OK

Two regression tests keep both in place: the trigger has to cover the
branches that carry released code, and the E2E script must not carry a
version number of its own.

Release state after the fix

Tag	v4.1.2 -> b4bf73e (= main)
Release	"CloudMesh 4.1.2 LTS"
Assets	wheel, sdist, SHA256SUMS, sbom.cdx.json
sha256sum -c SHA256SUMS	OK for both artifacts
python -m zipfile -t on the wheel	Done testing
pip install of the published wheel	cm --version -> CloudMesh 4.1.2
cm update --pip verification path	VERIFIED
gh attestation verify	exit 0
CI on main (Windows + Linux, 3.11/3.12/3.13)	green
BSD gate on the tag	green — BSD E2E OK
Local suite	1071 passed, 44 skipped

The tag was re-cut onto the commit that carries these fixes, and the assets,
the checksum file and the provenance attestation were regenerated and
re-verified.

The one thing left open

gh api -X PATCH .../releases/<id> -F immutable=true is accepted but has no
effect: immutable releases are a repository setting that this API surface
does not expose. Enabling it under Settings -> General -> Releases would
freeze the artifacts above against replacement.