Support local CRD dependencies #93

Activity

1. eric-carlsson

   added

   enhancementNew feature or requestNew feature or request

   on Jun 9, 2026
2. chaitanyapantheor commented on Jun 13, 2026

   

   chaitanyapantheor

   on Jun 13, 2026

   Contributor

   More actions

   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.
3. eric-carlsson commented on Jun 18, 2026

   

   eric-carlsson

   on Jun 18, 2026

   Last edited by eric-carlsson

   ContributorAuthor

   More actions

   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.
4. adamwg commented on Jun 18, 2026

   

   adamwg

   on Jun 18, 2026

   Member

   More actions

   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://.

   👍React with 👍1Reacted by Eric Carlsson
5. github-actions commented on Sep 17, 2026

   

   github-actionsBot

   on Sep 17, 2026 – with GitHub Actions

   More 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.
6. github-actions

   added

   stale

   on Sep 17, 2026
7. github-actions

   closed this as not plannedon Oct 1, 2026
8. adamwg commented on Oct 1, 2026

   

   adamwg

   on Oct 1, 2026

   Member

   More actions

   /fresh

   👀React with 👀1Reacted by github-actions
9. adamwg

   reopened this on Oct 1, 2026
10. github-actions

    removed

    stale

    on Oct 1, 2026
11. stevendborrelli commented on Oct 15, 2026

    

    stevendborrelli

    on Oct 15, 2026

    Member

    More actions

    I've been thinking with the changes in #430 we can add local or crds as a new source. We already will have sha256 hashing, caching, lock files so it won't be much of a lift to add a new source.

    "groups": {
      "dependencies": {
        "fs://vendor/crds": "sha256:...",
        "xpkg://xpkg.upbound.io/upbound/provider-helm:v1.4.0": "sha256:..."
      }
    }