@@ -9,6 +9,7 @@ It is a good idea to do a dry-run check locally, and then delete the local state
 # Create and switch to branch: release-YY.M.
 ./release/create-release-branch.sh -b YY.M -w products
 ./release/create-release-branch.sh -b YY.M -w operators
+./release/create-release-branch.sh -b YY.M -w cockpit
 ./release/create-release-branch.sh -b YY.M -w demos
 
 # Clone to /tmp/stackable-release-YY.M/docker-images and/or enter the directory.
@@ -20,11 +21,13 @@ It is a good idea to do a dry-run check locally, and then delete the local state
 # Raise a PR (dry-run).
 ./release/create-release-candidate-branch.sh -t YY.M.X-rc1 -w products
 ./release/create-release-candidate-branch.sh -t YY.M.X-rc1 -w operators
+./release/create-release-candidate-branch.sh -t YY.M.X-rc1 -w cockpit
 
 # Pretend the PR exists, and exit.
 # This doesn't really test much.
 ./release/merge-release-candidate.sh -t YY.M.X-rc1 -w products
 ./release/merge-release-candidate.sh -t YY.M.X-rc1 -w operators
+./release/merge-release-candidate.sh -t YY.M.X-rc1 -w cockpit
 
 # Clone to /tmp/stackable-release-YY.M/docker-images and/or enter the directory.
 # Fetch and switch to branch: release-YY.M.
@@ -33,6 +36,7 @@ It is a good idea to do a dry-run check locally, and then delete the local state
 # Tag the HEAD commit (in this case it would be the same as `main` where this branch was based).
 ./release/tag-release-candidate.sh -t YY.M.X-rc1 -w products
 ./release/tag-release-candidate.sh -t YY.M.X-rc1 -w operators
+./release/tag-release-candidate.sh -t YY.M.X-rc1 -w cockpit
 
 # TODO: ./release/post-release.sh
 ```
@@ -55,6 +59,7 @@ This procedure would be done until a viable release-candidate can be selected.
 # Push the branch.
 ./release/create-release-branch.sh -b YY.M -w products -p
 ./release/create-release-branch.sh -b YY.M -w operators -p
+./release/create-release-branch.sh -b YY.M -w cockpit -p
 ./release/create-release-branch.sh -b YY.M -w demos -p
 
 # Clone to /tmp/stackable-release-YY.M/docker-images and/or enter the directory.
@@ -65,6 +70,7 @@ This procedure would be done until a viable release-candidate can be selected.
 # Raise a PR.
 ./release/create-release-candidate-branch.sh -t YY.M.X-rc1 -w products -p
 ./release/create-release-candidate-branch.sh -t YY.M.X-rc1 -w operators -p
+./release/create-release-candidate-branch.sh -t YY.M.X-rc1 -w cockpit -p
 ```
 
 Ask people to do approvals.
@@ -80,6 +86,7 @@ Once all approvals are done, merge the changes and tag the release branch `HEAD`
 # Merge the PR (this does not seem to wait for checks to complete).
 ./release/merge-release-candidate.sh -t YY.M.X-rc1 -w products -p
 ./release/merge-release-candidate.sh -t YY.M.X-rc1 -w operators -p
+./release/merge-release-candidate.sh -t YY.M.X-rc1 -w cockpit -p
 ```
 
 It is still worth checking that all PRs are merged.
@@ -94,6 +101,7 @@ It is still worth checking that all PRs are merged.
 # Push tag.
 ./release/tag-release-candidate.sh -t YY.M.X-rc1 -w products -p
 ./release/tag-release-candidate.sh -t YY.M.X-rc1 -w operators -p
+./release/tag-release-candidate.sh -t YY.M.X-rc1 -w cockpit -p
 ```
 
 > [!CAUTION]
@@ -123,6 +131,7 @@ Once the release candidate has been deemed good, do the release proper:
 # Raise a PR.
 ./release/create-release-candidate-branch.sh -t YY.M.X -w products -p
 ./release/create-release-candidate-branch.sh -t YY.M.X -w operators -p
