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

Conversation

gurnben
Copy link
Contributor

@gurnben gurnben commented Jun 3, 2024

Summary of Changes

This PR adds documentation on how to manually trigger a Release of a Snapshot!

@github-actions github-actions bot added the size: XL Extra Large label Jun 3, 2024
Copy link

github-actions bot commented Jun 3, 2024

🚀 Preview is available at https://pr-268--boisterous-meerkat-894982.netlify.app

Copy link

github-actions bot commented Jun 3, 2024

🚀 Preview is available at https://pr-268--boisterous-meerkat-894982.netlify.app

Copy link
Member

@dirgim dirgim left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good to me, tagging SMEs to look at it too

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?

@arewm
Copy link
Contributor

arewm commented Jul 17, 2024

The redhat-appstudio docs are deprecated. Would you be able to recreate a similar PR on konflux-ci/docs?

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

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

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

@arewm
Copy link
Contributor

arewm commented Jul 26, 2024

@gurnben , I recently added https://konflux-ci.dev/docs/advanced-how-tos/releasing/create-release/ Can you see if you can instead add to that page if any further clarification is needed?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
size: XL Extra Large
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants