Support local CRD dependencies

[eric-carlsson]

What problem are you facing?

CRDs can be added as dependencies using a git ref or HTTP URL, but not from a local path.

How could Crossplane help solve your problem?

Add another dependency type: local, that points to a local file or directory containing CRDs. This is useful if CRDs live in the same repository as the Crossplane project.

[chaitanyapantheor]

Thanks for the feature request! Before picking this up, I have a few design questions to make sure the implementation aligns with expectations:

1. New top-level type or sub-source within crd?
   The crd dependency type already supports git and http as sub-sources. Should local be a third sub-source under crd (keeping the structure consistent), or a new top-level dependency type?

2. Path resolution — relative to what?
   Should the path be relative to crossplane-project.yaml or to the working directory at build time? Relative-to-project-file feels more portable for teams sharing the same repo.

3. File vs directory semantics
   The issue mentions "a local file or directory." For directories, should it recurse into subdirectories? Should it pick up all .yaml files, or only files that are valid CRDs?

4. crossplane dependency add CLI UX
   How would a user add a local dependency via the CLI? For example:

   • crossplane dependency add ./path/to/crds (auto-detected as a local path)?
   • crossplane dependency add --local ./path?

5. Why not spec.paths.apis?
   The project already has a spec.paths.apis field for local XRDs. Is the intent here to support third-party CRDs that are vendored locally (but not owned by this project), as opposed to the project's own APIs? Clarifying this would help scope the feature correctly.

For context, there's already an internal fsSource implementation in internal/schemas/manager/source.go that the project uses for its own apis/ directory — so local path support could reuse that infrastructure rather than starting from scratch.

[eric-carlsson]

Realized this can already be done by putting CRDs into the /apis folder. This includes them in schema generation, but since they're not xpkg compatible kinds they're excluded from the configuration. So far this works OK for us.

[adamwg]

Placing CRDs in apis/ does work as a workaround, but I don't think it's an ideal solution. The apis/ directory is intended to contain the resources that will get built into the Configuration package by crossplane project build. CRDs are ignored by crossplane project build because they're not allowed in Configurations.

I think it makes sense to add a local source for CRD dependencies, similar to the existing git and http options. To answer @chaitanyapantheor's other detail questions:

2. We should require that local CRD paths be relative to the project directory, as we do for other paths in the project file.
3. For consistency with how the git source works, I'd allow a directory to be specified and ignore any non-CRD files in the directory. The existing fsSource and generators already handle this (they handle XRDs as well, which I think is either harmless or desirable - I can imagine use-cases for vendoring XRDs from another project).
4. This is a little tricky, since local paths could parse as xpkg refs. In the long term, maybe we should make source selection explicit via a flag, but to avoid a breaking change for now I'd probably have local sources specified by starting with ./ or file://.

[github-actions]

Crossplane does not currently have enough maintainers to address every issue and pull request. This issue has been automatically marked as stale because it has had no activity in the last 90 days. It will be closed in 14 days if no further activity occurs. Leaving a comment starting with /fresh will mark this issue as not stale.

[adamwg]

/fresh