+./release/create-release-candidate-branch.sh -t YY.M.X -w cockpit -p
 ```
 
 Ask people to do approvals.
@@ -138,6 +147,7 @@ Once all approvals are done, merge the changes and tag the release branch `HEAD`
 # Merge the PR (this does not seem to wait for checks to complete).
 ./release/merge-release-candidate.sh -t YY.M.X -w products -p
 ./release/merge-release-candidate.sh -t YY.M.X -w operators -p
+./release/merge-release-candidate.sh -t YY.M.X -w cockpit -p
 
 # Clone to /tmp/stackable-release-YY.M/docker-images and/or enter the directory.
 # Fetch, including tags.
@@ -148,6 +158,7 @@ Once all approvals are done, merge the changes and tag the release branch `HEAD`
 # Push tag.
 ./release/tag-release-candidate.sh -t YY.M.X -w products -p
 ./release/tag-release-candidate.sh -t YY.M.X -w operators -p
+./release/tag-release-candidate.sh -t YY.M.X -w cockpit -p
 ```
 
 > [!CAUTION]
 
@@ -41,6 +41,16 @@ These steps are repeated for each release tag i.e. for both release-candidates a
 # build failures are not yet sent to the #notifications-container-images channel yet.
 # repeat the above with e.g. the tag 25.3.0 once a release candidate is accepted.
 
+# continue with cockpit ...
+# same flow as the operators: branch, RC PR, merge, tag
+./release/create-release-branch.sh -b 25.3 -w cockpit # Only add the -p flag after testing locally first
+./release/create-release-candidate-branch.sh -t 25.3.0-rc1 -w cockpit # Only add the -p flag after testing locally first
+./release/merge-release-candidate.sh -t 25.3.0-rc1 -w cockpit # Only add the -p flag after testing locally first
+./release/tag-release-candidate.sh -t 25.3.0-rc1 -w cockpit # Only add the -p flag after testing locally first
+
+# monitor the GH action that builds the cockpit image and Helm chart for success.
+# repeat the above with e.g. the tag 25.3.0 once a release candidate is accepted.
+
 # continue with the demos ...
 # create and push the release branch (demos are intentionally branch-only:
 # no RC branches, no tagging, no post-release steps)
@@ -112,14 +122,15 @@ A set of scripts that automates some release steps. The release process has mult
 4. Call `tag-release-candidate.sh` - This will:
   - tag merge commit from above, triggering github actions to build the product images and operators
 5. Call `post-release.sh`- This will:
-  - update the operator CHANGELOG.md in `main` with changes from the release tag
-  - create PRs for all operators
+  - update the operator and cockpit CHANGELOG.md in `main` with changes from the release tag
+  - create PRs for all operators and cockpit
 
 > [!NOTE]
 
 > - Steps 2-4 will check out the release branch (or clone it if does exist locally) and so can be run independently of each other.
 > - Any changes should be done manually between steps 2 and 3 i.e. by making changes in the PR branch and/or cherry-picking commits from main.
 > - Demos only require step 1 (branch creation). They are intentionally not tagged or given release candidates.
+> - Cockpit follows the same steps as the operators.
 
 ## Install requirements
 
@@ -142,6 +153,10 @@ cargo install cargo-edit --version 0.12.3
 
 This script requires <https://github.com/mikefarah/yq> (not to be confused with <https://github.com/kislyuk/yq>).
 
+### jaq (json parser)
+
+This script requires <https://github.com/01mf02/jaq> to edit JSON files in place, which `jq` can't do.
+
 ### gh (github client)
 
 This script requires <https://github.com/cli> to be installed.
@@ -163,13 +178,13 @@ pipx inject jinja2-cli pyyaml
 To create release branches use the `create-release-branch.sh` script, called from the repository root folder. The syntax is given below:
 
 ```shell
-./release/create-release-branch.sh -b <release> [-p] [-c] [-w products|operators|demos|all]
+./release/create-release-branch.sh -b <release> [-p] [-c] [-w products|operators|cockpit|demos|all]
 ```
 
 - `-b <release>`: the release number (mandatory). This must be a semver-compatible value (i.e. without leading zeros) such as `23.1`, `23.10` etc. and will be used to create a branch with the name `release-<release>` e.g. `release-23.1`.
 - `-p`: push flag (optional, default is "false"). If provided, the created branches plus any changes made as part of this process will be pushed to the origin.
 - `-c`: cleanup flag (optional, default is "false"). If provided, the repository folders will be torn down on completion.
