Skip to content

Latest commit

 

History

History
118 lines (94 loc) · 6.37 KB

PROVIDER_CHECKLIST.md

File metadata and controls

118 lines (94 loc) · 6.37 KB

Provider Checklist

Crossplane manages Resources external via Providers. Providers are composed of Kubernetes Custom Resource Definitions and Controllers that communicate to a remote API and manages the lifecycle of a resource from Creation to Deletion.

To build a new provider, please refer to the Provider Development Guide.

This document contains list of items that are usually involved in managing Open Source contributions to a Crossplane provider. In general your provider should follow the guidelines documented in the Crossplane Contributing guide.

Repository

Although providers can be hosted in any source code repository, the crossplane-contrib Github Organization is available as a neutral home that is under Crossplane's project governance.

Members of the Crossplane community are happy to create a repository in the crossplane-contrib organization and configure access, continuous integration, and storage for software artifacts. Please open an issue in the Crossplane org repository or reach out to the Crossplane #dev channel.

Generally projects are named provider-<name>, with name being the API being managed. Example project names are provider-aws, provider-kubernetes, and provider-github.

The provider-userprovider repository can be used as a starting point for new providers. For terrajet-based providers, the provider-jet-userprovider is available.

Files

Most Crossplane providers include the following files:

Build Process

There are a number of build tools and processes that are common across the Crossplane ecosystem. Using these ensures a consistent development environment across projects.

The provider-userprovider repository contains most of these settings.

Deployment of Artifacts

When deploying provider artifacts, projects should generally follow the Crossplane release process.

Most Crossplane projects use Github Actions to build, tag, and promote software releases.

Providers are packaged as OCI (Docker) images and pushed to an OCI registry as part of the publish and promotion workflows.

In general, providers should:

If you're part of the crossplane-contrib org and want to enable Github CI, push OCI images or packages to the crossplane org in Docker Hub please ask a steering committee member to grant your project access to the GitHub org scoped secrets.

Governance