Creating a release plan

A ReleasePlan (RP) CR is created for a specific Application. It defines the the process to release a specific Application Snapshot in a target tenant namespace, whether automatic releases are enabled, as well as additional data to pass to a corresponding RPA.

Creating a `ReleasePlan` object

The development team creates a ReleasePlan object in the developer tenant namespace. The ReleasePlan object includes a reference to the application that the development team wants to release, along with tenant namespace where the application is supposed to be released.

Prerequisites

You have an existing Development tenant namespace.
You have completed the steps listed in the Getting started in the CLI page.

Procedures

Create a ReleasePlan.yaml object locally.

Example ReleasePlan.yaml object

apiVersion: appstudio.redhat.com/v1alpha1
kind: ReleasePlan
metadata:
 labels:
   release.appstudio.openshift.io/auto-release: 'true' (1)
   release.appstudio.openshift.io/standing-attribution: 'true'
   release.appstudio.openshift.io/releasePlanAdmission: 'rpa-name' (2)
 name: sre-production (3)
 namespace: dev-tenant-namespace (4)
spec:
 application: <application-name> (5)
 data: <key> (6)
 pipelineRef: <pipeline-ref> (7)
 serviceAccount: <service-account> (8)
 releaseGracePeriodDays: <days> (9)
 target: managed-tenant-namespace (10)

1	Optional: Control if Releases should be created automatically for this ReleasePlan when tests pass. Defaults to true.
2	Optional: The name of the RPA to use if more than one RPA references the specified application.
3	The name of the release plan.
4	The development team’s tenant namespace.
5	The name of the application that you want to deploy to the managed tenant namespace.
6	Optional: An unstructured key used for providing data for the managed Pipeline.
7	Optional: Reference to the Pipeline to be executed by the release service.
8	Optional: The name of the service account to use in the Pipeline to gain elevated privileges. It’s used only if you have defined the `pipelineRef` value.
9	Optional: The number of days a Release CR should be kept in the cluster before being automatically deleted by KubeArchive. If not specified, KubeArchive will delete the Release after 5 days. KubeArchive will also delete any Release more than 30 days old, regardless of this value. Deleted Releases are archived and remain accessible via the KubeArchive API. This affects Snapshot GC; Snapshots are protected while their Release exists.
10	The tenant namespace to which the system deploys the application. This tenant namespace is created by the Managed environment team (for example, your organization’s SRE team)

In the development tenant namespace, apply the ReleasePlan.yaml file and add the resource to your cluster by running the following command:
```
$ kubectl apply -f ReleasePlan.yaml -n dev
```

Release Retention and Lifecycle

The releaseGracePeriodDays field in your ReleasePlan controls how long Release CRs remain in the cluster before automatic deletion.

How it works

Default: If releaseGracePeriodDays is unspecified, Releases are deleted 5 days after creation
Custom retention: Set releaseGracePeriodDays to any value between 1-30 days
Maximum cap: Values higher than 30 are automatically capped at 30 days
Deletion timing: KubeArchive deletes Releases based on their creation timestamp
Archive access: Access deleted Releases through the KubeArchive API for historical access and auditing

Impact on Snapshot garbage collection

Release retention directly affects Snapshot lifecycle:

Protected Snapshots: Snapshots referenced by active Releases are protected from garbage collection
Freed Snapshots: When a Release is deleted, its Snapshot becomes eligible for count-based garbage collection
Quota management: Shorter retention periods help prevent Snapshot quota limits by allowing faster garbage collection

See Snapshot quotas and garbage collection details for more information.

Verification

In the Konflux UI, select the Release services > Release plan tab.
Review the Release plan object that you just added. Using the Release plan tab, you can update or delete the selected Release plan object.
When a ReleasePlan is correctly configured to be paired with a ReleasePlanAdmission, its Status will display as being Matched.

Auto-release logic

The release.appstudio.openshift.io/auto-release label controls whether a Release should automatically be created once a push snapshot passes all required tests. The value of the label should be a CEL expression. This gives users fine-grained control over whether their snapshots are auto-released. Konflux also supports custom functions for common use-cases. There is a table of custom functions below. To request others, please reach out to the Konflux integration service team.

Name

Description

UpdatedComponentIs(component)

Takes a component name as a parameter. Returns true if the snapshot is a component snapshot and the name of the updated component in the snapshot matches the named passed as an argument. Also returns true if the snapshot is a group snapshot and the argument matches the name of any of the updated components in the snapshot.

Creating a release plan