-- `-w`: where to create the branch. It can be "products", "operators", "demos" or "all".
+- `-w`: where to create the branch. It can be "products", "operators", "cockpit", "demos" or "all".
 
 N.B. the flags cannot be combined (e.g. `-p -c` but not `-pc)
 
@@ -192,13 +207,13 @@ e.g.
 To create release tags use the `create-release-candidate-branch.sh` script, called from the repository root folder. The syntax is given below:
 
 ```shell
-./release/create-release-candidate-branch.sh -t <release-tag> [-p] [-c] [-w products|operators|all]
+./release/create-release-candidate-branch.sh -t <release-tag> [-p] [-c] [-w products|operators|cockpit|all]
 ```
 
 - `-t <release-tag>`: the release tag (mandatory). This must be a semver-compatible value (i.e. major/minor/path, without leading zeros) such as `23.1.0`, `23.10.3-rc1` etc. and will be used to create a tag with the name.
 - `-p`: push flag (optional, default is "false"). If provided, the changes and PRs made as part of this process will be pushed to the origin.
 - `-c`: cleanup flag (optional, default is "false"). If provided, the repository folders will be torn down on completion.
-- `-w`: where to create the tag and update versions in code. It can be "products", "operators" or "all".
+- `-w`: where to create the tag and update versions in code. It can be "products", "operators", "cockpit" or "all".
 
 N.B. the flags cannot be combined (e.g. `-p -c` but not `-pc)
 
@@ -220,6 +235,7 @@ e.g.
   - update the `release-tag` in helm charts
   - rebuilds the helm charts
   - bumps the changelog
+  - for cockpit: sets the version in `package.json`, `package-lock.json` and the Helm `Chart.yaml` instead of updating `Cargo.toml` and rebuilding the Helm charts; `docs/antora.yml` and the changelog are updated like for the operators
 - optional: pushes the new branch (if requested with "-p")
 - optional: deletes the temporary folder (if requested with "-c")
 
@@ -233,12 +249,12 @@ Product and operator images will be built when these PRs are created or updated,
 To merge PRs use the `merge-release-candidate.sh` script, called from the repository root folder. The syntax is given below:
 
 ```shell
-./release/merge-release-candidate.sh -t <release-tag> [-p] [-w products|operators|all]
+./release/merge-release-candidate.sh -t <release-tag> [-p] [-w products|operators|cockpit|all]
 ```
 
 - `-t <release-tag>`: the release tag (mandatory). This must be a semver-compatible value (i.e. major/minor/path, without leading zeros) such as `23.1.0`, `23.10.3-rc1` etc. and will be used to identify the PR (which was created using this tag).
 - `-p`: push flag (optional, default is "false"). If provided, the PRs will be approved and merged.
-- `-w`: where to create the tag and update versions in code. It can be "products", "operators" or "all".
+- `-w`: where to create the tag and update versions in code. It can be "products", "operators", "cockpit" or "all".
 
 e.g.
 
@@ -259,13 +275,13 @@ e.g.
 The final step is to tag the merge commit from above: this is done using the `tag-release-candidate.sh` script, called from the repository root folder. The syntax is given below:
 
 ```shell
-./release/tag-release-candidate.sh -t <release-tag> [-p] [-c] [-w products|operators|all]
+./release/tag-release-candidate.sh -t <release-tag> [-p] [-c] [-w products|operators|cockpit|all]
 ```
 
 - `-t <release-tag>`: the release tag (mandatory). This must be a semver-compatible value (i.e. major/minor/path, without leading zeros) such as `23.1.0`, `23.10.3-rc1` etc. and will be used to create a tag with the name.
 - `-p`: push flag (optional, default is "false"). If provided, the created commits and tags made as part of this process will be pushed to the origin.
 - `-c`: cleanup flag (optional, default is "false"). If provided, the repository folders will be torn down on completion.
