Merge pull request #223 from MartinBasti/fix-vale-issues

Fix vale issues

docs/modules/ROOT/pages/advanced-how-tos/building-olm.adoc

@@ -1,6 +1,6 @@
 = Building an Operator Lifecycle Manager (OLM) Operator in {ProductName}
 
-If you are developing an application that aligns with the link:https://operatorframework.io/[Operator Framework], and managing it with link:https://olm.operatorframework.io/docs/[Operator Lifecycle Manager (OLM)], you can build that application in {ProductName}. We refer to such applications as OLM Operators. 
+If you are developing an application that aligns with the link:https://operatorframework.io/[Operator Framework], and managing it with link:https://olm.operatorframework.io/docs/[Operator Lifecycle Manager (OLM)], you can build that application in {ProductName}. We refer to such applications as OLM Operators.
 
 OLM Operators include the following elements:
 
@@ -18,7 +18,7 @@ NOTE: A link:https://github.com/konflux-ci/olm-operator-konflux-sample[sample re
 
 == Building the Operator and the bundle
 
-[NOTE] 
+[NOTE]
 ====
 This procedure assumes that the source code for your Operator and bundle, including the Dockerfiles, are in the same git repository, per OLM convention.
 ====
@@ -29,7 +29,7 @@ This procedure assumes that the source code for your Operator and bundle, includ
 . In your new application, xref:../how-tos/creating.adoc[add a new component] for your Operator. Be sure to specify the correct path to the Operator's Dockerfile within its git repository.
 . Add another component for your bundle. Enter the same URL that you used for the Operator, but enter the path to the bundle's Dockerfile.
 . (Optional) If you are using a file-based Catalog (FBC) for your OLM Operator, you must build the FBC as another component in its own separate application in {ProductName}.
-. (Optional) You may want to configure {ProductName} to xref:../how-tos/configuring/redundant-rebuilds.adoc[prevent redundant rebuilds] for this application. For example, you can configure {ProductName} to rebuild your bundle image only if a commit is made to its Dockerfile or the `/bundle` directory, instead of rebuilding it whenever any commit is made to your OLM Operator's git repository. 
+. (Optional) You may want to configure {ProductName} to xref:../how-tos/configuring/redundant-rebuilds.adoc[prevent redundant rebuilds] for this application. For example, you can configure {ProductName} to rebuild your bundle image only if a commit is made to its Dockerfile or the `/bundle` directory, instead of rebuilding it whenever any commit is made to your OLM Operator's git repository.
 
 == Automating updates for image references in the CSV
 
@@ -56,7 +56,7 @@ NOTE: If you want to update the references in your CSV to match where the operan
 . In your new application, xref:../how-tos/creating.adoc[add a new component] for your FBC. Be sure to select the file-based catalog pipeline and to specify the correct path to the catalog's Containerfile within its git repository.
 
 +
-NOTE: As long as the Containerfile populates the cache, the image produced with a FBC fragment can be used as a link:https://olm.operatorframework.io/docs/concepts/crds/catalogsource/[CatalogSource]. You can use *opm* to generate the cache in the final stage of your Containerfile.
+NOTE: If the Containerfile populates the cache, the image produced with a FBC fragment can be used as a link:https://olm.operatorframework.io/docs/concepts/crds/catalogsource/[CatalogSource]. You can use *opm* to generate the cache in the final stage of your Containerfile.
 
 +
 [source,dockerfile]

docs/modules/ROOT/pages/advanced-how-tos/installing/enabling-builds.adoc

@@ -1,6 +1,6 @@
 = Enabling build pipelines
 
-Before users can create an application in {ProductName}, you must enable build pipelines in your instance of {ProductName}. At the time of publication, this process includes configuring a smee channel, to listen for users' pull requests, and creating a GitHub App, so {ProductName} can access those PRs. 
+Before users can create an application in {ProductName}, you must enable build pipelines in your instance of {ProductName}. At the time of publication, this process includes configuring a smee channel, to listen for users' pull requests, and creating a GitHub App, so {ProductName} can access those PRs.
 
 .Prerequisites:
 
