feat(nix): Finish control plane setup and surface failures in the nix run app - #375
Merged
Merged
Conversation
Signed-off-by: Christopher Haar <christopher.haar@upbound.io>
negz
approved these changes
Jul 31, 2026
negz
left a comment
Collaborator
There was a problem hiding this comment.
Thanks for fixing this! I'd been meaning to do it myself.
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
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.
Description of your changes
The nix run app started a control plane with
crossplane project runand stopped there, which left it in a state that doesn't match what the getting-started guide produces. The prerequisites manifest, the modelplane-system namespace, composition RBAC, and provider-helm's DeploymentRuntimeConfig and ImageConfig, was never applied, so compositions that rely on that RBAC fail. Now the app appliesdocs/manifests/getting-started/prerequisites.yamlonce the control plane is healthy.Applying the manifest alone isn't enough for provider-helm, though:
crossplane project runinstalls providers before the prerequisites exist, and Crossplane resolves ImageConfig runtime configs only at ProviderRevision creation. provider-helm therefore always comes up on the default runtime config, whose ServiceAccount lacks the RBAC granted above. The app now patches the provider'sspec.runtimeConfigRefto point atprovider-helm-modelplaneexplicitly, so it runs with the intended ServiceAccount regardless of install order.Failures were also effectively undebuggable under nix.sh: installs that time out report only "context deadline exceeded", and the kind cluster lives inside the container's Docker daemon, so it's gone before anyone can inspect it. On failure the app now exports the kind kubeconfig and dumps
kubectl get pkgrev(plus the full YAML) before dropping into the dev shell, and it propagates the failure as its exit code instead of swallowing it. The default--timeoutis also raised from the CLI's 5m to 15m, since first-time image pulls through the Docker-in-Docker daemon regularly exceed 5m; an explicit--timeouton the command line still wins.Fixes #
I have:
nix flake check(or./nix.sh flake check) and made sure it passes.git commit -s.