openshift/openshift-docs
1
0
Fork 0
mirror of https://github.com/openshift/openshift-docs.git synced 2026-02-06 06:46:26 +01:00
Code Issues Releases Activity

Integrated definitions with concepts

Browse Source
This commit is contained in:
harshcasper
2021-04-15 15:01:50 +05:30
committed by openshift-cherrypick-robot
parent 5ed0155918
commit 57efc326fa
8 changed files with 9 additions and 37 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
cicd/pipelines/understanding-openshift-pipelines.adoc
View File

@@ -7,7 +7,6 @@ include::modules/pipelines-document-attributes.adoc[]
toc::[]
:FeatureName: OpenShift Pipelines
include::modules/technology-preview.adoc[leveloffset=+1]
{pipelines-title} is a cloud-native, continuous integration and continuous delivery (CI/CD) solution based on Kubernetes resources. It uses Tekton building blocks to automate deployments across multiple platforms by abstracting away the underlying implementation details. Tekton introduces a number of standard Custom Resource Definitions (CRDs) for defining CI/CD pipelines that are portable across Kubernetes distributions.
@@ -23,11 +22,8 @@ include::modules/technology-preview.adoc[leveloffset=+1]
* You can use {pipelines-title} to build images with Kubernetes tools such as Source-to-Image (S2I), Buildah, Buildpacks, and Kaniko that are portable across any Kubernetes platform.
* You can use the {product-title} Developer Console to create Tekton resources, view logs of Pipeline runs, and manage pipelines in your {product-title} namespaces.
//Main Concept Topic
include::modules/op-pipelines-concepts.adoc[leveloffset=+1]
[id="op-detailed-concepts"]
== Detailed OpenShift Pipeline Concepts
== OpenShift Pipeline Concepts
This guide provides a detailed view of the various Pipeline concepts.
//About Tasks

2
modules/op-about-pipelinerun.adoc
View File

@@ -5,7 +5,7 @@
[id="about-pipelinerun_{context}"]
= PipelineRun
A _PipelineRun_ instantiates a Pipeline for execution with specific inputs, outputs, and execution parameters on a cluster. A corresponding TaskRun is created for each Task automatically in the PipelineRun.
A _PipelineRun_ is the running instance of a Pipeline. It instantiates a Pipeline for execution with specific inputs, outputs, and execution parameters on a cluster. A corresponding TaskRun is created for each Task automatically in the PipelineRun.
All the Tasks in the Pipeline are executed in the defined sequence until all Tasks are successful or a Task fails. The `status` field tracks and stores the progress of each TaskRun in the PipelineRun for monitoring and auditing purpose.

2
modules/op-about-pipelines.adoc
View File

@@ -5,7 +5,7 @@
[id="about-pipelines_{context}"]
= Pipelines
A _Pipeline_ is a collection of `Task` resources arranged in a specific order of execution. You can define a CI/CD workflow for your application using pipelines containing one or more tasks.
A _Pipeline_ is a collection of `Task` resources arranged in a specific order of execution. They are executed to construct complex workflows that automate the build, deployment and delivery of applications. You can define a CI/CD workflow for your application using pipelines containing one or more tasks.
A `Pipeline` resource definition consists of a number of fields or attributes, which together enable the pipeline to accomplish a specific goal. Each `Pipeline` resource definition must contain at least one `Task` resource, which ingests specific inputs and produces specific outputs. The pipeline definition can also optionally include _Conditions_, _Workspaces_, _Parameters_, or _Resources_ depending on the application requirements.

4
modules/op-about-taskrun.adoc
View File

@@ -5,9 +5,9 @@
[id="about-taskrun_{context}"]
= TaskRun
A _TaskRun_ instantiates a Task for execution with specific inputs, outputs, and execution parameters on a cluster. It can be invoked on its own or as part of a PipelineRun.
A _TaskRun_ instantiates a Task for execution with specific inputs, outputs, and execution parameters on a cluster. It can be invoked on its own or as part of a PipelineRun for each Task in a pipeline.
A Task consists of one or more Steps that execute container images, and each container image performs a specific piece of build work. A TaskRun executes the Steps in a Task in the specified order, until all Steps execute successfully or a failure occurs.
A Task consists of one or more Steps that execute container images, and each container image performs a specific piece of build work. A TaskRun executes the Steps in a Task in the specified order, until all Steps execute successfully or a failure occurs. A TaskRun is automatically created by a PipelineRun for each Task in a Pipeline.
The following example shows a TaskRun that runs the `apply-manifests` Task with the relevant input parameters:
[source,yaml]

4
modules/op-about-tasks.adoc
View File

@@ -5,9 +5,9 @@
[id="about-tasks_{context}"]
= Tasks
_Tasks_ are the building blocks of a Pipeline and consist of sequentially executed Steps. Tasks are reusable and can be used in multiple Pipelines.
_Tasks_ are the building blocks of a Pipeline and consists of sequentially executed steps. It is essentially a function of inputs and outputs. A Task can run individually or as a part of the pipeline. Tasks are reusable and can be used in multiple Pipelines.
_Steps_ are a series of commands that achieve a specific goal, such as building an image. Every Task runs as a pod, and each Step runs as a container within that pod. Because Steps run within the same pod, they can access the same volumes for caching files, config maps, and secrets.
_Steps_ are a series of commands that are sequentially executed by the Task and achieve a specific goal, such as building an image. Every Task runs as a pod, and each Step runs as a container within that pod. Because Steps run within the same pod, they can access the same volumes for caching files, config maps, and secrets.
The following example shows the `apply-manifests` Task.

