Merge pull request #39 from robobario/release-flow-sync

Sync release flow with flink-sql

.github/workflows/integration.yaml

@@ -2,8 +2,8 @@ name: Build
 
 on:
   push:
-    branches: [ "main", "releases/**" ]
-    tags: ["v*"]
+    branches: [ "main", "release-**" ]
+    tags: [ "[0-9]+.[0-9]+.[0-9]+" ]
   pull_request:
     types: [ opened, synchronize, reopened ]
 

.github/workflows/release-transition.yaml

@@ -34,7 +34,7 @@ jobs:
         run: |
           if [[ "${{ github.event.inputs.transition }}" == "DEVELOPMENT_TO_RELEASE" ]]; then
             # integration.yaml will push up a matching image tag after Releaser pushes up the v${newVersion} tag
-            IMAGE_TAG="v${{ github.event.inputs.newVersion }}"
+            IMAGE_TAG="${{ github.event.inputs.newVersion }}"
           else
             # integration.yaml will push images to quay tagged with the branch name on push to branch
             IMAGE_TAG="${{ github.event.inputs.branch }}"
@@ -58,9 +58,9 @@ jobs:
         uses: peter-evans/create-pull-request@v7
         with:
           # use token so that the created PR will trigger other actions, default GITHUB_TOKEN does not do this
-          token: ${{ secrets.RELEASE_PAT }}
+          token: ${{ secrets.RELEASE_TOKEN }}
           commit-message: "Update to ${{ github.event.inputs.newVersion }}"
-          branch: "release-transition-${{ github.event.inputs.branch }}-${{ github.event.inputs.newVersion }}"
+          branch: "transition-${{ github.event.inputs.branch }}-${{ github.event.inputs.newVersion }}"
           signoff: true
           title: "Release Transition ${{ github.event.inputs.branch }} from ${{ github.event.inputs.transition }}: ${{github.event.inputs.newVersion}}"
           body: "Release Transition ${{ github.event.inputs.branch }} from ${{ github.event.inputs.transition }}: ${{github.event.inputs.newVersion}}"

RELEASING.md

@@ -4,8 +4,8 @@ Currently the only external artefact for a release is the data generator image i
 
 The automation builds and pushes images to quay on push to:
 1. main (image will be tagged as main eg quay.io/streamshub/flink-examples-data-generator:main )
-2. branches named releases/** (image will be tagged as branch name eg quay.io/streamshub/flink-examples-data-generator:releases/0.0)
-3. tag push (image will be tagged with the git tag, for example git tag v0.0.1 -> quay.io/streamshub/flink-examples-data-generator:releases/v0.0.1)
+2. branches named release-** (image will be tagged as branch name, for example branch release-0.0.x -> quay.io/streamshub/flink-examples-data-generator:release-0.0.x)
+3. semver-like tag push (image will be tagged with the git tag, for example git tag 0.0.1 -> quay.io/streamshub/flink-examples-data-generator:0.0.1)
 
 For the branches targeted above we can use github Actions to transition them between two states:
 
@@ -15,7 +15,7 @@ For the branches targeted above we can use github Actions to transition them bet
 ## Prerequisites
 You must have permissions to execute manual GitHub Actions workflows and the ability to push tags to this repository
 
-The repository must have a `RELEASE_PAT` secret containing a non-expired GitHub Personal Access Token with write permissions for this repositories contents and PRs.
+The repository must have a `RELEASE_TOKEN` secret containing a non-expired GitHub Personal Access Token with write permissions for this repositories contents and PRs.
 
 ## To Release a Branch that is in Development
 
@@ -24,8 +24,8 @@ The repository must have a `RELEASE_PAT` secret containing a non-expired GitHub
   - New Version: if your development branch is on 0.0.1-SNAPSHOT in the maven projects, you would set this to 0.0.1
   - Choose: `DEVELOPMENT_TO_RELEASE`
 2. This will create a PR. After CI has run against this PR, review, approve and merge it.
-3. Fetch the branch changes locally and tag the merge commit as `v${version}`. So if you are releasing 0.0.1, run `git tag -a v0.0.1 -m v0.0.1` and push the tag up.
-4. This tag push will trigger [integration.yaml](https://github.com/streamshub/flink-sql-examples/actions/workflows/integration.yaml) to push a v0.0.1 tagged image to quay.io,
+3. Fetch the branch changes locally and tag the merge commit as `${version}`. So if you are releasing 0.0.1, run `git tag -a 0.0.1 -m 0.0.1` and push the tag up.
+4. This tag push will trigger [integration.yaml](https://github.com/streamshub/flink-sql-examples/actions/workflows/integration.yaml) to push a 0.0.1 tagged image to quay.io,
   matching the references in the deployment YAML that were set in the transition PR.
 5. After the automation pushes the image to quay, you should be able to execute the examples successfully.
 
@@ -41,8 +41,8 @@ The repository must have a `RELEASE_PAT` secret containing a non-expired GitHub
 
 If we ever needed to release an older version for some reason (like we wanted to put out a bugfixed 0.0.2 but main has moved far ahead)
 
-1. Branch off the tag you want to work from, the release branch name must start with `releases/`, so if I want to add a bugfix to 0.0.1 I might
-  execute `git checkout -b releases/0.0 v0.0.1 && git push releases/0.0`
-2. Transition the new `releases/0.0` branch to Development following the process above,  setting the branch to `releases/0.0` in the action
+1. Branch off the tag you want to work from, the release branch name must start with `release-`, so if I want to add a bugfix to 0.0.1 I might
+  execute `git checkout -b release-0.0 0.0.1 && git push release-0.0`
+2. Transition the new `release-0.0` branch to Development following the process above,  setting the branch to `release-0.0` in the action
 3. Make code changes
-4. Release the branch following the process above, setting the branch to `releases/0.0` in the action
+4. Release the branch following the process above, setting the branch to `release-0.0` in the action