From 821db73a18e52c0815baf65f54d0142b402e5c7a Mon Sep 17 00:00:00 2001 From: Leif Madsen Date: Mon, 16 Sep 2024 12:30:47 -0400 Subject: [PATCH] Minor adjustments after review Minor adjustments to README.md after performing a review of the contents. --- README.md | 72 +++++++++++++++++++++++++++++++++---------------------- 1 file changed, 44 insertions(+), 28 deletions(-) diff --git a/README.md b/README.md index 72af886..231bafd 100644 --- a/README.md +++ b/README.md @@ -1,6 +1,6 @@ # Infrawatch Release Automation -Common release and automation tooling for infrawatch project, aka Service Telemetry Framework. +Common release and automation tooling for infrawatch project, aka Service Telemetry Framework (STF). ## Related images build process @@ -9,7 +9,7 @@ Common release and automation tooling for infrawatch project, aka Service Teleme All the related images are stored and automatically build in https://quay.io/repository/infrawatch. -The related images include +The related images include: - https://quay.io/repository/infrawatch/sg-core - https://quay.io/repository/infrawatch/sg-bridge @@ -17,8 +17,8 @@ The related images include - https://quay.io/repository/infrawatch/service-telemetry-operator - https://quay.io/repository/infrawatch/smart-gateway-operator -In their respective repositories, we differenciate the following -tags +In their respective repositories, we differentiate the following +tags: - nightly - nightly-1.5 @@ -27,8 +27,9 @@ We use those tags to refer to the latest available nightly builds (built periodically) for the master and stable-1.5 branches respectively. -We also include the tags for the latest release (e.g. SGO v5.1.2), -and the "latest" and "master" tags (point to the same builds). +We also include the tags for the latest release, e.g. Smart Gateway Operator +(SGO) v5.1.2, and the "latest" and "master" tags (point to the same builds). + Those tags are used when cutting a new release. ### Build triggers for related images @@ -40,7 +41,7 @@ For each of the related images the following build triggers are defined: - Push to tags/v.x.y.z These actions will generate a new build to be created and stored -in the specific repository +in the specific repository. ## Bundles build process @@ -48,13 +49,13 @@ in the specific repository Operator bundles are stored in https://quay.io/organization/infrawatch-operators. -The bundles include +The bundles include: - https://quay.io/repository/infrawatch-operators/smart-gateway-operator-bundle - https://quay.io/repository/infrawatch-operators/service-telemetry-operator-bundle -In their respective repositories, we differenciate the following -tags +In their respective repositories, we differentiate the following +tags: - nightly-head - nightly-1.5 @@ -71,19 +72,28 @@ as we do with the related images. Instead, we rely on the execution of the nightly action defined in the release-automation repository. Precisely, https://github.com/infrawatch/release-automation/blob/main/.github/workflows/nightly.yml. -This action fetch master and stable1.5 branches for both STO and SGO, -and executes the releaser.sh script in https://github.com/infrawatch/release-automation/blob/main/releaser.sh. +This action fetches master and stable-1.5 branches for both Service Telemetry +Operator (STO) and Smart Gateway Operator (SGO), and executes the `releaser.sh` +script in +https://github.com/infrawatch/release-automation/blob/main/releaser.sh. -This script automates retrieving the latest available builds for the -related images, setting the correct tags for them, creating the bundles (more information on this in the section below), replacing tags for correct image hashes in the created bundles, validating the bundles and pushin the created bundles to their respective repository. +The `releaser.sh` script automates retrieving the latest available builds for +the related images, setting the correct tags for them, creating the bundles +(more information on this in the section below), replacing tags for correct +image hashes in the created bundles, validating the bundles and pushing the +created bundles to their respective repository. ### Bundle creation The bundle creation is delegated to logic present in each of the operators repository. -Precisely, we generate the bundle for STO using this script https://github.com/infrawatch/service-telemetry-operator/blob/master/build/generate_bundle.sh and we generate the bundle for SGO using this script https://github.com/infrawatch/smart-gateway-operator/blob/master/build/generate_bundle.sh. Both work in a very similar way. +Precisely, we generate the bundle for STO using this script +https://github.com/infrawatch/service-telemetry-operator/blob/master/build/generate_bundle.sh +and we generate the bundle for SGO using this script +https://github.com/infrawatch/smart-gateway-operator/blob/master/build/generate_bundle.sh. +Both work in a very similar way. -The generate_bundle.sh script executes the following steps +The `generate_bundle.sh` script executes the following steps - Generate version - Create working directory @@ -93,20 +103,24 @@ The generate_bundle.sh script executes the following steps #### Bundle version -The bundle version is generated by combining the operator CSV major version and the current UNIX epoch time. E.g. stf/service-telemetry-operator-bundle version=1.5.1723675485, means that -is a build for STO 1.5 built on Aug 14 2024 at 10.45am. You can use -https://www.epochconverter.com/ to get the specific date in which -a desired bundle has been built. +The bundle version is generated by combining the operator CSV major version and +the current UNIX epoch time. For example, stf/service-telemetry-operator-bundle +version=1.5.1723675485, describes a build for STO 1.5, built at epoch time +1723675485, which converts to Aug 14 2024 at 10:45am. You can use +https://www.epochconverter.com/ to get the specific date in which a desired +bundle has been built. ## Index image build process -The creation process of an index image with SGO and STO bundles is also automated. The index image is stored in https://quay.io/organization/infrawatch-operators. +The creation process of an index image with SGO and STO bundles is also +automated. The index image is stored in +https://quay.io/organization/infrawatch-operators. -Precisely, the latest available index image can be found in +Precisely, the latest available index image can be found at: - https://quay.io/repository/infrawatch-operators/infrawatch-catalog -As with the operator bundles, we differenciate the following tags +As with the operator bundles, we differenciate the following tags: - nightly-head - nightly-1.5 @@ -118,10 +132,12 @@ respectively. ### Build process for the index image We also rely on the execution of the nightly action defined in the -release-automation repository for the creation of the index image. Precisely, https://github.com/infrawatch/release-automation/blob/main/.github/workflows/nightly.yml. +release-automation repository for the creation of the index image. Precisely, +https://github.com/infrawatch/release-automation/blob/main/.github/workflows/nightly.yml. -This action fetch master and stable1.5 branches for both STO and SGO, -and executes the releaser.sh script in https://github.com/infrawatch/release-automation/blob/main/releaser.sh. +This action fetches master and stable-1.5 branches for both STO and SGO, and +executes the releaser.sh script in +https://github.com/infrawatch/release-automation/blob/main/releaser.sh. -After the creation of STO and SGO bundles, an step for building -the index image is executed and the result is pushed to the repository. +After the creation of STO and SGO bundles, a step for building the index image +is executed and the result is pushed to the quay.io container repository.