Hey, could you please add the https://github.com/projectcontour/contour CRDs?

The link to the github repo on the CRDs page is broken when viewing latest on master: https://github.com/crossplane/crossplane/tree/. This can be fixes by appending master or excluding tree when no tag is supplied.

Currently, we hit Github API rate limiting extremely quickly for our queries to find all CRD types in a repository (search), and relatively quickly for parsing each of those CRDs (get file contents). These results should be cached such that we do not have to hit Github every time they are requested.

A first step could be authenticating requests such that the limit for fetching CRD file content will rise from 60 to 5000 per hour, and 10 to 30 per minute for finding CRDs in a repository.

The next step will be to cache results and crawl repos on a periodic basis based on incoming requests for content.

Add the CRDs of Lieutenant https://github.com/projectsyn/lieutenant-operator to the mix.

It is helpful to know the last time that a repo or CRD was crawled in order to make sure that it is up to date with any recent changes.

The CRD doc experience feels similar to https://godoc.org. One feature I appreciate about https://godoc.org is that I can browse to either a repository root like https://godoc.org/github.com/crossplaneio/crossplane-runtime or a path within a repository like https://godoc.org/github.com/crossplaneio/crossplane-runtime/pkg/reconciler and I'll be shown all the packages under that path. It would be very helpful if CRD doc had similar functionality - i.e. if I browsed to https://doc.crds.dev/github.com/crossplaneio I would see all the known CRDs of the Crossplane project.

Currently CAPI is added, but the provider crds are not
e.g.
https://github.com/kubernetes-sigs/cluster-api-provider-vsphere
https://github.com/kubernetes-sigs/cluster-api-provider-azure

Add https://github.com/kubernetes-sigs/cluster-api-provider-packet CRDs.

