feat(recipes): add the bundled catalog rule and its three common recipes - #100
Merged
Conversation
Issue #84 asks for a reviewed candidate table before implementation. This records what is bundled, the rule that a task existing on every guest gets one recipe with a script per family, and the OS-specific candidates that remain unselected. Four of the five OS-specific candidates overlap a common recipe, which is the rule working. Only the SELinux entry stands apart. Signed-off-by: NovusEdge <novusedge0@gmail.com>
Signed-off-by: NovusEdge <novusedge0@gmail.com>
Signed-off-by: NovusEdge <novusedge0@gmail.com>
Signed-off-by: NovusEdge <novusedge0@gmail.com>
Signed-off-by: NovusEdge <novusedge0@gmail.com>
Signed-off-by: NovusEdge <novusedge0@gmail.com>
Signed-off-by: NovusEdge <novusedge0@gmail.com>
Signed-off-by: NovusEdge <novusedge0@gmail.com>
Signed-off-by: NovusEdge <novusedge0@gmail.com>
Both branches added a recipe to the same enumeration maps and to samples_test.go. The resolution keeps both entries in each map and both test functions. Signed-off-by: NovusEdge <novusedge0@gmail.com>
…check Signed-off-by: NovusEdge <novusedge0@gmail.com>
service-tools reported healthy without asking the service manager anything, and build-deps reported unhealthy on a guest that provides pkg-config only under the name pkgconf. Signed-off-by: NovusEdge <novusedge0@gmail.com>
Signed-off-by: NovusEdge <novusedge0@gmail.com>
Signed-off-by: NovusEdge <novusedge0@gmail.com>
Signed-off-by: NovusEdge <novusedge0@gmail.com>
cloud-init 25.3 keeps /run/cloud-init at mode 0700. The seeded account cannot read the run directory, so `cloud-init status --wait` never reports a result and `stoat up` waits until its caller gives up. Fedora 44 ships that version. Stoat now polls `cloud-init status` on its own deadline, and retries a probe that returns no JSON under the guest's escalation. A running cloud-init is a reason to wait rather than a failure. Signed-off-by: NovusEdge <novusedge0@gmail.com>
Signed-off-by: NovusEdge <novusedge0@gmail.com>
systemctl runs its pager even when stdout is not a terminal, and the check saw SIGPIPE as exit 141 on Fedora 44. Signed-off-by: NovusEdge <novusedge0@gmail.com>
dnf5 on Fedora names the group development-tools. dnf4 on AlmaLinux 9 and Rocky 9 names it development and fails the transaction on the other id. Signed-off-by: NovusEdge <novusedge0@gmail.com>
apt-file has no --version and exits 2 on it, so the pkg-tools health check failed on Ubuntu and Debian. Signed-off-by: NovusEdge <novusedge0@gmail.com>
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Team Run ID: 📒 Files selected for processing (28)
WalkthroughThe change adds three bundled recipes for build dependencies, service inspection, and package ownership across supported guest families. It also changes cloud-init readiness from blocking status waiting to deadline-aware polling with escalation for unreadable status data. ChangesBundled recipe catalog
Cloud-init readiness polling
Estimated code review effort: 4 (Complex) | ~45 minutes Sequence Diagram(s)sequenceDiagram
participant waitCloudInit
participant SSH
participant cloud-init
waitCloudInit->>SSH: Run cloud-init status --format json
SSH->>cloud-init: Execute status probe
cloud-init-->>SSH: Return status JSON
SSH-->>waitCloudInit: Return probe result
waitCloudInit->>SSH: Retry with sudo when needed
waitCloudInit-->>waitCloudInit: Poll until ready or deadline
Poem
✨ Finishing Touches 💡 1🛠️ Fix failing CI checks 💡
📝 Generate docstrings
🧪 Generate unit tests (beta)
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. Comment |
NovusEdge
added
recipes
This was referenced Sep 6, 2026
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.
Closes #84.
The bundled catalog had no rule for what belongs in it. This adds one, in
docs/recipes/catalog.md, and then adds the three recipes the rule admits.The rule
A task that exists on every guest gets one recipe with a script per OS family,
not one recipe per OS. A recipe earns its place by needing real OS-specific
behaviour: a package group, a pattern, or a different init system. A package
name that differs is not enough on its own. At most three OS-specific recipes
per guest, for tasks with no counterpart elsewhere.
The page also lists the OS-specific candidates the rule rejects and says why.
Four of the five overlap a common recipe. Only the SELinux entry is separate,
and it needs a decision about whether a permissive-mode VM benefits from it.
The three recipes
build-depsinstalls what building someone else's source tree needs. The RPMguests get the
@development-toolsgroup, openSUSE gets thedevel_basispattern, Arch gets
base-devel. Those three are the OS-specific behaviour therecipe exists for. Outputs:
compiler,make,pkg_config.service-toolsinstalls what inspecting a running service needs. It derivesservice_managerin the guest rather than from a package:systemctlmeanssystemd,
rc-statusmeans openrc, neither is a named failure. Outputs:service_manager,lsof,strace.pkg-toolsinstalls what querying the package manager needs beyond install andremove. Outputs:
manager,query_tool.All three run on all eight guests, declare schema 3 outputs and a health check,
and name no user account.
Four defects the live matrix found
stoat uphung on Fedora 44. cloud-init 25.3 keeps/run/cloud-initat mode0700, so the unprivileged
cloud-init status --waitnever reports a result.cloud-init finished at 19:33 in the guest and stoat was still waiting at 19:43.
Stoat now polls
cloud-init statuson its own deadline and retries a probethat returns no JSON under the guest's escalation. A running cloud-init is now
a reason to wait rather than a failure.
The
service-toolshealth check failed on Fedora with exit 141.systemctlruns its pager even when stdout is not a terminal, and the check saw SIGPIPE.
The check passes
--no-pager --no-legend.build-depsfailed on AlmaLinux 9 with "Module or Group 'development-tools' isnot available". dnf5 on Fedora names that group
development-toolsand dnf4 onAlmaLinux 9 and Rocky 9 names it
development. Asked on the guest,@developmentinstalls and@development-toolsexits 1. The RPM script asksfor the first id and falls back to the second.
The
pkg-toolshealth check failed on Ubuntu.apt-filehas no--versionand exits 2 on it. The check probes
apt-filewith--help.Live evidence
One VM per guest, three recipes selected at create, one attempt per row, every
phase retained under
catalog-recipes/live/f/.Run
f, binary sha2568ee01d14dd014d1f, built atd113453withvcs.modified=false.systemddnfrepoqueryopenrcapkapksystemdpacmanpacmansystemdapt-getapt-filesystemddnfrepoquerysystemdzypperzyppersystemddnfrepoquerysystemdapt-getapt-fileEach row created the VM, waited for it to be reachable and healthy, then
checked that the recipe outputs resolve to executables in the guest, that the
compiler builds and runs a C program, that the service manager answers a status
query, that
lsofandstracerun, that a secondapplyplans a skip for allthree recipes, and that the applied timestamps and outputs are unchanged after
it. Every row then stopped its VM and confirmed the stopped state.
Tests
Each recipe has a contract test on the manifest and a hermetic per-family test
asserting the exact package request, using the fake package managers already in
internal/recipes/samples_test.go. Every bundled-script test now runs on ahermetic PATH, so a test proves what the script does rather than what the test
host happens to have installed.
service-toolscovers both service managersand the no-manager failure.
pkg-toolscovers themanagerresolution orderfor all five package managers. The readiness change has a test for a guest
whose unprivileged probe cannot read the run directory.
Follow-up, out of scope here
Alpine's
setup-apkreposretry loop is now copied in four recipes. The sharedthing is Alpine's guest prelude
stoat_pkg_setup, which runsapk updateandis not what any recipe wants. Moving the loop there removes the exception the
Alpine scripts carry today.
🤖 Generated with Claude Code
https://claude.ai/code/session_01SXipad3xRhe72PMkoyjBiB
Summary by CodeRabbit
New Features
Bug Fixes
stoat upcloud-init readiness handling with deadline-aware polling and permission-aware retries, preventing hangs and premature failures.Documentation