Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document nightly and nightly-1.5 release process #12

Merged
merged 1 commit into from
Aug 22, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
126 changes: 125 additions & 1 deletion README.md
Original file line number Diff line number Diff line change
@@ -1,3 +1,127 @@
# release-automation
# Infrawatch Release Automation

Common release and automation tooling for infrawatch project, aka Service Telemetry Framework.

## Related images build process

### Repositories and tag definition for related images

All the related images are stored and automatically build in
https://quay.io/repository/infrawatch.

The related images include

- https://quay.io/repository/infrawatch/sg-core
- https://quay.io/repository/infrawatch/sg-bridge
- https://quay.io/repository/infrawatch/prometheus-webhook-snmp
- 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

- nightly
- nightly-1.5

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).
Those tags are used when cutting a new release.

### Build triggers for related images

For each of the related images the following build triggers are defined:

- Push to stable-x.y.z branch
- Push to master branch
- Push to tags/v.x.y.z

These actions will generate a new build to be created and stored
in the specific repository

## Bundles build process

### Repositories and tag definition for bundles

Operator bundles are stored in https://quay.io/organization/infrawatch-operators.

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

- nightly-head
- nightly-1.5

We use those tags to refer to the latest available nightly builds
(built periodically) for the master and stable-1.5 branches
respectively.

### Build process for bundles

Bundles build process is not automatically triggered by the repository
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 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.

### 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.

The generate_bundle.sh script executes the following steps

- Generate version
- Create working directory
- Generate Dockerfile
- Generate bundle
- Copy extra metadata

#### 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.

## 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.

Precisely, the latest available index image can be found in

- https://quay.io/repository/infrawatch-operators/infrawatch-catalog

As with the operator bundles, we differenciate the following tags

- nightly-head
- nightly-1.5

We use those tags to refer to the latest available nightly builds
(built periodically) for the master and stable-1.5 branches
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.

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.

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.
Loading