Users should be able to share links that reference a specific field in a CRD. The request to have all sections expanded by default (crossplane/crossplane#1295 (comment) cc @negz) should also be implemented as part of this effort.

Was looking for docs on https://doc.crds.dev/github.com/crossplane/oam-kubernetes-runtime and didn't find them. Would be great to add to the homepage!

Should include documentation on issue triage, PR format, and local development.

Add the https://github.com/tektoncd/pipeline CRDs

https://github.com/giantswarm/apiextensions hosts a number of CRDs we are using at Giant Swarm. We'd like to see them in https://doc.crds.dev/

Thanks!

Should include information on how to run doc in a production setting.

It would be awesome to be able to query docs.crds programmatically (through a simple HTTP API).

My use case is to be able to add support in cdk8s to import CRDs that are listed in docs.crds. For example, say I want to import all of crossplane's CRDs into my cdk8s app :-).

In order for https://doc.crds.dev to be used as the default documentation for projects that add Kubernetes CRDs there should be public, documented service level objectives. There should also be documented service level indicators to ensure that SLOs are being met. These can be evolved over time with input from the community, but some initial areas to consider would be:

• Availability (The proportion of requests that resulted in a successful response.)
• Latency (The proportion of requests that were faster than some threshold.)
• Freshness (The proportion of the data that was updated more recently than some time threshold.)
• Correctness (The proportion of records coming into the pipeline that resulted in the correct value coming out.)

Reference: https://landing.google.com/sre/workbook/chapters/implementing-slos/

#32 added the ability to copy links to specific fields in a CRD. However, when a copy link icon is clicked it does not notify the user that the link has been copied. There is no indication that they have copied the link until they try to paste it. While this does not affect functionality, it is a poor UX and can be confusing.

What seems to be the problem?

Add https://github.com/packethost/crossplane-provider-packet CRDs.

When you change the sorting of Kind in a list of CRDs, it is actually sorting alphabetically by URL, not Kind.

In the crossplane/crossplane repo there is a file that includes a CRD that is not an official CRD, but part of a demo. It fails to parse, but is still included in the list of CRDs on the repo page. Clicking on the link leads to the "this has not been indexed yet" page. We should not list CRDs that fail to parse.

Problem

When a repo is renamed in GitHub doc.crds.dev will redirect to the correct repo, as it just uses the one provided to point to, that is then being redirected when we clone and parse.

However the repo name will not automatically update, so you see the old repo name in doc.crds.dev and still have to use the old url when linking to the docs from other sites.

If we change the repo being indexed in config.yaml think old link will be broken, so it's unclear how to get doc.crds.dev to show the new repo name, with a new link, without breaking the old links or having duplicate entries in config.yaml.

The new repo name for ☝️ is https://github.com/packethost/crossplane-provider-equinix-metal/.

What can we do to help?

Would be nice to have a redirect alias for the old repo name to point at the new repo name.

Maybe something like this for config.yaml:

apiVersion: v1
kind: Namespace
metadata:
  name: crdsdev
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: doc-repos
  namespace: crdsdev
data:
  repos: "crossplane/crossplane,crossplane/provider-gcp,crossplane/provider-aws,crossplane/provider-azure,crossplane/provider-alibaba,crossplane/provider-rook,crossplane-contrib/provider-helm,kubernetes-sigs/cluster-api,jetstack/cert-manager,schemahero/schemahero,projectcontour/contour,packethost/crossplane-provider-packet,kubernetes-sigs/cluster-api-provider-packet,crossplane/oam-kubernetes-runtime"
  aliases:
    - alias: old
      target: new
    - alias: packethost/crossplane-provider-packet
      target: packethost/crossplane-provider-equinix-metal

Add an issue template with guidance on how to request support for a new repo.

doc should allow operators to run the service with analytics enabled so that they can track site traffic.

I just realized that I can click to spec and have it collapsed and loved it. A lot of time, I collapse all functions in my editor when I deal with a long page of code and then click through only the things I'd like.

I think it'd be great experience to have a button to collapse all fields and let people open one by one and discover the fields.

I can contribute if there are some pointers about how one could implement this.

Heyho,

could you ad the CRDs for https://github.com/kubernetes-sigs/cluster-api-provider-vsphere

Can we get https://github.com/schemahero/schemahero added to the site? I'd be happy to make a PR if it's preferred.

It would be great to also add docs for kubernetes-sigs/cluster-api-provider-aws

For many distributed teams, running a doc server on the private network is not conducive to their workflow. It should be possible to run a doc server that requires authentication. It would be good to support at least Github and Google for auth in the short term.

Thanks

Currently, Doc will only parse CRDs at annotated tags, which are best practice for releases. While this is sufficient in most cases, projects that use or have used lightweight tags will be unable to see documentation for those tags, even if they were part of a release. Doc should support both types of tags.

https://doc.crds.dev/github.com/crossplane-contrib/provider-helm

ControllerConfig has been added on master branch, but is not yet showing up on https://doc.crds.dev/github.com/crossplane/crossplane

Thanks for adding support for shoring the full GVK in the list view #56, that's a big improvement!

The other day I was reviewing provider-aws CRDs with a contributor and we and we wanted to view the list of beta vs. alpha CRDs and wanted the ability to sort the CRDs by version as a separate field.

Would be awesome to support:

• separate sortable columns in the list view for group, version, and kind
• tighten the spacing of the columns so it's easier to read without jumping back and forth horizontally
  

Really liking the enhancements, this is a super useful tool!!

Please add https://github.com/cluster-api-provider-hcloud/cluster-api-provider-hcloud CRDs

Add the https://github.com/jetstack/cert-manager CRDs

In the short term, all repos that are being crawled should be displayed on the home page. In the long term it will likely be useful to show the top searched repos and allow for searching of all repos.

Hello !

I want to see how an AWS security group or a AWS S3 can be defined in crossplane, but when I look into the examples in the AWS provider GitHub repository, it seems that all is not up to date...
For example :

• the security group for a database does not include 'forProvider' section that seems to be mandatory for a managed resources, isn't it ? https://github.com/crossplane/provider-aws/blob/master/examples/database/mysqlinstance/network.yaml
• for S3, the sample mention a "resource class"... is such an object still used in Crossplane ?

Finally, is this "examples" repository the only location where to find such samples of crossplane Custom Resources ?

Thank you !

What seems to be the problem?

Just realized you can specify a tag in the URL, e.g. https://doc.crds.dev/github.com/crossplane/[email protected], but this isn't discoverable for new users

Would be awesome to:

1. add links for latest 3 tags on main page as follow on to #23
2. provide an available tags so I can select the tags on this page

Add the CRDs of https://github.com/vshn/k8up to the mix.

That would be really cool. Thanks for the great idea and working on it, looks absolutely promising.

Make a dark mode theme for the UI

Currently the repo page provides a link to the repo at the given tag. CRDs should also expose a link so that the raw yaml can be easily accessed.

CRDs are currently listed by filename. When controller-gen has generated the CRD files this works well as the pattern of the filename is <group>_<plural-kind>.yaml. However, it would be nice to also support files with arbitrary names and potentially present the CRDs in an organized format, such as nesting CRDs under their group and listing multiple versions of the same kind together.

Currently, doc will only accept paths with /blob/*/ removed, always returning the content of the CRD on master. Users should be able to not have to remove /blob/master/ (so links can be copied directly) and should be able to specify a branch / tag / SHA other than master.

There are comment tags like // +immutable that do not have proper k8s validation schemes but they do appear in the description section of a field. It'd be cool if doc generator could detect those and just add a button-like box with immutable word or whatever exists in // +something

Parsing a CRD will fail with templated values present. For the short-term, since these values do not exist in the actual schema of the custom resource, they can just be removed to pass validation. In the long-term it may be useful to expose some of these values to users.

Ref #49

Currently, users are only able to view documentation of the storage: true version of a CRD. This should be the default, but it should also be possible view any other served versions.