Repository navigation
OSAC-1733: Consolidate fulfillment-service and osac-operator .github into root - #4
Conversation
…into root Neither component's CI ran at all after the subtree merge -- GitHub Actions only scans workflows at the repo root, and both components' .github/workflows/ were preserved as-is under their own subdirectory. - Move all workflow/script/composite-action files to root .github/, prefixed by component where they must coexist (Integration Tests, Check Floating Image Tags), deduped to one copy where they were already redundant duplicates (ok-to-test-label-cleanup, slash-command, scan-workflow-logs -- none of these were ever component-specific). - Rewrite every path filter to be prefixed with fulfillment-service/ or osac-operator/ so they match real paths in the merged tree. - Fix every job's working-directory/CWD assumptions (ginkgo, ruff, buf generate, goreleaser workdir, docker build context/file, make -C, go-version-file, hashFiles cache keys) so they actually build/lint/ test the right component's code, not the repo root. - Rework the shared setup-go composite action to accept a working-directory input, since composite action steps don't inherit a calling job's defaults.run.working-directory. - Remove fulfillment-service's and osac-operator's now-redundant pre-commit workflows/configs -- root's already covers both with correctly scoped excludes. - Merge dependabot.yml into one file with per-component gomod/docker entries. - Consolidate the two near-duplicate e2e-bmaas/vmaas workflow pairs into one each, building both components' current code together instead of testing one against the other's stale pinned image -- needs a companion osac-test-infra PR (eliorerz/osac-test-infra#283) adding two-component support to the reusable e2e workflows.
|
Warning Review limit reached
Next review available in: 13 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Repository: osac-project/coderabbit/.coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (50)
✨ Finishing Touches 💡 1🛠️ Fix failing CI checks 💡
🧪 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 |
go.work required go >= 1.26.5, an artifact of whatever toolchain was cached on the machine that ran 'go work init' -- every module's own go.mod declares go 1.26.3, and CI's setup-go composite action installs exactly that version, so the mismatch broke every Go job in CI.
…licating jobs check-floating-tags, check-generated-code (buf generate), and helm-lint were the same steps for both components, just a different directory -- matrix them into one job each instead of one file/job per component, so adding osac-aap/osac-installer/bare-metal-fulfillment-operator later is a matrix entry, not a new file. Also adds fulfillment-service's chart to helm-lint, which had no lint coverage at all before this. Left per-component lint/test jobs that use genuinely different toolchains (fulfillment-service's ruff/buf-lint/ginkgo vs osac-operator's golangci-lint/Makefile/Kind) and the image-build workflows (whose exact per-component conclusion gates the tag-triggered chart-publish workflow_run) unmerged -- matrixing those would either add real conditional complexity for no shared logic, or entangle release-path signaling between components. Revisit at OSAC-1734.
|
Follow-up commit: matrixed the three identical-shape per-component checks ( |
|
Follow-up: dropped component-name prefixes and merged the two cases where they existed only to avoid a collision (Integration Tests, Publish charts) into one file each. Everything else that never actually collided got its prefix stripped and filename reverted to the original name. Also reverted fulfillment-service from helm-lint.yaml -- its chart can't be linted bare (guards most values with |
…o one Merged Integration Tests and Publish charts into one workflow file each (they were the two cases where the prefix existed only to avoid a name collision between otherwise-identical-concept workflows) -- each keeps separate per-component jobs/steps since the underlying work differs, but there's exactly one 'Integration Tests' and one 'Publish charts' workflow now, gated on component paths / which producer's workflow_run fired, respectively. Stripped the component prefix entirely from the remaining solo workflows (Check pull request, Unit Tests, Publish binaries, Container image, Build container image, Publish OpenAPI, Publish proto) and reverted their filenames to the original unprefixed names, since none of them ever actually collided with another component's workflow -- the prefix was unnecessary duplication of what the (already unique) name already said. Reverted fulfillment-service's chart from helm-lint.yaml: it guards most values with required(...), so it can't be linted with bare values.yaml the way osac-operator's charts can -- needs a CI-only dummy-values file first (tracked separately, not blocking this PR).
…tted IDE config, rewrite README - Merge fulfillment-service's and osac-operator's .gitignore into one root .gitignore, prefixing component-relative patterns with their new subdirectory path and deduping generic entries (.idea, .vscode, etc.). - Consolidate LICENSE: all three copies are Apache 2.0; the root copy had a stale 'Innabox Project Contributors' copyright line (a prior project name) where both merged components correctly said 'OSAC Project Contributors' -- fixed the root copy to match and removed the two duplicates. Remove fulfillment-service/.idea/ and fulfillment-service/.vscode/, which were accidentally committed local IDE config, not project code. - Rewrite the root README from its bare skeleton into a real mono-repo orientation doc describing both components and the go.work workspace setup, linking to each component's own README for details.
60d17c8 to
10aa635
Compare
**New Controller Implementation** (`internal/controller/baremetalpool_controller.go`) - Reconciles BareMetalPool CRs to maintain desired HostLease replica counts per host type - Handles finalizer-based cleanup during BareMetalPool deletion - Scales up by creating new HostLeases with proper ownership and labels - Removes all HostLeases when host types are removed from spec - Updates status conditions and host set counts **Test Coverage** (`internal/controller/baremetalpool_controller_test.go`) - Tests finalizer addition, replica scaling, multi-class management - Validates owner references, labels, and status updates - Confirms proper cleanup on deletion **Integration** - Registered controller in `cmd/main.go` - Added helper functions and common variables used across packages - Added RBAC permissions for hostleases (create, delete, get, list, watch) - Updated PROJECT file to mark controller as enabled - Added k8s.io/api as direct dependency (was indirect) - Updated kustomization with proper API version and image configuration Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com> Closes osac-project/issues#373
…ions/setup-python-7 NO-ISSUE: Bump actions/setup-python from 6 to 7
1 participant
Summary
After the subtree merge (#3), neither fulfillment-service's nor osac-operator's CI was actually running: GitHub Actions only scans workflows at the repo root, and the merge preserved each component's
.github/exactly where it was, under its own subdirectory. This PR moves everything to root and fixes it up so it actually works against the merged tree..github/, prefixed by component where they must coexist (Integration Tests,Check Floating Image Tags-- these are genuinely different per component), deduped to one copy where they were already redundant (ok-to-test-label-cleanup,slash-command,scan-workflow-logs-- none of these were ever component-specific; keeping two would have double-run the same bot logic on every PR/comment).paths:/paths-ignore:filter to be prefixed withfulfillment-service/orosac-operator/so they match real paths in the merged tree instead of firing on any change anywhere in the repo.ginkgo run,ruff,buf generate,goreleaser workdir,docker buildcontext/file,make -C,go-version-file,hashFilescache keys -- so they actually build/lint/test the right component's code, not the repo root.setup-gocomposite action to accept aworking-directoryinput, since composite action steps don't inherit a calling job'sdefaults.run.working-directory.dependabot.ymlinto one file with per-componentgomod/dockerentries.e2e-bmaas/e2e-vmaasworkflow pairs into one each, building both components' current code together instead of testing one against the other's stale pinned image -- this is the actual bug the mono-repo is supposed to fix. Needs the companionosac-test-infraPR below.Dependency
Requires osac-project/osac-test-infra#283 (adding two-component build support to the reusable e2e workflows) to land first, or the new
e2e-bmaas-full-install.yml/e2e-vmaas-full-install.ymlhere will fail on the unrecognizedcomponent2-*inputs.Deliberately out of scope
Per OSAC-1734/OSAC-3227: no workflow here is a required branch-protection check, and none of the path filters use
dorny/paths-filter-style skip logic yet -- both are intentionally deferred until the full path-based CI matrix lands (after osac-aap/osac-installer also merge).Verification
python -c "import yaml; yaml.safe_load(...)"over every touched file -- all valid.pre-commit run --all-filespasses clean.name:/workflow_run.workflows:pair to confirm producer/consumer names match exactly, and thatscan-workflow-logs.yml's watched names match the new consolidated e2e workflow names.