-- `-w`: where to create the tag and update versions in code. It can be "products", "operators" or "all".
+- `-w`: where to create the tag and update versions in code. It can be "products", "operators", "cockpit" or "all".
 
 #### What this script does
 
@@ -281,19 +297,20 @@ The final step is to tag the merge commit from above: this is done using the `ta
 Some post release steps are performed with `release/post-release.sh` script, called from the repository root folder. The syntax is given below:
 
 ```shell
-./release/post-release.sh -t <release-tag> [-p] [-w products|operators|all]
+./release/post-release.sh -t <release-tag> [-p] [-w products|operators|cockpit|all]
 ```
 
 - `-t <release-tag>`: the release tag (mandatory). This must be a semver-compatible value (i.e. major/minor/path, without leading zeros) such as `23.1.0`, `23.10.3` etc. and will be used to create a tag with the name.
 - `-p`: push flag (optional, default is "false"). If provided, the created commits and tags made as part of this process will be pushed to the origin.
-- `-w`: which repositories to update the changelogs for. It can be "products", "operators", "all" (defaults to "all").
+- `-w`: which repositories to update the changelogs for. It can be "products", "operators", "cockpit", "all" (defaults to "all").
 
 #### What this script does
 
 - checks that the release tag exists and that all operator repositories have a clean working copy
 - checks that the release tag exists and that the docker-images repository has a clean working copy
 - merges the CHANGELOG.md from the release tag into main
 - creates PRs for all operators
+- does the same for the cockpit repository
 
 ## Build actions
 
@@ -325,6 +342,10 @@ on:
 ...
 ```
 
+### Cockpit image and Helm chart
+
+The cockpit image and Helm chart are built by `build.yaml` in the cockpit repository when a matching tag is pushed. The tag filter there must accept CalVer tags (two-digit year, e.g. `26.3.0`), otherwise tagging builds nothing.
+
 ## Post-release steps
 
 Once the release is complete and all steps above have been verified, the documentation needs to be updated and built. This is done in a separate suite of scripts found https://github.com/stackabletech/documentation/tree/main/scripts[here]. Follow the steps given in the two scripts (there are prompts provided which allow for early-exit if things are not as they should be!).
 
