crossplane-contrib/crossplane-lint

crossplane-lint's Issues

Linter should not fail on missing claimNames for XRDs that are designed to be XR only

I've tried to execute linter against https://github.com/upbound/platform-ref-aws/ and got the following feedback

dist/crossplane-lint_linux_amd64_v1/crossplane-lint package -f /home/xnull/upbound/platform-ref-aws/package
crossplane-lint: error: failed to register package schemas: failed to build claim CRD: invalid resource claim names: missing names

Related code: https://github.com/crossplane-contrib/crossplane-lint/blob/main/internal/xpkg/lint/schema/xcrd.go#L191-L194

Apparently linter is very opinionated in the expectation that every XRD should have associated Claim and inherently claimNames.

At the same time XR-only XRDs without claimNames defined are totally valid scenario for the cases like

• https://github.com/upbound/platform-ref-aws/tree/main/package/cluster/network XRD which is designed to be non-namespaced and cluster-wide
• https://github.com/upbound/platform-ref-aws/blob/main/package/cluster/eks/definition.yaml which acts as a nested XR and eventually used in higher-level Composition https://github.com/upbound/platform-ref-aws/blob/main/package/cluster/composition.yaml

Integrate with crd-schema-checker

This issue is for awareness. @deads2k prototyped https://github.com/openshift/crd-schema-checker for the OpenShift use-case, but conversations are ongoing to promote that to an effort of Kubernetes Sig-API-Machinery. Likely, CRD schema checking would be a great addition to crossplane-lint, and integrating via vendoring would be great. Also experience from the Crossplane community would benefit crd-schema-checker.

Suggested rules

Thanks for building this - I expect it will be very useful.

What do you think about having the linter warn if folks aren't following "best practices"? These aren't things that would break a Configuration or Composition, but they are things that make them more readable, and in some cases "future proof" them.

The two examples that immediately come to mind are:

• Warn if any entries in the resources array are missing a name field. When this is the case Composition operates in a kind of "legacy mode". It can't support deleting or reordering entries in the resources array, and can't support Composition Functions.
• Warn if any type field is missing. This is mostly a readability thing - we introduced a couple of type fields as optional when they probably should have been required. I think writing the type out each time makes it more obvious what the Composition is doing.

only download the layer io.crossplane.xpkg: base

Currently, when including a provider package in .crossplane-lint.yaml all the OCI image layers are downloaded from the registry, including the go binary of the respective provider. However we are just interested in the CRDs so that we can validate the compositions against them.

Following the xpkg specification we should be able to look at the OCI manifest and download only the image with the annotation "io.crossplane.xpkg": "base". It contains a package.yaml with the yaml stream.

Here is a live example. Click on the digest to dive deeper:
https://explore.ggcr.dev/?image=crossplanecontrib/provider-gitlab@sha256:3dd3d5b6f0fe600a2b43adbcf0e2ce289aff3838ffcab43e98ee37e9a231654b&mt=application%2Fvnd.docker.distribution.manifest.v2%2Bjson&size=1006

ignore well-known crossplane fields

Given the following input:

- fromFieldPath: "metadata.uid"
  toFieldPath: "spec.writeConnectionSecretToRef.name"
  transforms:
    - type: string
      string:
        fmt: "%s-sql" #change

The linter spots an error because it can't find metadata.uid in the XRD.

The linter should know about the well-known fields, e.g. https://github.com/crossplane/crossplane/blob/4e4f57a80dc19d24bb712acaa853a836b6963dc9/internal/xcrd/schemas.go#L23-L25

Check if MR fields do not comply with provider CRDs schema

Thank you for putting this together, the tool is very useful, especially that it's a CLI and can be run in a pipeline.

Are there plans on the roadmap to validate MRs for nonexistent or incorrect fields? We are very conscious about paying compositions tax and often use plain MRs for simpler, non-repeatable deployments. Having validation rules check if fields in a given MR are missing, added or incorrect would help catch errors much earlier.