keptn / gh-automation

This repo is the single source of truth for pipelines that are shared across Keptn repos

Keptn

Keptn V1 has reached end of life on December 22nd, 2023 and has been replaced.

Keptn is an event-based control plane for continuous delivery and automated operations for cloud-native applications. Please find the documentation on our website, and read the motivation about Keptn on our Why Keptn? page.

In addition, you can find the roadmap of the Keptn project here. It provides an overview of user stories that are currently in the focus of development for the next release.

Keptn Today! Keptn Lifecycle Toolkit Tomorrow!

Keptn: Moving towards our 1.0 milestone!

3 years of hard work will soon reach a long awaited milestone: Keptn 1.0 with LTS (Long Time Support) brings you automated release validation based on SLOs that you can easily integrate into your existing DevOps Tools (deployment, test and observability).

If you want to explore Keptn then keep scrolling down to get all information!

Keptn Lifecycle Toolkit: The kuber-native road ahead!

At KubeCon 2022 in Detroit we announced the direction we are heading: Keptn Lifecycle Toolkit! Keptn Lifecycle Toolkit brings application-aware deployment lifecycle management to your k8s cluster:

• kubernetes-native: no external dependencies, everything in your CRDs and
• pipeline-less: works with any delivery tool (ArgoCD, Flux, Jenkins, GitHub, GitLab, Harness ...) without having to integrate it with Keptn

To decide whether you want to stick with Keptn 1.0 or focus on Keptn Lifecycle Toolkit do this:

1. Watch our Keptn Lifecycle Toolkit in a Nutshell video including live demo
2. Try Keptn Lifecycle Toolkit yourself: GitHub Repo

Quickstart

Keptn runs on Kubernetes. To get started, you can follow our Quickstart guide.

Developing Keptn

The easiest way to develop is to spin up a Kubernetes cluster locally by using K3d (requires docker) via the following commands:

curl -s https://raw.githubusercontent.com/rancher/k3d/main/install.sh | TAG=v5.3.0 bash
k3d cluster create mykeptn -p "8082:80@loadbalancer" --k3s-arg "--no-deploy=traefik@server:*"

Afterwards, install Keptn CLI:

curl -sL https://get.keptn.sh | bash

And install Keptn using Helm:

helm repo add keptn https://charts.keptn.sh && helm repo update
helm install keptn keptn/keptn \
-n keptn --create-namespace \
--wait \
--set=apiGatewayNginx.type=LoadBalancer

In case you want to install helm-service and jmeter-service, execute:

helm install jmeter-service keptn/jmeter-service -n keptn
helm install helm-service keptn/helm-service -n keptn

Please follow the instructions printed by the CLI to connect to your Keptn installation.

Installing Keptn from Master branch

Note: This will install a potentially unstable version of Keptn.

If you want to install the latest master version of Keptn onto your cluster you can do that by using the development helm charts repository located at https://charts-dev.keptn.sh . By default, the global registry used is ´ghcr.io/keptn´, so you will need to override it.

helm repo add keptn-dev https://charts-dev.keptn.sh    # Add the keptn-dev helm repo
helm repo update                                       # Update all repo contents
helm search repo keptn-dev --devel --versions          # List all versions present in the keptn-dev repo

# Select a chart version from the previous command that you want to install

helm install -n keptn-dev keptn keptn-dev/keptn --set=global.keptn.registry=ghcr.io/keptn --create-namespace --version "<the-version-you-selected-previously>"

You can find more information in our docs.

Community

Please find details on regular hosted community events as well as our Slack workspace in the keptn/community repo.

Keptn Versions compatibilities

We manage the Keptn core components in versions. The versions of the Keptn core components and the services are compatible with each other. However, contributed services as well as services that are not considered core components might not follow the same versioning schema.

We are tracking compatibility of those services on our website.

Container Images

Keptn provides container images of all core components. The respective images in their versions are stored on the following container registries:

• GitHub Container Registry
• Quay.io Container Registry

From version 0.19.0, all released container images are signed using cosign with a keyless signing mechanism. That means that Keptn uses short-lived code signing certificates and keys together with OIDC and a transparency log to sign all its container images. More info on keyless signed container images can be found here.

Helm Chart

Keptn provides Helm charts for easy installation of all control plane components. From version 0.19.0, the charts are signed and can be verified with the public key that can be found in assets/pubring.gpg and attached to every release. More info on signed Helm charts can be found here.

Contributions

You are welcome to contribute using Pull Requests to the respective repositories. Before contributing, please read our Contributing Guidelines and our Code of Conduct. Please also check out our list of good first issues.

License

Keptn is an Open Source Project. Please see LICENSE for more information.

Adopters

For a list of users, please refer to ADOPTERS.md.

Further information

