-
Notifications
You must be signed in to change notification settings - Fork 45
Add documentation on manually triggering a ReleasePlan #268
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,56 @@ | ||
= Manually Triggering a ReleasePlan | ||
|
||
This document covers the process to manually trigger a ReleasePlan for a given Snapshot of an Application when using Konflux. Common use cases include re-releasing a snapshot that failed to release due to a now-resolved condition or in the case that a ReleasePlan is not automatically triggered on every Snapshot intentionally to enforce manual releases (see: Releases to Production Registries that happen infrequently). | ||
|
||
.*Prerequisites* | ||
|
||
* A Konflux workspace with an Application with complete Snapshots, a valid ReleasePlan, and a valid ReleasePlanAdmission | ||
* CLI Access to the Konflux Instance and Namespace that houses the Application and resources | ||
* A minimum of Maintainer access to the Workspace/Namespace that houses the Application and ReleasePlan | ||
* [Optional] Contributor (Viewer) access to the Release Engineering namespace that houses the ReleasePlanAdmission for the Application in question | ||
|
||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. As a general rule, Red Hat/IBM encourage us to minimize capitalization, because the industry tendency is to do the opposite. In these prerequisites, the only things that I would leave capitalized are "Konflux", "ReleasePlan," and "ReleasePlanAdmission." Product names are capitalized, and objects written in camel case are kept that way. Everything else should probably be lower case 👍 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. |
||
.*Procedures* | ||
|
||
. Create a `Release.yaml` object locally | ||
|
||
+ | ||
*Example `Release.yaml` object* | ||
|
||
+ | ||
[source,yaml] | ||
---- | ||
apiVersion: appstudio.redhat.com/v1alpha1 | ||
kind: Release | ||
metadata: | ||
annotations: | ||
pac.test.appstudio.openshift.io/event-type: push | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. is this needed? |
||
name: <my-application-name>-manual-release-<unique-identifier> <.> | ||
namespace: <application-workspace> <.> | ||
spec: | ||
gracePeriodDays: 7 <.> | ||
releasePlan: <release-plan> <.> | ||
snapshot: <snapshot-name> <.> | ||
---- | ||
|
||
+ | ||
<.> The name of the release object - set to something identifiable and unique. | ||
<.> The namespace that houses the Application you're planning to release. | ||
<.> The number of days the Release object should be preserved. | ||
<.> The name of the ReleasePlan that should be used. | ||
<.> The name of the Snapshot to Release. | ||
|
||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So in lines 36-40, I suggest leaving only "ReleasePlan" capitalized |
||
. In the development workspace, apply the `Release.yaml` file and add the resource to your cluster by running the following command: | ||
|
||
+ | ||
[source,shell] | ||
---- | ||
$ oc apply -f Release.yaml | ||
---- | ||
|
||
.*Verification* | ||
|
||
. On the Trusted Application Pipeline console, select the *Release* tab under the Application. | ||
. You should see a Release object matching the name you configured. If you have access to the Release Engineering namespace, you should be able to see the PipelineRun for the Release. | ||
|
||
.Next steps | ||
link:https://redhat-appstudio.github.io/docs.appstudio.io/Documentation/main/how-to-guides/proc_managed_services_onboarding.adoc/[Managed services team onboarding] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is all great info, and it's super helpful to have use cases. But I recommend breaking it up into shorter sentences to not overwhelm readers, and rephrasing a bit for clarity:
"One common use case for this procedure is re-releasing a snapshot that failed to release due to an issue that has been resolved. Another use case is when manual releases are mandatory, because ReleasePlans are not automatically triggered on every snapshot. (See: Releases to production registries that happen infrequently)."
Also, should that sentence in the parentheses have a link to something? ^^