Merge master into next - #305
Merged
Merged
Conversation
Brings the Ruckus/Brocade FastIron (ICX) driver (#304) onto next and adapts it to the structures next introduced after master branched. Conflict resolutions: - Registry: next moved the platform-to-driver map out of constructors.py into registry.py, so RUCKUS_FASTIRON is registered there instead. - Docs: next replaced docs/user/drivers.md with docs/admin/platforms.md, so the FastIron section and the platform table row moved there. The code example uses the v4 constructor names the rest of the page uses. docs/index.md on next carries no platform table, so master's row is dropped rather than re-added. - Tests: next split tests into tests/unit/ and tests/integration/, so the driver scenarios moved to tests/integration/test_ruckus_fastiron.py, the fixtures to tests/integration/fixtures/, and their conftest fixtures to tests/integration/conftest.py. The test now calls the v4 names (HConfig.from_text, remediation, to_lines) like every other integration test. - v3 baseline: v3_scenarios.py enumerated every Platform member, so a platform v4 adds after v3.7.0 broke the frozen recording. The scenario now iterates a frozen list of the platforms v3 declares, because a v4 platform has no v3 mapping to compare against.
The driver landed on master before v4 merged the three negation rule lists into one, so it configured `negate_with` and `negation_sub`. On next those two are the permanent v3 compatibility surface, kept for users who wrote against v3; every other built-in driver declares its negation through the unified `negation` list. `all_negation_rules()` resolves both spellings, so behaviour is unchanged and the driver's tests pass as written.
uv refuses both at once ("the argument `UV_LOCKED` cannot be used with
`UV_FROZEN`"), so `uv sync` exited 2 and the review never ran. Every
earlier run of this workflow was skipped, because the pull requests were
drafts or came from forks, so nothing caught it.
The job-level UV_FROZEN already stops the agent's `uv run` calls from
rewriting uv.lock, which is what the setting is there for.
build-and-test.yml keeps UV_LOCKED and asserts the lock is current on
every push, so that check is not lost.
The driver recorded every device-enforced dependency as a `#` comment beside the rule it explains. The reasons belong in the docstring of the function that holds the rules, where a reader finds them from the class and where `help()` shows them. `_instantiate_rules()` now carries the ordering rationale as a list, one item per dependency, and the remaining platform facts under it. One comment pointed at `docs/user/drivers.md`, which this branch replaced with `docs/admin/platforms.md`.
jtdub
force-pushed
the
sync-master-into-next
branch
from
September 20, 2026 03:42
d0fec3c to
56b8dd1
Compare
The Rust rewrite moved the Python version to `dynamic` and sourced it from `[workspace.package] version`, which it set to `4.0.0-beta.4`. Every earlier release of this line spelled the version `4.0.0bN`, and the tags follow the same spelling. Cargo requires semver, so the closest spelling is `4.0.0-b4`. PEP 440 normalizes it to `4.0.0b4`, which is what the wheel and `uv sync` now report.
The driver arrived from master before the Rust core landed on next, so it existed only in Python. Adding `RUCKUS_FASTIRON` to the Python `Platform` enum on its own breaks VyOS: the enum uses `auto()`, so its members are numbered by position, the PyO3 bindings parse a member's value, and the core mapped "13" to VyOS and rejected "14". Every `HConfig.from_text(Platform.VYOS, ...)` call would raise `unsupported driver.platform: "14"`. Add the `RuckusFastiron` variant in the position the Python enum gives it and renumber VyOS to "14", so the two enums stay aligned. `FromStr` now documents that contract, because the next platform added to the middle of the Python enum hits the same trap. Move the driver rules into `crates/hier_config_core/src/platforms/ ruckus_fastiron/rules.json`. The core's embedded JSON is the single source of truth for a built-in platform, and `test_all_14_platforms_load_rules_via_ rust_and_python` asserts the driver's rules match it, so the rules cannot stay as a Python literal. `_instantiate_rules()` now calls `load_platform_rules()` and keeps only the four post-load callbacks, which the core does not own and `hier_config.constructors` still runs in Python. Cover the platform the way the others are covered: a driver test for the prefixes, the single-space indentation, the prompt-echo stripping, the LAG regex negation and the ACL ordering, plus four corpus cases that the property tests need.
`maturin develop` installs the project dependencies before it builds, and it passes the PEP 735 `--group` flag to do so. Its default installer is the pip inside `.venv`, which the job seeds with `python -m venv`. That pip is older than 25.1, so it answers "no such option: --group" and maturin exits 1 before the review agent ever starts. `--uv` makes maturin install with uv, which the job already uses for everything else, so the venv's pip version stops mattering. build-and-test.yml avoids the same failure by upgrading pip first. This job has no pip step to hang that on.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Closes: DNE
Merges
masterintonext.mastercarries one commit thatnextdoes not have: the Ruckus/Brocade FastIron (ICX) driver (#304). The merge conflicts becausenextreorganized the docs, the tests, and the driver registry aftermasterbranched, so the FastIron change is re-landed on those structures.Library
RUCKUS_FASTIRONinhier_config/registry.py.nextmoved the platform-to-driver map out ofconstructors.py, so the entry goes there, keyed onPlatform.RUCKUS_FASTIRON.name.HConfigDriverRuckusFastIronto the unifiednegationrule list. It declarednegate_withandnegation_sub, which onnextare the permanent v3 compatibility surface. Every other built-in driver usesnegation.all_negation_rules()resolves both, so behavior does not change.Docs
docs/admin/platforms.md.nextreplaceddocs/user/drivers.mdwith that page, andmkdocs.ymlalready redirects the old path.HConfig.from_text()andremediation()in the section's example, matching the rest of the page.master's platform table row fordocs/index.md: that page carries no table onnext.Tests
tests/integration/test_ruckus_fastiron.py, the four config fixtures totests/integration/fixtures/, and their accessors totests/integration/conftest.py.HConfig.from_text(),remediation(), andto_lines(), the idiom every other integration test uses.tests/integration/v3_scenarios.py. Thev3_platform_to_v2_osscenario enumerated everyPlatformmember, so any platform added after v3.7.0 broke the committed v3 baseline. A v4-only platform has no v3 mapping to compare against.CI
.github/workflows/claude-review.ymlsetUV_FROZENon the job andUV_LOCKEDon the install step. uv refuses both together, souv syncexited 2 and the review job failed. Every earlier run was skipped, for draft or fork pull requests, so nothing caught it. The job-levelUV_FROZENis what stops the agent rewritinguv.lock, so the step-levelUV_LOCKEDis removed.build-and-test.ymlstill asserts the lock is current on every push.Test plan
uv run ./scripts/build.py lint-and-testexits 0. Coverage is 97.58%, above the 95% floor. The FastIron driver and its functions module are at 100%.uv run mkdocs build --strictexits 0.tests/integration/test_ruckus_fastiron.pypasses all 56 tests, including both round trips against the ICX 6450 and ICX 6650 fixtures.tests/integration/test_v3_baseline.pypasses against the committed v3.7.0 recording.Note on the
reviewcheck:claude-code-actionrequires the workflow file to match the copy on the default branch, which ismaster.nextconverted the workflow from poetry to uv in #301, so the two differ and the action skips itself. The job reports success. The review runs again oncenextreachesmaster.Self-Review Checklist
uv run ./scripts/build.py lint-and-testpasses locally (lint + 95% test coverage).CHANGELOG.mdhas an entry under## [Unreleased]referencing this issue/PR ((#NNN)).mkdocs build --strictpasses if docs were touched).AI-Assisted Contributions
Written with Claude Code and reviewed with the
hier-config-reviewskill.