• The Keptn`s website has the documentation of Keptn and its use cases.
• Please join the Keptn community.

gh-automation's Issues

Introduce signed container images to the integration release pipelines

Follow the same principle as keptn/keptn#8740

Create release notes Pull Request to source branch, not master

When triggering a new release using the release-integration workflow from a branch like "6.0.x" (as in: not the default branch master/main), we still create a PR towards the default branch. This is caused by the following lines of code:

gh-automation/.github/workflows/release-integration.yml

Lines 81 to 86 in 1e631cb

	- name: Create GitHub Pull Request for release notes
	env:
	RELEASE_TAG: ${{ steps.create-release-package.outputs.tag-name }}
	GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
	run: |
	gh pr create --title "chore: Release notes for $RELEASE_TAG" --body "**This is an automated PR for release notes of $RELEASE_TAG!**"

When doing this, all commits from the branch (e.g., 6.0.x) are also part of the PR, e.g.:

As a fix, the PR needs to be created towards the branch it originated from, e.g., 6.0.x (or in terms of GH actions: ${GITHUB_REF##*/}

Tasks:

• add --base ${GITHUB_REF##*/} to the gh create pr command

Repo activity

@mowies is this still a usful repo? or should we just archive?

Docker-Build Action: normalize tags causes only the first tag to be used

With

gh-automation/.github/actions/docker-build/action.yaml

Lines 70 to 73 in c403b07

	- name: Normalize TAGS
	shell: bash
	id: normalize_tags
	run: echo "::set-output name=tags::$(echo '${{ inputs.TAGS }}' | tr '[:upper:]' '[:lower:]')"

The following step does not build all tags, but only the first one (without env.DATETIME)

      - name: Docker Build
        id: docker_build
        uses: keptn/gh-automation/.github/actions/[email protected]
        with:
          TAGS: |
            ${{ env.DOCKER_ORGANIZATION }}/${{ env.IMAGE }}:${{ env.VERSION }}
            ${{ env.DOCKER_ORGANIZATION }}/${{ env.IMAGE }}:${{ env.VERSION }}.${{ env.DATETIME }}
          BUILD_ARGS: |
            version=${{ env.VERSION }}
          REGISTRY_USER: ${{ secrets.REGISTRY_USER }}
          REGISTRY_PASSWORD: ${{ secrets.REGISTRY_PASSWORD }}
          PUSH: ${{(github.event_name == 'push' || github.event_name == 'workflow_dispatch' || github.event.pull_request.head.repo.full_name == github.repository)}}

Expected behaviour

All Tags listed in TAGS are built (and pushed)

Analysis

I was able to reproduce this with the following job:

      # Runs a single command using the runners shell
      - name: Before
        run: echo Tags='${{ env.TAGS }}'

      - name: Normalize TAGS
        shell: bash
        id: normalize_tags
        run: echo "::set-output name=tags::$(echo '${{ env.TAGS }}' | tr '[:upper:]' '[:lower:]')"

      # Runs a set of commands using the runners shell
      - name: After
        run: echo Tags='${{ steps.normalize_tags.outputs.tags }}'

Docker-Build Action: normalize tags causes problems with upper-cased tags

With

gh-automation/.github/actions/docker-build/action.yaml

Lines 70 to 73 in c403b07

	- name: Normalize TAGS
	shell: bash
	id: normalize_tags
	run: echo "::set-output name=tags::$(echo '${{ inputs.TAGS }}' | tr '[:upper:]' '[:lower:]')"

The following step builds all tags, but tags with upper-cased characters will be lower-cased, which breaks certain integrations, e.g.:

      - name: Docker Build
        id: docker_build
        uses: keptn/gh-automation/.github/actions/[email protected]
        with:
          TAGS: |
            ${{ env.DOCKER_ORGANIZATION }}/${{ env.IMAGE }}:PR-123
            ${{ env.DOCKER_ORGANIZATION }}/${{ env.IMAGE }}:PR-123.${{ env.DATETIME }}
          BUILD_ARGS: |
            version=${{ env.VERSION }}
          REGISTRY_USER: ${{ secrets.REGISTRY_USER }}
          REGISTRY_PASSWORD: ${{ secrets.REGISTRY_PASSWORD }}

In the above example, the tags will be normaliezd from "PR-123" to "pr-123".

In our helm-charts we are expecting the tags to be "PR-123" though, so we end up getting image pull back offs when installing helm charts.

Expected behaviour

All Tags listed in TAGS are built the correct way.

release-integration: Add possibility to publish a release without draft

Change

gh-automation/.github/workflows/release-integration.yml

Lines 89 to 94 in 22589e0

	- name: Create GitHub Release
	env:
	RELEASE_TAG: ${{ steps.create-release-package.outputs.tag-name }}
	GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
	run: |
	gh release create "$RELEASE_TAG" --draft --notes-file "${{ env.RELEASE_NOTES_FILE }}" --title "$RELEASE_TAG"

such that it is possible/configurable to not create a draft release.

We need to add an option to toggle having a draft release or not. By default --draft is enabled.