docs: add Auditable release #2912

hisarbalik · 2026-01-25T18:30:39Z

Description

Changes proposed in this pull request (what was done and why):

Changes refer to particular issues, PRs or documents:

Traceability

The PR is linked to a GitHub issue.
The follow-up issues (if any) are linked in the Related Issues section.
If the change is user-facing, the documentation has been adjusted.
If a CRD is changed, the corresponding Busola ConfigMap has been adjusted.
The feature is unit-tested.
The feature is e2e-tested.

…anager into auditable-release

NHingerl · 2026-01-26T11:21:13Z

docs/contributor/arch/031-auditable-release-automation.md

+
+## Context
+
+In the context of the SAP BTP, Kyma runtime product, ensuring a reliable and auditable release process is crucial for maintaining software quality and compliance. An automated release pipeline not only streamlines the deployment process but also provides a clear audit trail of changes, approvals, and deployments.


Shorter and more direct:

Suggested change

In the context of the SAP BTP, Kyma runtime product, ensuring a reliable and auditable release process is crucial for maintaining software quality and compliance. An automated release pipeline not only streamlines the deployment process but also provides a clear audit trail of changes, approvals, and deployments.

To ensure the quality and compliance of the SAP BTP, Kyma runtime product, we must have a reliable and auditable release process. Our current process lacks a clear audit trail.

NHingerl · 2026-01-26T11:22:18Z

docs/contributor/arch/031-auditable-release-automation.md

+
+In the context of the SAP BTP, Kyma runtime product, ensuring a reliable and auditable release process is crucial for maintaining software quality and compliance. An automated release pipeline not only streamlines the deployment process but also provides a clear audit trail of changes, approvals, and deployments.
+
+This document outlines the principles and practices for implementing auditable release automation within the Kyma runtime product environment.


Suggested change

This document outlines the principles and practices for implementing auditable release automation within the Kyma runtime product environment.

This document proposes a new, automated release process that produces the required audit artifacts for changes, approvals, and deployments.

NHingerl · 2026-01-26T11:22:52Z

docs/contributor/arch/031-auditable-release-automation.md

+
+This document outlines the principles and practices for implementing auditable release automation within the Kyma runtime product environment.
+
+## Principles of Auditable Release Automation


Suggested change

## Principles of Auditable Release Automation

## Audit Requirements

NHingerl · 2026-01-26T11:23:40Z

docs/contributor/arch/031-auditable-release-automation.md

+
+## Principles of Auditable Release Automation
+
+For auditing purposes, each release must provide successful test result artifacts. This includes:


Suggested change

For auditing purposes, each release must provide successful test result artifacts. This includes:

To pass an audit, the release process must produce the following artifacts:

NHingerl · 2026-01-26T11:28:06Z

docs/contributor/arch/031-auditable-release-automation.md

+
+### Test Execution Reports
+
+Test execution reports should be downloaded for both unit tests and end-to-end (E2E) tests from corresponding GitHub Workflow executions and retained for audit purposes.


Can we switch to active voice?

Suggested change

Test execution reports should be downloaded for both unit tests and end-to-end (E2E) tests from corresponding GitHub Workflow executions and retained for audit purposes.

The release workflow must download and retain the execution reports for all unit and end-to-end (E2E) tests from their corresponding GitHub workflow runs.

NHingerl · 2026-01-26T11:49:13Z

docs/contributor/arch/031-auditable-release-automation.md

+
+### Docker Images
+
+The Docker image used for testing and release should be reproducible and traceable. The current release pipeline builds two Docker images: first for testing and second for release.


Suggested change

The Docker image used for testing and release should be reproducible and traceable. The current release pipeline builds two Docker images: first for testing and second for release.

The Docker image used for testing must be the exact same image that is used for the release. Our release process must produce reproducible and traceable images.

NHingerl · 2026-01-26T11:49:44Z

docs/contributor/arch/031-auditable-release-automation.md

+
+The Docker image used for testing and release should be reproducible and traceable. The current release pipeline builds two Docker images: first for testing and second for release.
+
+**Current Flow:**


Suggested change

**Current Flow:**

**Current Flow:**

Our current release pipeline builds two separate images:

NHingerl · 2026-01-26T11:51:35Z

docs/contributor/arch/031-auditable-release-automation.md

+The Docker image used for testing and release should be reproducible and traceable. The current release pipeline builds two Docker images: first for testing and second for release.
+
+**Current Flow:**
+- First Docker image is built during release preparation PR and pushed to the Kyma dev registry with a unique PR tag and digest SHA. This image is used for running unit and E2E tests.


Suggested change

- First Docker image is built during release preparation PR and pushed to the Kyma dev registry with a unique PR tag and digest SHA. This image is used for running unit and E2E tests.

- The release preparation workflow builds a Docker image from a PR and pushes it to the Kyma dev registry with a unique PR tag and digest SHA. This image is used to run unit and E2E tests.

NHingerl · 2026-01-26T11:54:31Z

docs/contributor/arch/031-auditable-release-automation.md

+
+**Current Flow:**
+- First Docker image is built during release preparation PR and pushed to the Kyma dev registry with a unique PR tag and digest SHA. This image is used for running unit and E2E tests.
+- After successful tests, the second image is built for release using the same Dockerfile and source code, but tagged with release version and pushed to the production registry.


Suggested change

- After successful tests, the second image is built for release using the same Dockerfile and source code, but tagged with release version and pushed to the production registry.

- After successful tests, the release workflow builds a new image from the same Dockerfile and source code, tags it with the release version and pushes it to the production registry.

NHingerl · 2026-01-26T11:57:42Z

docs/contributor/arch/031-auditable-release-automation.md

+Both images currently receive different digests due to different build environments and timestamps, despite having identical content and application binary. This behavior is not acceptable for auditable release automation.
+
+**Resolution:**
+Implement deterministic Docker builds to ensure PR and release images produce identical digests when built from the same source code.


Suggested change

Implement deterministic Docker builds to ensure PR and release images produce identical digests when built from the same source code.

We must implement deterministic Docker builds. An image built from a PR must have the identical digest as the final release image built from the same source code. This makes the build process auditable.

NHingerl · 2026-01-28T13:29:50Z

docs/contributor/arch/031-auditable-release-automation.md

 ### Test Execution Reports

-Test execution reports should be downloaded for both unit tests and end-to-end (E2E) tests from corresponding GitHub Workflow executions and retained for audit purposes.
+Test execution reports should be downloaded for unit tests, end-to-end (E2E) tests, and Gardener Integration tests from corresponding GitHub Workflow executions and retained for audit purposes.


Suggested change

Test execution reports should be downloaded for unit tests, end-to-end (E2E) tests, and Gardener Integration tests from corresponding GitHub Workflow executions and retained for audit purposes.

Test execution reports should be downloaded for unit tests, end-to-end (E2E) tests, and Gardener integration tests from corresponding GitHub Workflow executions and retained for audit purposes.

NHingerl · 2026-01-28T13:32:20Z

docs/contributor/arch/031-auditable-release-automation.md


+### Download Test Reports
+
+The test reports from unit tests, E2E tests, and Gardener tests should be downloaded from the respective GitHub Actions workflows and stored as artifacts for audit purposes. For this pupose, a new re-usable workflow created to download and store test reports based on workflow run ID and job name.


should or must? Or simply, "We create a reusable workflow that downloads the test results from... based on... and stores them..."

(I'm not sure which of the actions is "based on run ID and job name", the downloading or the storing?)

NHingerl · 2026-01-28T13:35:09Z

docs/contributor/arch/031-auditable-release-automation.md

+### Download Test Reports
+
+The test reports from unit tests, E2E tests, and Gardener tests should be downloaded from the respective GitHub Actions workflows and stored as artifacts for audit purposes. For this pupose, a new re-usable workflow created to download and store test reports based on workflow run ID and job name.
+The new workflow can be called from the release PR workflow after test jobs are completed successfully and upload to the pre-configured GCP bucket for audit retention as desccribed [here](https://github.tools.sap/kyma/backlog/issues/8419).


Please clarify who/what is uploaded by whom. Not sure what "upload" in the middle of this sentence means. Thus, the following is probably wrong:

Suggested change

The new workflow can be called from the release PR workflow after test jobs are completed successfully and upload to the pre-configured GCP bucket for audit retention as desccribed [here](https://github.tools.sap/kyma/backlog/issues/8419).

After test jobs are completed successfully, the new workflow is called from the release PR workflow and uploaded to the pre-configured GCP bucket for audit retention (see [Archive Test Logs for 12-Month Auditing via Release Assets #8419](https://github.tools.sap/kyma/backlog/issues/8419).

NHingerl · 2026-01-28T13:50:06Z

docs/contributor/arch/031-auditable-release-automation.md

+The new workflow can be called from the release PR workflow after test jobs are completed successfully and upload to the pre-configured GCP bucket for audit retention as desccribed [here](https://github.tools.sap/kyma/backlog/issues/8419).
+
+### Deterministic Docker Builds
+To achieve deterministic Docker builds, the following strategies can be employed:


Suggested change

To achieve deterministic Docker builds, the following strategies can be employed:

To achieve deterministic Docker builds, we consider the following strategies:

NHingerl · 2026-01-28T13:50:22Z

docs/contributor/arch/031-auditable-release-automation.md

+### Deterministic Docker Builds
+To achieve deterministic Docker builds, the following strategies can be employed:
+
+- **Reproducible Build Tools**: Utilize tools and techniques that support reproducible builds, such as Docker's BuildKit option, which have to be implemented by the `Image-Builder`.


Suggested change

- **Reproducible Build Tools**: Utilize tools and techniques that support reproducible builds, such as Docker's BuildKit option, which have to be implemented by the `Image-Builder`.

- **Reproducible Build Tools**: Utilize tools and techniques that support reproducible builds, such as Docker's BuildKit option, which must be implemented by the `Image-Builder`.

NHingerl · 2026-01-28T13:51:37Z

docs/contributor/arch/031-auditable-release-automation.md

+To achieve deterministic Docker builds, the following strategies can be employed:
+
+- **Reproducible Build Tools**: Utilize tools and techniques that support reproducible builds, such as Docker's BuildKit option, which have to be implemented by the `Image-Builder`.
+- **Copy Release PR Image**: As an alternative to reproducible builds, the release process can be modified to copy the Docker image built during the release PR directly to the production registry with the release tag. This approach ensures that the same image used for testing is released, maintaining identical digests.


Suggested change

- **Copy Release PR Image**: As an alternative to reproducible builds, the release process can be modified to copy the Docker image built during the release PR directly to the production registry with the release tag. This approach ensures that the same image used for testing is released, maintaining identical digests.

- **Copy Release PR Image**: As an alternative to reproducible builds, we can modify the release process to copy the Docker image built during the release PR directly to the production registry with the release tag. This approach ensures that the same image used for testing is released, maintaining identical digests.

add docs

b044ac8

hisarbalik requested a review from a team as a code owner January 25, 2026 18:30

github-actions bot added the kind/docs Categorizes issue or PR as related to a documentation change label Jan 25, 2026

github-actions bot added this to the 1.57.0 milestone Jan 25, 2026

hisarbalik added do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. and removed kind/docs Categorizes issue or PR as related to a documentation change labels Jan 25, 2026

github-actions bot added the kind/docs Categorizes issue or PR as related to a documentation change label Jan 25, 2026

hisarbalik added 6 commits January 25, 2026 19:31

update

348e3a6

update

80f4651

Merge branch 'main' into auditable-release

dfb34b8

update

807f9f1

Merge branch 'auditable-release' of github.com:hisarbalik/telemetry-m…

d6b5aae

…anager into auditable-release

update

6049ac9

NHingerl reviewed Jan 26, 2026

View reviewed changes

hisarbalik added 4 commits January 28, 2026 08:28

update diagrams

086f350

update diagrams

1dec6dd

update

017cd53

update

652b059

NHingerl reviewed Jan 28, 2026

View reviewed changes


		## Context

		In the context of the SAP BTP, Kyma runtime product, ensuring a reliable and auditable release process is crucial for maintaining software quality and compliance. An automated release pipeline not only streamlines the deployment process but also provides a clear audit trail of changes, approvals, and deployments.

	In the context of the SAP BTP, Kyma runtime product, ensuring a reliable and auditable release process is crucial for maintaining software quality and compliance. An automated release pipeline not only streamlines the deployment process but also provides a clear audit trail of changes, approvals, and deployments.
	To ensure the quality and compliance of the SAP BTP, Kyma runtime product, we must have a reliable and auditable release process. Our current process lacks a clear audit trail.


		In the context of the SAP BTP, Kyma runtime product, ensuring a reliable and auditable release process is crucial for maintaining software quality and compliance. An automated release pipeline not only streamlines the deployment process but also provides a clear audit trail of changes, approvals, and deployments.

		This document outlines the principles and practices for implementing auditable release automation within the Kyma runtime product environment.

	This document outlines the principles and practices for implementing auditable release automation within the Kyma runtime product environment.
	This document proposes a new, automated release process that produces the required audit artifacts for changes, approvals, and deployments.


		This document outlines the principles and practices for implementing auditable release automation within the Kyma runtime product environment.

		## Principles of Auditable Release Automation

	## Principles of Auditable Release Automation
	## Audit Requirements


		## Principles of Auditable Release Automation

		For auditing purposes, each release must provide successful test result artifacts. This includes:

	For auditing purposes, each release must provide successful test result artifacts. This includes:
	To pass an audit, the release process must produce the following artifacts:


		### Test Execution Reports

		Test execution reports should be downloaded for both unit tests and end-to-end (E2E) tests from corresponding GitHub Workflow executions and retained for audit purposes.

	Test execution reports should be downloaded for both unit tests and end-to-end (E2E) tests from corresponding GitHub Workflow executions and retained for audit purposes.
	The release workflow must download and retain the execution reports for all unit and end-to-end (E2E) tests from their corresponding GitHub workflow runs.


		### Docker Images

		The Docker image used for testing and release should be reproducible and traceable. The current release pipeline builds two Docker images: first for testing and second for release.

	The Docker image used for testing and release should be reproducible and traceable. The current release pipeline builds two Docker images: first for testing and second for release.
	The Docker image used for testing must be the exact same image that is used for the release. Our release process must produce reproducible and traceable images.


		The Docker image used for testing and release should be reproducible and traceable. The current release pipeline builds two Docker images: first for testing and second for release.

		Current Flow:

	Current Flow:
	Current Flow:
	Our current release pipeline builds two separate images:

	- First Docker image is built during release preparation PR and pushed to the Kyma dev registry with a unique PR tag and digest SHA. This image is used for running unit and E2E tests.
	- The release preparation workflow builds a Docker image from a PR and pushes it to the Kyma dev registry with a unique PR tag and digest SHA. This image is used to run unit and E2E tests.

	- After successful tests, the second image is built for release using the same Dockerfile and source code, but tagged with release version and pushed to the production registry.
	- After successful tests, the release workflow builds a new image from the same Dockerfile and source code, tags it with the release version and pushes it to the production registry.

	Implement deterministic Docker builds to ensure PR and release images produce identical digests when built from the same source code.
	We must implement deterministic Docker builds. An image built from a PR must have the identical digest as the final release image built from the same source code. This makes the build process auditable.


		### Download Test Reports

		The test reports from unit tests, E2E tests, and Gardener tests should be downloaded from the respective GitHub Actions workflows and stored as artifacts for audit purposes. For this pupose, a new re-usable workflow created to download and store test reports based on workflow run ID and job name.

	The new workflow can be called from the release PR workflow after test jobs are completed successfully and upload to the pre-configured GCP bucket for audit retention as desccribed [here](https://github.tools.sap/kyma/backlog/issues/8419).
	After test jobs are completed successfully, the new workflow is called from the release PR workflow and uploaded to the pre-configured GCP bucket for audit retention (see [Archive Test Logs for 12-Month Auditing via Release Assets #8419](https://github.tools.sap/kyma/backlog/issues/8419).

	To achieve deterministic Docker builds, the following strategies can be employed:
	To achieve deterministic Docker builds, we consider the following strategies:

docs: add Auditable release #2912

Are you sure you want to change the base?

docs: add Auditable release #2912

Conversation

hisarbalik commented Jan 25, 2026

Description

Traceability

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

	- Reproducible Build Tools: Utilize tools and techniques that support reproducible builds, such as Docker's BuildKit option, which have to be implemented by the `Image-Builder`.
	- Reproducible Build Tools: Utilize tools and techniques that support reproducible builds, such as Docker's BuildKit option, which must be implemented by the `Image-Builder`.

	- Copy Release PR Image: As an alternative to reproducible builds, the release process can be modified to copy the Docker image built during the release PR directly to the production registry with the release tag. This approach ensures that the same image used for testing is released, maintaining identical digests.
	- Copy Release PR Image: As an alternative to reproducible builds, we can modify the release process to copy the Docker image built during the release PR directly to the production registry with the release tag. This approach ensures that the same image used for testing is released, maintaining identical digests.