Introduce minimal documentation for cutting new releases

[timflannagan]

Goal: introduce some light documentation that's centered around how to cut releases, and which steps aren't automated by goreleaser right now.

[timflannagan]

Note: just dumping the command I used to create the latest rukpak.yaml release manifest for the v0.2.0 release so I don't forget again how I did this:

$ yq --version
yq (https://github.com/mikefarah/yq/) version 4.24.2
$ yq manifests/*.yaml manifests/**/*.yaml internal/provisioner/plain/manifests/*.yaml | sed "s/:latest/:v0.2.0/g" > rukpak.yaml

[timflannagan]

And it looks like I forgot to override the default unpacker image used in the plain provisioner deployment manifest:

          args:
          - --unpack-image
          - quay.io/operator-framework/plain-provisioner:v0.2.0

[timflannagan]

Moving this to the 0.3 backlog just so we're forced to have something in place in the short term.

[timflannagan]

Moved this to 0.4 as I just pushed the 0.3 up locally. Note: the command I had outlined in #210 (comment) won't work anymore now that we're working towards a kustomize-based approach for stamping out the rukpak-related manifests.

Side note: it would be nice to have automation that tests the release quickstart manifests when a new release has been cut. I think that would just involve the following steps:

• Create a kind cluster
• Install cert manager
• Wait until cert manager is available
• Apply the rukpak.yaml release manifests
• Wait until the rukpak stack is ready (although I don't think we have any general checks for this right now)
• Load the e2e testdata images via make kind-load-bundles
• Run the e2e suite against that custom rukpak deployment via make test-e2e

[timflannagan]

Notes from grooming:

• We can now run kustomize build ... from the root directory and run sed for replacing the container image tags with the dedicated release tags
• We can use kustomize to inject that --unpack-image flag and point to the dedicated release tags
• We should aim towards automating these manual release steps

[exdx]

I really like the idea of an automated smoke test when a new release tag is pushed.

Side note: from the conversation here #316 (comment) it seems like we don't necessarily want to include the cert-manager installation step as part of the rukpak install. Maybe we can remove that portion from the release description going forward and instruct users to install cert-manager first (linking them to the appropriate doc). It may make more sense since outside of CI environments they may have a version of it on-cluster already.

[timflannagan]

I really like the idea of an automated smoke test when a new release tag is pushed.

Just for housekeeping: related to #263.

[timflannagan]

@exdx Created #319 to re-evaluate our usage of cert-manager as a direct dependency.

[timflannagan]

Notes from grooming:

• Can we use kubectl apply -k manifests instead of relying on kustomize build manifests | kubectl apply -f -?
• Still need a way to inject the container image arguments for the --unpack-image unpacked image to ensure that image uses the release tags built by goreleaser

Tracking automated testing for tags: #263.