@@ -103,6 +103,16 @@ verify_release() {
 		fi
 	fi
 
+	# package.json version (cockpit)
+	if [ -f "$dir/package.json" ]; then
+		local package_ver
+		package_ver=$(jaq -r '.version' "$dir/package.json")
+		if [ "$package_ver" != "$tag" ]; then
+			>&2 echo "  FAIL: package.json version is '$package_ver', expected '$tag'"
+			errors=$((errors + 1))
+		fi
+	fi
+
 	# Helm Chart.yaml version and appVersion
 	local chart_yaml
 	chart_yaml=$(find "$dir/deploy/helm" -maxdepth 2 -name "Chart.yaml" -print -quit 2>/dev/null || true)
@@ -252,6 +262,9 @@ check_common_dependencies() {
 
 	# yq (YAML processor) - https://github.com/mikefarah/yq
 	yq --version
+
+	# jaq (JSON processor) - https://github.com/01mf02/jaq
+	jaq --version
 }
 
 # CalVer base pattern: YY.M where month is 1-12 without leading zero.
@@ -334,7 +347,7 @@ validate_release_base_version() {
 # Derive common variables from a release tag.
 # Requires $INITIAL_DIR to be set (for reading config.yaml).
 #
-# Sets: RELEASE_BASE, RELEASE_BRANCH, PR_BRANCH, DOCKER_IMAGES_REPO, TEMP_RELEASE_FOLDER
+# Sets: RELEASE_BASE, RELEASE_BRANCH, PR_BRANCH, DOCKER_IMAGES_REPO, COCKPIT_REPO, TEMP_RELEASE_FOLDER
 #
 # Usage:
 #   INITIAL_DIR="$PWD"
@@ -346,13 +359,14 @@ derive_tag_vars() {
 	RELEASE_BRANCH="release-$RELEASE_BASE"      # e.g., release-26.3
 	PR_BRANCH="pr-$tag"                          # e.g., pr-26.3.0-rc1
 	DOCKER_IMAGES_REPO=$(yq '... comments="" | .images-repo ' "$INITIAL_DIR"/release/config.yaml)
+	COCKPIT_REPO=$(yq '... comments="" | .cockpit-repo ' "$INITIAL_DIR"/release/config.yaml)
 	TEMP_RELEASE_FOLDER="/tmp/stackable-$RELEASE_BRANCH"
 }
 
 # Derive common variables from a release base version (YY.M).
 # Requires $INITIAL_DIR to be set (for reading config.yaml).
 #
-# Sets: RELEASE_BRANCH, DOCKER_IMAGES_REPO, DEMOS_REPO, TEMP_RELEASE_FOLDER
+# Sets: RELEASE_BRANCH, DOCKER_IMAGES_REPO, DEMOS_REPO, COCKPIT_REPO, TEMP_RELEASE_FOLDER
 #
 # Usage:
 #   INITIAL_DIR="$PWD"
@@ -363,6 +377,7 @@ derive_branch_vars() {
 	RELEASE_BRANCH="release-$release_base"                # e.g., release-26.3
 	DOCKER_IMAGES_REPO=$(yq '... comments="" | .images-repo ' "$INITIAL_DIR"/release/config.yaml)
 	DEMOS_REPO=$(yq '... comments="" | .demos-repo ' "$INITIAL_DIR"/release/config.yaml)
+	COCKPIT_REPO=$(yq '... comments="" | .cockpit-repo ' "$INITIAL_DIR"/release/config.yaml)
 	TEMP_RELEASE_FOLDER="/tmp/stackable-$RELEASE_BRANCH"
 }
 
 
@@ -1,6 +1,7 @@
 ---
 demos-repo: demos
 images-repo: docker-images
+cockpit-repo: cockpit
 operators:
   - airflow-operator
   - commons-operator
 
@@ -38,6 +38,17 @@ update_operator() (
   push_branch "$operator"
 )
 
+update_cockpit() (
+  ensure_clone "$COCKPIT_REPO" "--branch main"
+  cd "$COCKPIT_REPO"
+  assert_cwd_is_repo "$COCKPIT_REPO"
+  assert_clean_index "$COCKPIT_REPO"
+  git pull && git switch "${RELEASE_BRANCH}" 2> /dev/null || git switch -c "${RELEASE_BRANCH}"
+  assert_on_branch "$RELEASE_BRANCH"
+  assert_remote_exists "$REMOTE" "$COCKPIT_REPO"
+  push_branch "$COCKPIT_REPO"
+)
+
 update_demos() (
   ensure_clone "$DEMOS_REPO" "--branch main"
   cd "$DEMOS_REPO"
@@ -61,10 +72,12 @@ update_repos() {
   case "$WHAT" in
     products) update_products ;;
     operators) for_each_operator update_operator ;;
+    cockpit) update_cockpit ;;
     demos) update_demos ;;
     all)
       update_products
       for_each_operator update_operator
+      update_cockpit
       update_demos
       ;;
   esac
@@ -119,12 +132,12 @@ main() {
   parse_inputs "$@"
 
   if [ -z "${RELEASE_BASE}" ]; then
-    >&2 echo "Usage: create-release-branch.sh -b <branch> [-p] [-c] [-w products|operators|demos|all]"
+    >&2 echo "Usage: create-release-branch.sh -b <branch> [-p] [-c] [-w products|operators|cockpit|demos|all]"
     exit 1
   fi
 
   validate_release_base_version "$RELEASE_BASE"
-  validate_what "$WHAT" "products" "operators" "demos" "all"
+  validate_what "$WHAT" "products" "operators" "cockpit" "demos" "all"
   check_common_dependencies
 
   ensure_temp_folder