In my last post I covered using a private image registry for Crossplane Packages. In this post, I cover setting up a repo with Github Actions to automate the building of a Crossplane Package. I’ll combine that with GitOps to show an end-to-end update to rollout.

Crossplane offers two types of Packages, Configuration and Provider. We can specify Provider dependencies within a Configuration Package so the required provider(s) are automatically installed if not already present. We could skip Packages when using GitOps and store the contents (Primarily XRDs and Compositions) in a Git repo. Both mechanisms offer us rollback/forward and state enforcement. Or we could use Package as our GitOps derived resource. I see benefit in the latter based on the overall SDLC process. Here are a few of my reasonings for this:

• A Package can be shared between organizations and individuals much easier than a configuration defined in a Git repo.
• Packages are easier to consume for testing in the early stages of the SDLC.
• Packages can be replicated at the registry level, contributing to high availability.
• Crossplane Package Manager distributes the reconcile task.

So for those reasons, I’m going to say the best route is to package all configs and consume them either via the cli install method or via a Package resource manifest.

I won’t cover all of the details for creating Packages manually here. You can refer to the docs if you are just getting started (Package docs). The automation follows these steps:

1. Commit a change to local Crossplane Package artifacts repo
2. Tag the commit with a SemVer value and push to origin (Stored in Github in this case)
3. Github Actions on push:
   1. Checkout repo.
   2. Write last commit tag value to variable.
   3. Docker login to image registry (Upbound Cloud in this case).
   4. Build Package and tag with value from step b.
   5. Push Package to registry.
   6. Update Package resource manifest in repo with new tag from step b.
4. GitOps detects change to resource manifest and syncs with cluster.
5. Crossplane installs new Package revision from registry.

Resulting in end-to-end Package automation that can be shared with other teams, installed from the command line during testing, and delivered to Prod clusters via GitOps. Rather than type all of it out, I’ll demonstrate with a video.

Useful Links:
Crossplane Package docs
Github Actions docs
Argo CD with Crossplane series here and here
Github Actions file used