@@ -10,7 +10,7 @@ Before users can create an application in {ProductName}, you must enable build p
 .Procedure:
 
 . Start a new link:https://smee.io/[smee] channel.
-. In the repository for your instance of {ProductName}, edit the file /smee/smee-client.yaml. Replace `<smee-channel>` with the webhook proxy URL from the previous step. 
+. In the repository for your instance of {ProductName}, edit the file /smee/smee-client.yaml. Replace `<smee-channel>` with the webhook proxy URL from the previous step.
 . Create a GitHub App according to link:https://pipelinesascode.com/docs/install/github_apps/#manual-setup[these Pipelines as Code instructions]. For the *Webhook URL* field, use the webhook proxy URL for your smee channel.
 
 .Verification
@@ -24,7 +24,7 @@ For further details on PipelineRun permissions, please refer to the https://pipe
 
 A controller can be deployed to simplify the lifecycle management of image repositories in quay.io. Documentation for this process can be found in the link:https://github.com/konflux-ci/konflux-ci/blob/main/docs/quay.md#automatically-provision-quay-repositories-for-container-images[installation docs].
 
-Creating components with the UI requires that an additional controller is deployed to manage the automatic creation of quay image repositories. 
+Creating components with the UI requires that an additional controller is deployed to manage the automatic creation of quay image repositories.
 
 This controller can be used to create image repositories scoped to individual components. It is also required to be deployed in order to enable creating components from the {ProductName} UI.
 
@@ -36,9 +36,9 @@ This **ConfigMap** can contain references to any Tekton pipeline bundles. Additi
 
 === Build pipelines available in quay.io/konflux-ci [[available-pipelines]]
 
-In order to support different use cases within {ProductName}, multiple Tekton pipeline bundles are available in the `quay.io/konflux-ci` organization. 
+In order to support different use cases within {ProductName}, multiple Tekton pipeline bundles are available in the `quay.io/konflux-ci` organization.
 
