Rewrite upstream sync automation to look for latest release (azimuth-cloud#127)

Author: Matt Pryor

.gitlab-ci.yml.sample

@@ -1,7 +1,7 @@
 ---
 
 default:
-  image: python:3.9
+  image: ubuntu:jammy
 
 variables:
   # Because we are installing git-crypt as part of the job, we cannot reuse old
@@ -10,12 +10,13 @@ variables:
   # Write the Azimuth URL to an envfile in the local directory
   AZIMUTH_URL_ENVFILE: ${CI_PROJECT_DIR}/azimuth.env
   # Use the pipeline credentials for Terraform
+  # This assumes that we are using GitLab-managed Terraform state (recommended when available)
   TF_HTTP_USERNAME: gitlab-ci-token
   TF_HTTP_PASSWORD: $CI_JOB_TOKEN
 
 stages:
   # This stage owns the scheduled job that checks for upstream changes
-  - upstream-merge
+  - scheduled
   # This stage owns the deploy and teardown jobs for dynamic environments
   - aio
   # This stage owns the deploy job for our staging environment
@@ -24,23 +25,26 @@ stages:
   - production
 
 #####
-# This job checks to see if there are changes from upstream to be merged
+# This job checks to see if there is a new release that needs to be merged
 #
-# If there are, it will create a new branch containing the changes and a corresponding merge request
+# If there is, it will create a new branch containing the changes and a corresponding merge request
 #
 # It runs as a scheduled job, for which a suitable schedule must be defined, e.g. daily or weekly
 #
 # This job writes back to the repository and to the merge requests API
 # To do this, it needs more power than is granted to the CI token
 # So CI variables must be set that contain an access token and the corresponding username
-# This can be a Project Access Token (paid feature) or a Personal Access Token (not ideal)
+# This can be a Project Access Token (paid feature, recommended if available) or a Personal Access Token (not ideal)
 #####
-upstream_merge:
-  stage: upstream-merge
+check_for_release:
+  stage: scheduled
   rules:
     - if: $CI_PIPELINE_SOURCE == "schedule" && $CI_COMMIT_BRANCH == "main"
   variables:
     GIT_STRATEGY: none
+  before_script:
+    - apt update -y
+    - apt install -y curl git jq
   script:
     # Configure git to use the available credentials
     - git config --global credential.helper store
@@ -58,7 +62,7 @@ upstream_merge:
           source ".mergeenv"
           BODY="{
             \"id\": ${CI_PROJECT_ID},
-            \"title\": \"[$UPSTREAM_COMMIT] Merge changes from upstream\",
+            \"title\": \"Upgrade Azimuth to ${RELEASE_TAG}\",
             \"source_branch\": \"${BRANCH_NAME}\",
             \"target_branch\": \"main\",
             \"remove_source_branch\": true,

bin/ci-exec

@@ -1,7 +1,7 @@
 #!/usr/bin/env bash
 
 #####
-# This script is designed to be run in a CI pipeline in an isolated Ubuntu 20.04 environment
+# This script is designed to be run in a CI pipeline in an isolated Ubuntu Jammy environment
 #####
 
 set -eo pipefail
@@ -30,7 +30,6 @@ function run_apt {
   fi
 }
 
-
 if [ -n "$GIT_CRYPT_KEY_B64" ]; then
   # Unlock the repository
   run_apt update
@@ -55,7 +54,7 @@ if [ -z "$AZIMUTH_ENVIRONMENT" ]; then
 fi
 
 run_apt update
-run_apt install -y qemu-utils
+run_apt install -y git python3 python3-pip qemu-utils
 pip install -U pip
 pip install -r requirements.txt
 

bin/create-merge-branch

@@ -1,7 +1,7 @@
 #!/usr/bin/env bash
 
 #####
-# This script creates a branch that merges the latest upstream changes
+# This script creates a branch that merges the latest release
 #####
 
 set -e
@@ -18,29 +18,33 @@ if [ -n "$(git status --short)" ]; then
   exit 1
 fi
 
-if ! git remote show upstream > /dev/null 2>&1; then
-  echo "[INFO] Adding upstream remote..."
-  git remote add upstream https://github.com/stackhpc/azimuth-config.git
-fi
+UPSTREAM_REPO="${UPSTREAM_REPO:-"stackhpc/azimuth-config"}"
+echo "[INFO] Using upstream repo - $UPSTREAM_REPO"
+
+# Fetch the tag for the latest release from the upstream repository
+RELEASE_TAG="$(curl -fsSL "https://api.github.com/repos/${UPSTREAM_REPO}/releases/latest" | jq -r '.tag_name')"
+echo "[INFO] Found latest release tag - $RELEASE_TAG"
 
+# Add the repository as an upstream
+echo "[INFO] Adding upstream remote..."
+git remote add upstream "https://github.com/${UPSTREAM_REPO}.git"
 git remote show upstream
 
-echo "[INFO] Fetching remote branches..."
-git fetch upstream
+echo "[INFO] Fetching remote tags..."
+git remote update
 
-# Use the short sha from the upstream branch to distinguish merge branches
-UPSTREAM_COMMIT="$(git rev-parse --short upstream/main)"
-BRANCH_NAME="upstream-merge-${UPSTREAM_COMMIT}"
+# Use a branch that is named for the release
+BRANCH_NAME="upgrade/$RELEASE_TAG"
 
 # Check if the branch already exists on the origin
-# If it does, there is nothing more to do as the branch can be rebased from the MR if required
+# If it does, there is nothing more to do as the branch can be rebased from the MR
 if git show-branch "remotes/origin/$BRANCH_NAME" >/dev/null 2>&1; then
-  echo "[INFO] Merge branch already created for commit '${UPSTREAM_COMMIT}'"
+  echo "[INFO] Merge branch already created for $RELEASE_TAG"
   exit
 fi
 
-echo "[INFO] Attempting to merge from upstream"
-git merge --strategy recursive -X theirs --no-commit upstream/main
+echo "[INFO] Merging release tag - $RELEASE_TAG"
+git merge --strategy recursive -X theirs --no-commit $RELEASE_TAG
 
 # Check if the merge resulted in any changes being staged
 if [ -n "$(git status --short)" ]; then
@@ -50,8 +54,8 @@ if [ -n "$(git status --short)" ]; then
   echo "[INFO] Checking out temporary branch '$BRANCH_NAME'..."
   git checkout -b "$BRANCH_NAME"
 
-  echo "[INFO] Committing changes from upstream"
-  git commit -m "Merging changes from upstream"
+  echo "[INFO] Committing changes"
+  git commit -m "Upgrade Azimuth to $RELEASE_TAG"
 
   echo "[INFO] Pushing changes to origin"
   git push --set-upstream origin "$BRANCH_NAME"
@@ -63,10 +67,10 @@ if [ -n "$(git status --short)" ]; then
   echo "[INFO] Removing temporary branch"
   git branch -d "$BRANCH_NAME"
 
-  # Write a file containing the branch name and upstream commit
+  # Write a file containing the branch name and tag
   # for automatic PR or MR creation that follows
   echo "BRANCH_NAME=\"$BRANCH_NAME\"" > .mergeenv
-  echo "UPSTREAM_COMMIT=\"$UPSTREAM_COMMIT\"" >> .mergeenv
+  echo "RELEASE_TAG=\"$RELEASE_TAG\"" >> .mergeenv
 else
   echo "[INFO] Merge resulted in no changes"
 fi

docs/deployment/automation.md

@@ -157,18 +157,21 @@ azimuth_current_cloud_label: "{{ lookup('env', 'CI_ENVIRONMENT_NAME') }}"
 # "Secrets"
 #   Since the dynamic environments are short-lived, there is not much
 #   risk in using secrets that are not really secret for ease
+admin_dashboard_ingress_basic_auth_password: admin
 harbor_admin_password: admin
-harbor_secret_key: notsecret0123456
-zenith_registrar_subdomain_token_signing_key: notsecret
-azimuth_secret_key: notsecret
+harbor_secret_key: abcdefghijklmnop
+keycloak_admin_password: admin
+zenith_registrar_subdomain_token_signing_key: abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789AA
+azimuth_secret_key: 9876543210ZYXWVUTSRQPONMLKJIHGFEDCBAzyxwvutsrqponmlkjihgfedcda00
 ```
 
-### Automated synchronisation of upstream changes
+### Automated upgrades
 
 The sample configuration also includes a job that can automatically
-[synchronise changes from upstream](../repository/index.md#synchronising-changes-from-upstream).
+[propose an Azimuth upgrade](../repository/index.md#upgrading-to-a-new-azimuth-release)
+when a new release becomes available.
 
-If the job detects changes, it will create a new branch, merge the changes
+If the job detects a new release, it will create a new branch, merge the changes
 into it and create an associated
 [merge request](https://docs.gitlab.com/ee/user/project/merge_requests/).
 If you also have
@@ -177,10 +180,10 @@ enabled, then this will automatically trigger a job to deploy the changes for re
 
 The job will only run for a
 [scheduled pipeline](https://docs.gitlab.com/ee/ci/pipelines/schedules.html), so
-if you want to have automatic synchronisation of upstream changes you must
+to enable automated upgrades you must
 [add a pipeline schedule](https://docs.gitlab.com/ee/ci/pipelines/schedules.html#add-a-pipeline-schedule)
 for the `main` branch of your configuration repository with a suitable interval
-(e.g. daily or weekly).
+(e.g. weekly).
 
 Because the job needs to write to the repository and call the merge requests API,
 the [CI/CD job token](https://docs.gitlab.com/ee/ci/jobs/ci_job_token.html) is not

docs/repository/index.md

@@ -102,6 +102,12 @@ component versions, upgraded dependencies and new images.
     The available releases, with associated release notes, can be reviewed on the
     [Azimuth releases page](https://github.com/stackhpc/azimuth-config/releases).
 
+!!! tip  "Automating upgrades"
+
+    If you have automated deployments, which is recommended for a production installation,
+    this process
+    [can also be automated](../deployment/automation.md#automated-synchronisation-of-upstream-changes).
+
 To upgrade your Azimuth configuration to a new release, use the following steps to create
 a new branch containing the upgrade: