chore: More release updates (#11)

Makefile

@@ -1,14 +1,14 @@
 # The version of Zarf to use. To keep this repo as portable as possible the Zarf binary will be downloaded and added to
 # the build folder.
 # renovate: datasource=github-tags depName=defenseunicorns/zarf
-ZARF_VERSION := v0.30.1
+ZARF_VERSION := v0.31.2
 
 # The version of the build harness container to use
 BUILD_HARNESS_REPO := ghcr.io/defenseunicorns/build-harness/build-harness
 # renovate: datasource=docker depName=ghcr.io/defenseunicorns/build-harness/build-harness
-BUILD_HARNESS_VERSION := 1.10.2
+BUILD_HARNESS_VERSION := 1.14.2
 # renovate: datasource=docker depName=ghcr.io/defenseunicorns/packages/dubbd-k3d extractVersion=^(?<version>\d+\.\d+\.\d+)
-DUBBD_K3D_VERSION := 0.12.1
+DUBBD_K3D_VERSION := 0.13.0
 
 # Figure out which Zarf binary we should use based on the operating system we are on
 ZARF_BIN := zarf

README.md

@@ -74,5 +74,5 @@ zarf-packages:
   # Mattermost Operator with a Mattermost instance
   - name: mattermost
     repository: ghcr.io/defenseunicorns/uds-capability/mattermost
-    ref: 0.0.1
+    ref: x.x.x
 ```

docs/DEVELOPMENT_MAINTENANCE.md

@@ -26,4 +26,37 @@ export AWS_AVAILABILITY_ZONE=a
 
  3) At the root of this repository, you can run `make test`. This will provision an ec2 instance, build and deploy all dependencies and packages, and run an e2e test to insure the capability is deploying successfully, available and ready.
 
-You can also follow the bread crumbs of the Makefile to manually create the cluster as well as build and deploy all the necessary packages.
+You can also follow the bread crumbs of the Makefile to manually create the cluster as well as build and deploy all the necessary packages.
+
+## How to manually trigger e2e tests in a github PR
+
+This project uses [slash command dispatch](https://github.com/peter-evans/slash-command-dispatch). To use this, add a comment in your PR that says `/test all`. This will trigger the e2e tests for this repo.
+
+## Auto e2e tests
+
+This project will automatically run e2e tests on pushes to `main`
+
+## Creating Releases
+
+This project uses [release-please-action](https://github.com/google-github-actions/release-please-action) for versioning and releasing OCI packages.
+
+### How should I write my commits?
+
+Release Please assumes you are using [Conventional Commit messages](https://www.conventionalcommits.org/).
+
+The most important prefixes you should have in mind are:
+
+- `fix:` which represents bug fixes, and correlates to a [SemVer](https://semver.org/)
+  patch.
+- `feat:` which represents a new feature, and correlates to a SemVer minor.
+- `feat!:`,  or `fix!:`, `refactor!:`, etc., which represent a breaking change
+  (indicated by the `!`) and will result in a SemVer major.
+
+When changes are merged to the `main` branch, the Release Please will evaluate all commits since the previous release to calculate what changes are included and will create another PR to increase the version and tag a new release (per the Release Please design [documentation](https://github.com/googleapis/release-please/blob/main/docs/design.md#lifecycle-of-a-release)). This will also automatically generate changelog entries based on these commits.
+
+> TIP: Merging a PR should be done via a branch **"Squash and merge"**; this means that the commit message seen on this PR merge is what Release Please will use to determine a version bump.
+
+When the auto generated Release Please PR is merged the following steps will automatically happen.
+1) A new release will be created and tagged
+1) An e2e test will be triggered
+1) If e2e passes, a new capability artifact will be published to the OCI registry

zarf.yaml

@@ -3,7 +3,9 @@ kind: ZarfPackageConfig
 metadata:
   name: mattermost
   description: "UDS mattermost capability deployed via flux"
+  # x-release-please-start-version
   version: "0.0.2"
+  # x-release-please-end
   architecture: amd64
 
 variables: