Skip to content
This repository has been archived by the owner on Nov 5, 2024. It is now read-only.

Add documentation on manually triggering a ReleasePlan #268

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
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
1 change: 1 addition & 0 deletions docs/modules/ROOT/nav-how-to-guides.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -31,6 +31,7 @@
** xref:how-to-guides/proc_managing-compliance-with-the-enterprise-contract.adoc[Managing compliance with the Enterprise Contract]
** xref:how-to-guides/con_release_application.adoc[Releasing an application]
*** xref:how-to-guides/proc_release_plan.adoc[Creating a `releasePlan` object]
*** xref:how-to-guides/proc_manually_triggering_a_release_plan.adoc[Manually Releasing a Snapshot]
** xref:how-to-guides/proc_managed_services_onboarding.adoc[Managed services team onboarding]
** xref:how-to-guides/proc_delete_application.adoc[Deleting an application]
** xref:how-to-guides/proc_multiversion.adoc[Managing multiple software versions]
Expand Down
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).
Copy link
Collaborator

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? ^^


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

Copy link
Collaborator

Choose a reason for hiding this comment

The 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 👍

Copy link
Collaborator

Choose a reason for hiding this comment

The 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
Copy link
Member

Choose a reason for hiding this comment

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

Copy link
Collaborator

Choose a reason for hiding this comment

The 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]
Loading