2
modules/op-about-triggers.adoc
View File

@@ -5,7 +5,7 @@
[id="about-triggers_{context}"]
= Triggers
Use _Triggers_ in conjunction with pipelines to create a full-fledged CI/CD system where Kubernetes resources define the entire CI/CD execution. Triggers capture the external events and process them to extract key pieces of information. Mapping this event data to a set of predefined parameters triggers a series of tasks that can then create and deploy Kubernetes resources and instantiate the pipeline.
Use _Triggers_ in conjunction with pipelines to create a full-fledged CI/CD system where Kubernetes resources define the entire CI/CD execution. Triggers capture the external events, such as a Git pull request, and process them to extract key pieces of information. Mapping this event data to a set of predefined parameters triggers a series of tasks that can then create and deploy Kubernetes resources and instantiate the pipeline.
For example, you define a CI/CD workflow using {pipelines-title} for your application. The pipeline must start for any new changes to take effect in the application repository. Triggers automate this process by capturing and processing any change event and by triggering a pipeline run that deploys the new image with the latest changes.

2
modules/op-about-workspace.adoc
View File

@@ -10,7 +10,7 @@
It is recommended that you use Workspaces instead of PipelineResources in OpenShift Pipelines, as PipelineResources are difficult to debug, limited in scope, and make Tasks less reusable.
====
Workspaces declare shared storage volumes that a Task in a Pipeline needs at runtime. Instead of specifying the actual location of the volumes, Workspaces enable you to declare the filesystem or parts of the filesystem that would be required at runtime. You must provide the specific location details of the volume that is mounted into that Workspace in a TaskRun or a PipelineRun. This separation of volume declaration from runtime storage volumes makes the Tasks reusable, flexible, and independent of the user environment.
Workspaces declare shared storage volumes that a Task in a Pipeline needs at runtime to receive input or provide output. Instead of specifying the actual location of the volumes, Workspaces enable you to declare the filesystem or parts of the filesystem that would be required at runtime. A Task or Pipeline declares the Workspace and you must provide the specific location details of the volume. It is then mounted into that Workspace in a TaskRun or a PipelineRun. This separation of volume declaration from runtime storage volumes makes the Tasks reusable, flexible, and independent of the user environment.
With Workspaces, you can:

24
modules/op-pipelines-concepts.adoc
View File

@@ -1,24 +0,0 @@
// Module included in the following assemblies:
//
// * openshift_pipelines/understanding-openshift-pipelines.adoc
[id='op-pipelines-concepts_{context}']
= {pipelines-title} concepts
{pipelines-title} provide a set of standard Custom Resource Definitions (CRDs) that act as the building blocks from which you can assemble a CI/CD pipeline for your application.
Task:: A Task is the smallest configurable unit in a Pipeline. It is essentially a function of inputs and outputs that form the Pipeline build. It can run individually or as a part of a Pipeline. A Pipeline includes one or more Tasks, where each Task consists of one or more Steps. Steps are a series of commands that are sequentially executed by the Task.
Pipeline:: A Pipeline consists of a series of Tasks that are executed to construct complex workflows that automate the build, deployment, and delivery of applications. It is a collection of PipelineResources, parameters, and one or more Tasks. A Pipeline interacts with the outside world by using PipelineResources, which are added to Tasks as inputs and outputs.
PipelineRun:: A PipelineRun is the running instance of a Pipeline. A PipelineRun initiates a Pipeline and manages the creation of a TaskRun for each Task being executed in the Pipeline.
TaskRun:: A TaskRun is automatically created by a PipelineRun for each Task in a Pipeline. It is the result of running an instance of a Task in a Pipeline. It can also be manually created if a Task runs outside of a Pipeline.
Workspace:: A Workspace is a storage volume that a Task requires at runtime to receive input or provide output. A Task or Pipeline declares the Workspace, and a TaskRun or PipelineRun provides the actual location of the storage volume, which mounts on the declared Workspace. This makes the Task flexible, reusable, and allows the Workspaces to be shared across multiple Tasks.
Trigger:: A Trigger captures an external event, such as a Git pull request and processes the event payload to extract key pieces of information. This extracted information is then mapped to a set of predefined parameters, which trigger a series of tasks that may involve creation and deployment of Kubernetes resources. You can use Triggers along with Pipelines to create full-fledged CI/CD systems where the execution is defined entirely through Kubernetes resources.
Condition:: A Condition refers to a validation or check, which is executed before a Task is run in your Pipeline. Conditions are like `if` statements which perform logical tests, with a return value of `True` or `False`. A Task is executed if all Conditions return `True`, but if any of the Conditions fail, the Task and all subsequent Tasks are skipped. You can use Conditions in your Pipeline to create complex workflows covering multiple scenarios.
//image::openshift_pipelines_architecture.png[{pipelines-title} Architecture]