-NOTE: The tasks included in the pipeline definitions can be discovered using `yq` or `jq`. For example, 
+NOTE: The tasks included in the pipeline definitions can be discovered using `yq` or `jq`. For example,
 ```bash
 $ tkn bundle list -o yaml quay.io/konflux-ci/tekton-catalog/pipeline-docker-build:devel pipeline docker-build 2>/dev/null | yq ".spec.tasks.[].name"
 init
@@ -67,13 +67,12 @@ _Uses `buildah` to create a container image. It also optionally creates a source
 
 This pipeline is ideal for building container images from a Containerfile while maintaining trust after pipeline customization.
 
-_Uses `buildah` to create a container image leveraging link:https://konflux-ci.dev/architecture/ADR/0036-trusted-artifacts.html[trusted artifacts]. It also optionally creates a source image and runs some build-time tests. Information is shared between tasks using OCI artifacts instead of PVCs. EC will pass the link:https://enterprisecontract.dev/docs/ec-policies/release_policy.html#trusted_task__trusted[trusted_task.trusted] policy as long as all data used to build the artifact is generated from trusted tasks. (link:https://quay.io/repository/konflux-ci/tekton-catalog/pipeline-docker-build-oci-ta?tab=tags[quay.io link], link:https://github.com/konflux-ci/build-definitions/blob/main/pipelines/docker-build-oci-ta/README.md[parameter documentation])_
+_Uses `buildah` to create a container image leveraging link:https://konflux-ci.dev/architecture/ADR/0036-trusted-artifacts.html[trusted artifacts]. It also optionally creates a source image and runs some build-time tests. Information is shared between tasks using OCI artifacts instead of PVCs. EC will pass the link:https://enterprisecontract.dev/docs/ec-policies/release_policy.html#trusted_task__trusted[trusted_task.trusted] policy if all data used to build the artifact is generated from trusted tasks. (link:https://quay.io/repository/konflux-ci/tekton-catalog/pipeline-docker-build-oci-ta?tab=tags[quay.io link], link:https://github.com/konflux-ci/build-definitions/blob/main/pipelines/docker-build-oci-ta/README.md[parameter documentation])_
 
 ==== _docker-build-multi-platform-oci-ta_ [[docker-build-multi-platform-oci-ta]]
-
 This pipeline is ideal for building multi-arch container images from a Containerfile while maintaining trust after pipeline customization.
 
-_Uses `buildah` to create a multi-platform container image leveraging link:https://konflux-ci.dev/architecture/ADR/0036-trusted-artifacts.html[trusted artifacts]. It also optionally creates a source images and runs some build-time tests. This pipeline requires that the link:https://github.com/konflux-ci/multi-platform-controller[multi platform controller] is deployed and configured on your {ProductName} instance. Information is shared between tasks using OCI artifacts instead of PVCs. EC will pass the link:https://enterprisecontract.dev/docs/ec-policies/release_policy.html#trusted_task__trusted[trusted_task.trusted] policy as long as all data used to build the artifact is generated from trusted tasks. (link:https://quay.io/repository/konflux-ci/tekton-catalog/pipeline-docker-build-multi-platform-oci-ta?tab=tags[quay.io link], link:https://github.com/konflux-ci/build-definitions/blob/main/pipelines/docker-build-multi-platform-oci-ta/README.md[parameter documentation])_
+_Uses `buildah` to create a multi-platform container image leveraging link:https://konflux-ci.dev/architecture/ADR/0036-trusted-artifacts.html[trusted artifacts]. It also optionally creates a source images and runs some build-time tests. This pipeline requires that the link:https://github.com/konflux-ci/multi-platform-controller[multi platform controller] is deployed and configured on your {ProductName} instance. Information is shared between tasks using OCI artifacts instead of PVCs. EC will pass the link:https://enterprisecontract.dev/docs/ec-policies/release_policy.html#trusted_task__trusted[trusted_task.trusted] policy if all data used to build the artifact is generated from trusted tasks. (link:https://quay.io/repository/konflux-ci/tekton-catalog/pipeline-docker-build-multi-platform-oci-ta?tab=tags[quay.io link], link:https://github.com/konflux-ci/build-definitions/blob/main/pipelines/docker-build-multi-platform-oci-ta/README.md[parameter documentation])_
 
 ==== _fbc-builder_ [[fbc-builder]]
 

docs/modules/ROOT/pages/advanced-how-tos/managing-multiple-versions.adoc

@@ -147,7 +147,7 @@ Here are specific examples for how to clean up and use the YAML for certain reso
 *** `spec.application`
 *** `spec.componentName`
 *** `source.git.revision`
-** The `build.appstudio.openshift.io/status` annotation is in place to make the UI present the component's pipeline as customized. It's not mandatory if you can ignore the pipeline status being misrepresented in the UI. Note that this annotation's value needs to contain a reference to a merged PR that added the PaC pipeline files. There is no harm in having multiple components reference the same PR, as long as the `pac.component.appstudio.openshift.io/finalizer` finalizer is not added to the component's finalizers list.
+** The `build.appstudio.openshift.io/status` annotation is in place to make the UI present the component's pipeline as customized. It's not mandatory if you can ignore the pipeline status being misrepresented in the UI. Note that this annotation's value needs to contain a reference to a merged PR that added the PaC pipeline files. There is no harm in having multiple components reference the same PR, if the `pac.component.appstudio.openshift.io/finalizer` finalizer is not added to the component's finalizers list.
 * For *ImageRepository* resources:
 ** The labels referring to the owning component and application should probably contain variable references.
 ** To allow for correct ownership configuration between Component and ImageRepository resources, every component that has its built image pushed to the default registry organization that is managed automatically by {ProductName} needs to have a dedicated ImageRepository resource. This implies each component has its own container image repository.
@@ -231,7 +231,7 @@ The following limitations exist in the current controller implementation and are
 ** The *ProjectDevelopmentStream*, *ProjectDevelopmentStreamTemplate* or the *Project* resources that generated the resource are modified
 * A *ProjectDevelopmentStream* that isn't referring a template may be modified to refer to a template. Similarly, the template *ProjectDevelopmentStream* it's referring to may be changed. In both those cases, resources owned by the *ProjectDevelopmentStream* but not defined by the new template do not get deleted.
 
-== Troubleshooting 
+== Troubleshooting
 
 * When a *ProjectDevelopmentStream* that refers to a
   *ProjectDevelopmentStreamTemplate* is created or modified, and the resources

docs/modules/ROOT/pages/getting-started/index.adoc

@@ -2,7 +2,7 @@
 
 {ProductName} is a platform that helps teams develop applications. How you use {ProductName} depends on what role you have on your team. Konflux users generally fall into one of two categories:
 
-* Platform Engineers (PEs): These are the people whose job isn't to engineer applications, but to make it possible for others to do so. They usually own the instance of {ProductName}. They manage that instance and its users.   
+* Platform Engineers (PEs): These are the people whose job isn't to engineer applications, but to make it possible for others to do so. They usually own the instance of {ProductName}. They manage that instance and its users.
 * Developers:  These are the people who engineer applications for their organization. They are the typical users of {ProductName}, who productize their software with it.
 
 Depending on your role, read whichever following section applies best to you, to get more information and links to further documentation.
@@ -11,18 +11,18 @@ Depending on your role, read whichever following section applies best to you, to
 
 Before anyone can use it, you need to link:https://github.com/konflux-ci/konflux-ci?tab=readme-ov-file#konflux-ci[install {ProductName}].
 //Add xref for add users and assigning them
-After installing {ProductName}, you can add users and assign them to a {ProductName} workspace. We use {ProductName} workspaces for role-based access control (RBAC). 
+After installing {ProductName}, you can add users and assign them to a {ProductName} workspace. We use {ProductName} workspaces for role-based access control (RBAC).
 
 == For developers
 
 The purpose of {ProductName} is to help your applications get out into the world. Be aware that, in {ProductName}, we specifically define an application as one or more components that run together. And a component is an image built from a source repository.
 
-To access {ProductName}, your PE needs to give you the URL to your team's instance and your user credentials. Once you have that access, you can use {ProductName} to do a lot of different things. But the actions you can take generally fall into 3 key categories:
+To access {ProductName}, your PE needs to give you the URL to your team's instance and your user credentials. Once you have that access, you can use {ProductName} to do many different things. But the actions you can take generally fall into 3 key categories:
 
 //Add xrefs for each of these bullets
 . *Build:* as mentioned, to form an application, you build its components as images from a repository. While building, {ProductName} also runs certain checks against those images and their source repository.
-. *Test:* bring components together and test them as a whole application. 
-. *Release:* transfer ownership of your application to somewhere outside of {ProductName}, like a container registry. 
+. *Test:* bring components together and test them as a whole application.
+. *Release:* transfer ownership of your application to somewhere outside of {ProductName}, like a container registry.
 
 
 

docs/modules/ROOT/pages/how-tos/configuring/component-nudges.adoc

@@ -1,6 +1,6 @@
 = Defining component relationships
 
-When a workspace includes multiple components, their repositories might contain references to image builds of another component. For instance, an application might include multiple child components that, using a Dockerfile `FROM` clause, reference the image build of a common parent. Or, a component might reference image builds from another application altogether. OpenShift operators, for example, often have references to several components across applications.
+When a workspace includes multiple components, their repositories might contain references to image builds of another component. For example, an application might include multiple child components that, using a Dockerfile `FROM` clause, reference the image build of a common parent. Or, a component might reference image builds from another application altogether. OpenShift operators, for example, often have references to several components across applications.
 
 In such instances, whenever you build a new image of the common parent component, you need to update the references to it. Specifically, you need to copy and paste the pullspec and image digest of that new image to your other source repositories. This process is tedious and error-prone.
 
@@ -43,7 +43,7 @@ Currently, applications with only one component do not have the option to define
 . On any tab, use the *Actions* drop-down menu to select *Define component relationships*.
 .. Alternatively, go to the *Components* tab and select the *Define component relationships*.
 . In the *Component relationships* window, select one component from the *Select a component* drop-down menu.
-. Select *Nudges* or *Is nudged by*, depending on the relationship you wish to define.
+. Select *Nudges* or *Is nudged by*, depending on the relationship you want to define.
 
 +
 [NOTE]