diff --git a/_data/home-content.yml b/_data/home-content.yml index ed0f1ff8..414fbd74 100644 --- a/_data/home-content.yml +++ b/_data/home-content.yml @@ -38,7 +38,24 @@ localurl: /docs/runtime/monitor-manage-runtimes/ - title: Git Source management localurl: /docs/runtime/git-sources/ - + +- title: Pipelines + icon: images/home-icons/pipeline.svg + url: '' + links: + - title: Create pipelines + localurl: /docs/pipelines/create-pipelines/ + - title: Manage pipelines + localurl: /docs/pipelines/managing-pipelines/ + - title: Manage workflows + localurl: /docs/pipelines/workflows/ + - title: Sharing file systems + localurl: /docs/pipelines/sharing-file-system/ + - title: Selectors for concurrency synchronization + localurl: /docs/pipelines/conccurency-limit/ + - title: Create artifact repository + localurl: /docs/pipelines/configure-artifact-repository/ + - title: Administration icon: images/home-icons/administration.svg diff --git a/_data/nav.yml b/_data/nav.yml index 34d2d0e6..b0b9c4dc 100644 --- a/_data/nav.yml +++ b/_data/nav.yml @@ -46,7 +46,22 @@ - title: Git Source management url: "/git-sources" - +- title: Pipelines + url: "/pipelines" + pages: + - title: Create pipelines + url: "/create-pipelines" + - title: Manage pipelines + url: "/managing-pipelines" + - title: Manage workflows + url: "/workflows" + - title: Sharing file systems + url: "/sharing-file-system" + - title: Selectors for concurrency synchronization + url: "/conccurency-limit" + - title: Create artifact repository + url: "/configure-artifact-repository" + - title: Administration url: "/administration" pages: diff --git a/_docs/administration/git-tokens.md b/_docs/administration/git-tokens.md new file mode 100644 index 00000000..15eeb067 --- /dev/null +++ b/_docs/administration/git-tokens.md @@ -0,0 +1,65 @@ +--- +title: "Git tokens" +description: "" +group: administration +toc: true +--- + + + +Codefresh requires two types of Git tokens for authentication: +* A token per runtime (Git runtime token) +* A personal access token for each runtime, unique to every user (Git user token) + +You can update expired, revoked, or invalid Git runtime and personal user tokens. + +### Git runtime tokens +The Git runtime token is required to provision Codefresh runtimes. The Git runtime token is specific to a runtime, and is mandatory for runtime installation. +An expired, revoked, or invalid Git runtime token is flagged by a notification in the UI. You can then generate a new Git runtime token from your Git provider, and update it in Codefresh. + +#### Git runtime token permissions +Git runtime tokens need both repo and admim repo access to create webhooks for Git events. + +{% include + image.html + lightbox="true" + file="/images/getting-started/quick-start/quick-start-git-event-permissions.png" + url="/images/getting-started/quick-start/quick-start-git-event-permissions.png" + alt="Permissions for Git runtime token" + caption="Permissions for Git runtime token" + max-width="30%" + %} + +#### How to update a Git runtime token +Update Git runtime tokens when needed. + +**Before you begin** +* Generate a new runtime token with the correct permissions + +**How to** + +1. In the Codefresh UI, when you see a notification, select **[Update Token]**. + In the **Runtimes** page, runtimes with invalid tokens are prefixed by the key icon. Mouse over shows invalid token. +1. Select the runtime, and then on the top-right of the page, select and then **+Add Token**. +1. Paste the generated personal access token. +1. If there are no validation errors, select **Add**. + +### Git personal tokens +The Git personal token is a user-specific personal access token per provisioned runtime. Unique to each user, it is required to authenticate Git-based actions per runtime in Codefresh. +If not provided during runtime installation, every user can add a personal access token after installation through User Settings, using either OAuth to authorize access or generate one from GitHub. + +If users have access to multiple runtimes, they can use the same personal access token for all the runtimes. +> Users must configure the token for each runtime. + +#### Git personal token permissions +Git personal tokens need repo access for commits and other actions. + +{% include + image.html + lightbox="true" + file="/images/getting-started/github-pat.png" + url="/images/getting-started/github-pat.png" + alt="Permissions for Git personal token" + caption="Permissions for Git personal token" + max-width="30%" + %} diff --git a/_docs/deployment/app-dashboard 2.md b/_docs/deployment/app-dashboard 2.md new file mode 100644 index 00000000..493f4647 --- /dev/null +++ b/_docs/deployment/app-dashboard 2.md @@ -0,0 +1,375 @@ +--- +title: "Applications dashboard" +description: "" +group: deployment +toc: true +--- + +View, monitor, and analyze deployments across your enterprise in the Applications dashboard. As a one-stop shop for Argo Rollouts and Argo CD in Codefresh, the Applications dashboard delivers on the challenge of keeping track of deployments, whatever the frequency and scale. A wide range of filters, enriched CI and CD information, provide full traceability and visibility to continuous deployments. + +Here are some insights you can derive from the Applications dashboard: +* Visibility into deployments from all the clusters associated with the provisioned runtimes, in-cluster and managed +* Timeline on current and historical deployments +* Enriched CI information for deployments, including links to container images, Git hashes correlated with feature requests, Jira issues +* Microservices deployed by the application +* Hierarchical view of the resources in the application in the Current State + + + +### Applications main view + +The main view shows all deployed applications, sorted by the most recent deployments, by default. + +Here is an example of the main page in the Applications dashboard. + + {% include +image.html +lightbox="true" +file="/images/applications/app-dashboard-main-view.png" +url="/images/applications/app-dashboard-main-view.png" +alt="Applications Dashboard" +caption="pplications Dashboard" +max-width="30%" +%} + +#### Application inventory and state + +The application state snapshot shows at a glance both the total number of applications that are deployed and their breakdown according to state. + +> The state snapshot works also as a quick filter. Selecting a state filters the application view by that state. + +#### Filters and favorites +Similar to other dashboards, the Applications dashboard also offers a set of filters designed to bring you the information you need as quickly as possible. +You can also mark applications as favorites to focus on the applications of interest. + +**Filters** + +Filters are divided into frequently used and advanced filters. +* Frequently-used filters: Available at the top of the dashboard. These filters support multi-selection, and results are based on an OR relationship within the same filter with multiple options, and an AND relationship between filters. +* Advanced filters: Available on selecting **More Filters**. These filters include application type, health, and labels. + + * Application type + Applications and ApplicationSet + + * Health filters + The built-in Argo CD set of health filters. + For detailed information, see the official documentation on [Health sets](https://argo-cd.readthedocs.io/en/stable/operator-manual/health/){:target="\_blank"}. + + + * Labels + The K8s labels defined for the applications. The list displays labels of _all_ the applications, even if you have applied filters. + + To see the available labels, select **Add**, and then select the required label and one or more values. + To filter by the labels, select **Add** and then **Apply**. + + For detailed information, see the official documentation on [Labels and selectors](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/){:target="\_blank"}. + + {% include +image.html +lightbox="true" +file="/images/applications/app-dashboard-adv-filters.png" +url="/images/applications/app-dashboard-adv-filters.png" +alt="Advanced filters in Applications Dashboard" +caption="Advanced filters in Applications Dashboard" +max-width="30%" +%} + + +**'Favorite' applications** + +Mark applications as favorites, and view them with a click. +* Select the {::nomarkdown}{:/} to the left of the application name to mark it as a favorite. +* To view only favorites, on the filters bar, select {::nomarkdown}{:/}. + + + +#### Deployment type +Applications are displayed according to their deployment type which can be one of the following: +* Applications + Standalone applications. For detailed information, see the official documentation on [Applications](https://argo-cd.readthedocs.io/en/stable/operator-manual/declarative-setup/#applications){:target="\_blank"}. + + {% include +image.html +lightbox="true" +file="/images/applications/apps-standalone.png" +url="/images/applications/apps-standalone.png" +alt="Standalone applications in Applications Dashboard" +caption="Standalone applications in Applications Dashboard" +max-width="30%" +%} + +* Application set + Based on the Argo CD's ApplicationSet CRD, where several applications are always deployed as a set. For detailed information, see the official documentation on [Generating Applications with ApplicationSet](https://argo-cd.readthedocs.io/en/stable/user-guide/application-set/){:target="\_blank"}. + + {% include +image.html +lightbox="true" +file="/images/applications/app-appset-model.png" +url="/images/applications/app-appset-model.png" +alt="Application Set in Applications Dashboard" +caption="Application Set in Applications Dashboard" +max-width="30%" +%} + +* App-of-apps + In this deployment model, the parent application deploys a set of child applications. For detailed information, see the official documentation on [App of Apps](https://argo-cd.readthedocs.io/en/stable/operator-manual/declarative-setup/#app-of-apps){:target="\_blank"}. + +{% include +image.html +lightbox="true" +file="/images/applications/app-appofapps-model.png" +url="/images/applications/app-appofapps-model.png" +alt="App of Apps in Applications Dashboard" +caption="App of Apps in Applications Dashboard" +max-width="30%" +%} + + +### Application timeline +The Timeline tab displays the history of deployments for the selected application, sorted by the most recent update (default), and enriched with image, Pull Request (PR), Jira issues, and commit information, for each deployment. + +Each application displays up to ten of the most recent deployments through deployment cards. + +{% include +image.html +lightbox="true" +file="/images/applications/dashboard-timeline-main.png" +url="/images/applications/dashboard-timeline-main.png" +alt="Applications Dashboard: Timeline tab" +caption="Applications Dashboard: Timeline tab" +max-width="30%" +%} + + + +**Filters** + +View the subset of deployments of interest to you. Filter by Date range, PRs, issues, committers, and more. + +**Deployment chart** + +View day-to-day deployment information for the selected time period. The deployment chart is useful to get information on historical deployments, as deployment cards are shown for up to ten of the most recent deployments. + +* To jump to a specific deployment, click the dot on the chart that represents the deployment. +* To see GitOps details, mouse over the dot that represents the deployment. + +{% include +image.html +lightbox="true" +file="/images/applications/apps-historical-deployment.png" +url="/images/applications/apps-historical-deployment.png" +alt="Applications Dashboard: Deployment chart" +caption="Applications Dashboard: Deployment chart" +max-width="30%" +%} + +**Deployment entries** + +Each deployment entry displays the complete history of that deployment, by Git hash, Kubernetes services, and Argo applications: + +{% include +image.html +lightbox="true" +file="/images/applications/app-dashboard-time-expanded-card.png" +url="/images/applications/app-dashboard-time-expanded-card.png" +alt="Applications Dashboard: Deployment entry in Timeline tab" +caption="Applications Dashboard: Deployment entry in Timeline tab" +max-width="30%" +%} + +* The **CI Builds** showing the image(s) created or updated during deployment. Click to see the **Images** view in a browser window. +* The **Pull Request (PRs)** used for the commit. +* The Jira **Issues** the PR aims to resolve or has resolved, with the current status. +* The **Committer** who made the changes. +* The Kubernetes **Services** updated during the deployment, according to the Argo rollout strategy, and the current rollout status. + The example above shows the rollouts according to the canary rollout strategy. The blue line shows the progress of rollout with the current step versus the total number of steps. + Expanding the live version deployment shows the number of replicas currently deployed, as green circles. +* The Argo **Applications** updated during this deployment. + + +### Application services +The Services tab for an application shows the K8s services for each deployment of the application. +Each service shows the number of replicas, the endpoint IP, the labels that reference the application, and the health status. + +For more information, see the official documentation on [Services](https://kubernetes.io/docs/concepts/services-networking/service/){:target="\_blank"}. + +{% include +image.html +lightbox="true" +file="/images/applications/apps-dashboard-services.png" +url="/images/applications/apps-dashboard-services.png" +alt="Applications Dashboard: Services tab" +caption="Applications Dashboard: Services tab" +max-width="30%" +%} + +### Application Current State +The Current State tab for an application shows the live state of the application and the application's resources (Kubernetes objects) in the cluster in Tree and List view formats. +* Tree view (default): A hierarchical, interactive visualization of the application and its resources. Useful for complex deployments with multiple clusters and large numbers of resources. + +* List View: A representation of application's resources, sorted by the Last Update. + +> Filters are shared between both views, and when applied are retained when switching between views. + +Current State insights and actions: +* Health status: Reflects Argo CD's built-in health checks and status for the Application resource and Kubernetes objects. For more information, see [Argo CD Resource Health](https://argo-cd.readthedocs.io/en/stable/operator-manual/health/){:target="\_blank"}. +* Sync state: Desired state in Git versus live state in cluster. +* Resource details: High-level information on mouse-over, and detailed manifest and log information on selecting the resource. + +The icon for a resource node identifies the type of Kubernetes resource it represents. For general information on K8s resources, see [Working with Kubernetes objects](https://kubernetes.io/docs/concepts/overview/working-with-objects/){:target="\_blank"}. + +#### Current State Tree view +Here is an example of an application's Current State in Tree view. The root node, the application itself, is expanded to display all its resources. +The Tree view is designed to impart key information at a glance. + + +{% include +image.html +lightbox="true" +file="/images/applications/current-state-tree-app-in-progress.png" +url="/images/applications/current-state-tree-app-in-progress.png" +alt="Current State: Tree view" +caption="Current State: Tree view" +max-width="50%" +%} + +##### Health status +Identified by the border around the node and the resource-type icon. The health statuses tracked are [Argo CD's set of health checks](https://argo-cd.readthedocs.io/en/stable/operator-manual/health/). + +> The Unknown health status is assigned to resources that do not have a health status and are not tracked in Argo CD. `ConfigMaps` for example. + +{: .table .table-bordered .table-hover} +| Health status | Display in Tree view | +| -------------- | ----------| ----------| +| **Healthy** | {::nomarkdown}{:/} | +| **Degraded** | {::nomarkdown}{:/} | +| **Suspended** | {::nomarkdown}{:/} | +| **Missing** | {::nomarkdown}{:/} | +| **Progressing** | {::nomarkdown}{:/} | +| **Unknown** | {::nomarkdown}{:/} | + + + +##### Sync state +Identified by the icon to the left of the resource name. For information on sync options + +{: .table .table-bordered .table-hover} +| Sync state | Display in Tree view | +| -------------- | ---------- | +| **Synced** | {::nomarkdown}{:/} | +| **Syncing** | {::nomarkdown}{:/} | +| **Out-of-Sync** | {::nomarkdown}{:/} | +| **Unknown** | {::nomarkdown}{:/} | + + +##### Resource inventory +At the bottom left is the Resource inventory, summarizing the aggregated count for each resource type in the application. Syncing and Out-of-Sync resources are bucketed separately for visibility and quick access. + +**Click-filters** +In the resource inventory, selecting a Syncing or Out-of-Sync resource type, filters the Current State by that resource type and sync state. +These filters are automatically reflected in the default filter list for both Tree and List views. +Here's an example of an application with out-of-sync resources, and the result on selecting an out-of-sync resource type. + + +{% include +image.html +lightbox="true" +file="/images/applications/current-state-tree-resource-list.png" +url="/images/applications/current-state-tree-resource-list.png" +alt="Current State Tree view: Resource inventory" +caption="Current State Tree view: Resource inventory" +max-width="50%" +%} + +{% include +image.html +lightbox="true" +file="/images/applications/current-state-tree-resource-list-filtered.png" +url="/images/applications/current-state-tree-resource-list-filtered.png" +alt="Current State Tree view: Resource inventory filtered by out-of-sync service" +caption="Current State Tree view: Resource inventory filtered by out-of-sync service" +max-width="50%" +%} + +##### Resource info +Mouse over to see a tooltip for the resource. For detailed information, select the resource; see [Detailed resource information](#detailed-resource-information) in this article. + +{% include +image.html +lightbox="true" +file="/images/applications/current-state-resource-summary.png" +url="/images/applications/current-state-resource-summary.png" +alt="Current State Tree view: Resource tooltip" +caption="Current State Tree view: Resource tooltip" +max-width="50%" +%} + +##### Search resources +Quickly find a resource by typing the resource name in the search field, and pressing Enter to navigate to the next result. Search results have a different border for identification. + +{% include +image.html +lightbox="true" +file="/images/applications/current-state-tree-search.png" +url="/images/applications/current-state-tree-search.png" +alt="Current State Tree view: Search resources" +caption="Current State: Search resources" +max-width="50%" +%} + +#### Current State List view +Here is an example of the Current State in List view. + +{% include +image.html +lightbox="true" +file="/images/applications/apps-current-state.png" +url="/images/applications/apps-current-state.png" +alt="Applications Dashboard: List view of Current State" +caption="Applications Dashboard: List view of Current State" +max-width="50%" +%} + + +#### Detailed resource information +Selecting a resource, in either Tree or List view, shows resource manifests and logs, based on the resource type you selected. Endpoints for example show only manifests, while pods show both manifests and logs. + + +**Summary** + +{% include +image.html +lightbox="true" +file="/images/applications/current-state-resource-summary.png" +url="/images/applications/current-state-resource-summary.png" +alt="Current State Tree view: Resource tooltip" +caption="Current State Tree view: Resource tooltip" +max-width="50%" +%} + +* Desired and Live states: + * Managed resources, meaning those that are stored in Git repositories and use Git as the single source of truth, show both the Desired state and the Live state. + If there are discrepancies between them, the Diff view is displayed, highlighting the differences in both versions for comparison. + * Resources that are not stored in Git but live in the cluster, show only the Live state. + * +* Share resource details: Copy the URL and send to others in your organization to share the resource details for collaborative review and analysis. Pasting the URL in a browser opens to the same resource view. +* Hide Managed Fields: When selected, hides managed-field information from the manifest. Managed-fields show information on which field manager manages the field, after Kubernetes introduced `Server Side Apply`. For more information, see [Field Management](https://kubernetes.io/docs/reference/using-api/server-side-apply/#field-management){:target="\_blank"}. + + +**Logs** + +{% include +image.html +lightbox="true" +file="/images/applications/current-state-logs.png" +url="/images/applications/current-state-logs.png" +alt="Current State: Logs for resource" +caption="Current State: Logs for resource" +max-width="50%" +%} + +* Search: Free-text search for any string in the log, using the next and previous buttons to navigate between the results, or Enter for sequential navigation. +* Wrap: Enable/disable line wrapping +* Download: Download the complete log into a text file for offline viewing and analysis. + + diff --git a/_docs/pipelines/concurrency-limit.md b/_docs/pipelines/concurrency-limit.md new file mode 100644 index 00000000..780a53a4 --- /dev/null +++ b/_docs/pipelines/concurrency-limit.md @@ -0,0 +1,166 @@ +--- +title: "Selectors for concurrency synchronization" +description: "" +group: pipelines +toc: true +--- + + +Argo Workflows has a synchronization mechanism to limit parallel execution of specific workflows or templates within workflows, as required. +The mechanism enforces this with either semaphore or mutex synchronization configurations. For detailed information, see [Synchronization](https://argoproj.github.io/argo-workflows/synchronization/). + +Codefresh supports an additional level of concurrency synchronization, with _selectors_, for both workflows and templates. + +Selectors enable access to all workflow properties such as `annotations`, `labels`, or `parameters` using Go template formats. Selector-based concurrency configurations support parallel executions of workflows or templates within workflows. And equally important, selectors work with both semaphore and mutex synchronization configurations. + +This article has examples for semaphore synchronization configurations. + +Semaphore synchronization is configured in the `ConfigMap`, which is referenced from workflows or templates within workflows. + +Here's an example of the `ConfigMap` with the concurrency definition: +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: semaphore-config +data: + workflow: "1" +``` + +### Concurrency selector definitions +A concurrency synchronization selector is defined through a `name`-`template` pair in workflows or templates: + +* The `name` is any meaningful/logical name that describes the selector. For example, Git repo or branch. +* The `template` is the parameter mapping for the name, that is resolved to the selector value when the pipeline is run. The parameter mapping format must confirm to Sprig templates. For information on Go templates and Sprig functions, see the [Go template package documentation](https://pkg.go.dev/text/template){:target="\_blank"}, and [Sprig Function Documentation](http://masterminds.github.io/sprig/){:target="\_blank"}. + For example: + {% highlight yaml %}{% raw %}{{ workflow.parameters.REPO_OWNER }}/{{ workflow.parameters.REPO_NAME }}{% endraw %}{% endhighlight %} or {% highlight yaml %}{% raw %}{{ workflow.parameters.GIT_BRANCH }}{% endraw %}{% endhighlight %} + +Selectors are added to the `synchronization` section, under `selectors`, as in the sample YAML below. + +{% highlight yaml %} +{% raw %} +apiVersion: argoproj.io/v1alpha1 +kind: Workflow +metadata: + generateName: synchronization-wf-2 +spec: + entrypoint: whalesay + arguments: + parameters: + - name: REPO_OWNER + value: denis-codefresh + - name: REPO_NAME + value: argo-workflows + - name: GIT_BRANCH + value: main + synchronization: + semaphore: + configMapKeyRef: + name: semaphore-config + key: workflow + selectors: + - name: repository + template: "{{ workflow.parameters.REPO_OWNER }}/{{ workflow.parameters.REPO_NAME }}" + - name: branch + template: "{{ workflow.parameters.GIT_BRANCH }}" + templates: + - name: whalesay + container: + image: docker/whalesay:latest + command: [sleep] + args: ["5000"] +{% endraw %} +{% endhighlight %} + + +### When and how does selector concurrency configuration work? +Let's review a viable use case for selector-based concurrency synchronization, and different scenarios to illustrate when and how it works: +* Default concurrency synchronization without selectors +* Selector concurrency synchronization resolving to the _same `template`_ values +* Selector concurrency synchronization resolving to _different `template`_ values + +**Use case** + +We have two workflows, `synchronization-wf-1` and `synchronization-wf-2`. + +Both workflows commit to the _same Git repo_, but to _different branches in the repo_. The first workflow commits to the `main` branch, and the second workflow commits to a `feature` branch. When there are commits to the `main` and `feature` branches, we want the workflows to run in parallel. + +#### Default concurrency synchronization +Both workflows have the same default values for the arguments, and share the same semaphore configuration and key with weight 1. + +{% include image.html + lightbox="true" + file="/images/pipeline/concurrency/concurrency-default-config.png" + url="/images/pipeline/concurrency/concurrency-default-config.png" + alt="Workflows with default concurrency configuration" + caption="Workflows with default concurrency configuration" + max-width="30%" + %} + +With the default concurrency configuration, only one workflow at a time can use the key. Meaning that while `synchronization-wf-1` is `Running`, `synchronization-wf-2` is in `Pending` status. + +#### Selector concurrency synchronization resolving to same template values +Here are the same workflows, `synchronization-wf-1` and `synchronization-wf-2`, this time configured with _selector_ concurrency. +Both workflows share the same semaphore key with a weight of 1. +Both workflows also _use the same set of selectors_. As you can see in the image below, the Git repo and the Git branch arguments have the same values in both. + +{% include image.html + lightbox="true" + file="/images/pipeline/concurrency/selector-concurrency-sync.png" + url="/images/pipeline/concurrency/selector-concurrency-sync.png" + alt="Workflows with selector concurrency configuration" + caption="Workflows with selector concurrency configuration" + max-width="30%" + %} + +In this case, the selectors have no impact as the `selector templates` in both workflows resolve to the same values, resulting in the same semaphore key. +If you look at the status of both workflows, you can see that they have the same semaphore key. + +```yaml +synchronization: + semaphore: + holding: + - holders: + - synchronization-wf-6lf8b + semaphore: argo/ConfigMap/semaphore-config/workflow?repository=denis-codefresh/argo-workflows&branch=main +``` + + +#### Selector concurrency synchronization resolving to different template values + +In the third scenario, we have the same workflows, `synchronization-wf-1` and `synchronization-wf-2`, also configured with the _selector_ concurrency. +They also share the same semaphore configuration and key with weight 1. + +The difference is that in this scenario, the `selector templates` in both workflows resolve to different values, resulting in different semaphore keys for each workflow. +In `synchronization-wf-1`, the Git branch is set to `main`, and in `synchronization-wf-2`, it is set to `feature`. + +{% include image.html + lightbox="true" + file="/images/pipeline/concurrency/selector-concurrency-sync-git-branch.png" + url="/images/pipeline/concurrency/selector-concurrency-sync-git-branch.png" + alt="Workflows with selector concurrency and different Git branches" + caption="Workflows with selector concurrency and different Git branches" + max-width="30%" + %} + +Now, because the workflows use different semaphore keys, both workflows run in parallel. +If you look at the status of both workflows, you can see that they have different semaphore keys. + +```yaml +synchronization: + semaphore: + holding: + - holders: + - synchronization-wf-6lf8b + semaphore: argo/ConfigMap/semaphore-config/workflow?repository=denis-codefresh/argo-workflows&branch=main +``` + +```yaml +synchronization: + semaphore: + holding: + - holders: + - synchronization-wf-8lf9b + semaphore: argo/ConfigMap/semaphore-config/workflow?repository=denis-codefresh/argo-workflows&branch=feature +``` + diff --git a/_docs/pipelines/configure-artifact-repository.md b/_docs/pipelines/configure-artifact-repository.md new file mode 100644 index 00000000..894ec98c --- /dev/null +++ b/_docs/pipelines/configure-artifact-repository.md @@ -0,0 +1,181 @@ +--- +title: "Configure artifact repository" +description: "" +group: pipelines +toc: true +--- + +To run Argo Workflows that share artifacts between steps in workflows, and view archived logs for completed workflows, configure an artifact repository. Configure any Argo-supported, S3-compatible repository, such as AWS, GCS or MinIO. + +To configure an artifact repository, do the following: + +* Create a `ConfigMap` with the specifications; for more information, see Argo Workflows documentation on [Configuring Your Artifact Repository](https://argoproj.github.io/argo-workflows/configure-artifact-repository/){:target="\_blank"} +* Configure `RBAC` permissions for the workflow controller +* Update the `serviceAccountName` to match the storage bucket +* Recreate `argo-server` pod or pods to get the permissions + +### Step 1: Create ConfigMap for artifact repository +Create a `ConfigMap` with the specs to connect to the storage bucket configured as the artifact repository, and enable pipeline logging to the same. +The settings apply to all workflows by default, unless overridden by a specific `Workflow Template` or `Workflow` resource. + + +1. Go to your Codefresh runtime installation repository: + `/apps/workflows/overlays//` +1. Create a new file entitled `artifact-repo.yaml`, and update `bucket`, `endpoint`, and `region` as needed: + +```yaml +--- +apiVersion: v1 +kind: ConfigMap +metadata: + annotations: + workflows.argoproj.io/default-artifact-repository: default-v1 + name: artifact-repositories +data: + default-v1: | + archiveLogs: true #enable pipeline logging + s3: + bucket: csdp-artifacts-us-east-1 #change as needed + endpoint: s3.amazonaws.com #change as needed + region: us-east-1 #change as needed + useSDKCreds: true +``` + +### Step 2: Define RBAC permissions for artifact repository +Grant the workflow controller sufficient permissions for S3 bucket operations. + +1. Go to the same Codefresh runtime installation repository: +`/apps/workflows/overlays/` +1. Create the `rbac.yaml` file with the permissions, changing the annotation to match the S3 storage : + +```yaml +apiVersion: v1 +kind: ServiceAccount +metadata: + name: # for example, workflow + annotations: # change below as needed + /role-arn: # example s3.amazonaws.com/role-arn = arn:aws:iam::559963890471:role/argo-workflows-s3-artifact-repo +--- +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: workflow-role +rules: +- apiGroups: + - "" + resources: + - pods + verbs: + - get + - watch + - patch +- apiGroups: + - "" + resources: + - pods/log + verbs: + - get + - watch +- apiGroups: + - "" + resources: + - pods/exec + verbs: + - create +- apiGroups: + - "" + resources: + - configmaps + verbs: + - create + - get + - update +- apiGroups: + - argoproj.io + resources: + - workflows + - workflowtemplates + verbs: + - create + - delete + - list + - get + - watch + - update + - patch +- apiGroups: + - argoproj.io + resources: + - workflowtasksets + - workflowtasksets/finalizers + verbs: + - list + - watch + - get + - update + - patch +--- +apiVersion: rbac.authorization.k8s.io/v1 +kind: RoleBinding +metadata: + name: workflow-default-binding +roleRef: + apiGroup: rbac.authorization.k8s.io + kind: ClusterRole + name: workflow-role +subjects: +- kind: ServiceAccount + name: workflow +--- +``` + + +### Step 3: Update `serviceAccountName` for artifact repository +Define the correct Service Account that with the roles and permissions for workflows to access the artifact repository. +{:start="1"} +1. Go to the same Codefresh runtime installation repository: + `/apps/workflows/overlays/` +1. Open `kustomization.yaml`. +1. Change the `annotation` and the `serviceAccountName` to be identical to those defined in `rbac.yaml`: + +```yaml +apiVersion: kustomize.config.k8s.io/v1beta1 +kind: Kustomization +namespace: lognext +patches: +- path: ingress-patch.json + target: + group: apps + kind: Deployment + name: argo-server + version: v1 +resources: + - ../../base + - ingress.yaml # created after the installation + - rbac.yaml # created earlier as part of this process + - artifact-repo.yaml # created earlier as part of this process +patchesStrategicMerge: + - | + apiVersion: v1 + kind: ServiceAccount + metadata: + name: argo-server + annotations: + /role-arn: # must be identical to annotation of the service account in rbac.yaml file + - | + apiVersion: v1 + kind: ConfigMap + metadata: + name: workflow-controller-configmap + data: + workflowDefaults: | + spec: + serviceAccountName: # must be identical to the service account name in rbac.yaml +``` + +### Step 4: Recreate `argo-server` pods to get the permissions +As the final step in configuring the artifact repository, for the `argo-server` pod or pods to have the permissions needed to access the S3 bucket, manually delete `argo-server` pods to recreate them. + +1. Wait for the configuration changes to take effect on the cluster. +1. Check the `argo-server` service account and verify that it is updated with the user-provided `annotation`. +1. Select the `argo-server-<#>` pod or pods and delete them. diff --git a/_docs/pipelines/create-pipeline.md b/_docs/pipelines/create-pipeline.md new file mode 100644 index 00000000..278b4f2a --- /dev/null +++ b/_docs/pipelines/create-pipeline.md @@ -0,0 +1,280 @@ +--- +title: "Pipeline creation" +description: "" +group: pipelines +toc: true +--- + +Delivery Pipelines are where all the CI magic happens in Codefresh. Delivery Pipelines connect Argo Workflows and Argo Events with our unique functionality to implement and optimize CI/CD flows, such as checking out code, building and testing artifacts, running unit and acceptance tests, or any customized flows you need in your enterprise. + +Codefresh integrates with Argo Workflows and Argo Events, while greatly simplifying the process of creating pipelines and triggering them to submit workflows. + + +### Delivery Pipeline concepts +Let's start by reviewing the main concepts around Codefresh Delivery Pipelines. +In Codefresh, the Delivery Pipeline is a logical entity that connects an event-source, a sensor, and a Workflow Template. + +#### Pipeline per trigger +Every sensor-trigger pair is a unique pipeline in Codefresh. The same sensor with multiple triggers creates a different pipeline for every trigger. + +#### Git-Ops permission model +Access to Git Sources and Git repositories are based on the user's write permissions, as defined in their Git provider accounts. + +#### Git Source for pipeline +The Delivery Pipeline is connected to a specific Codefresh runtime installation, and is also run on this runtime through a Git Source. + +When the pipeline is created and synced with the cluster, all manifests generated for the pipeline are stored in the Git repository. These include the sensor and event-source manifests, and the pipeline workflow template's manifest. + +#### Centralized location for Argo Event-entities +Codefresh uses Argo Events to listen to events from different sources and define the conditions that trigger the events. All entities for creating and managing an Argo Event - from the event-source and its events, the sensor and its triggers - are available in a centralized location in Codefresh. + +An intuitive selection mechanism enables you to easily select and configure each entity. Predefined variables and automated mapping to event payload makes parameterization easy. There is no need to manually create the YAML manifests for the different entities, as Codefresh automatically generates them after the entities are set up. + + +### Delivery Pipeline creation flow +Here's a high-level overview of the Delivery Pipeline creation flow. +For step-by-step instructions, see [How to: create a Delivery Pipeline]({{site.baseurl}}/docs/pipelines/create-pipeline/#how-to-create-a-delivery-pipeline). + +1. Define pipeline name and select Workflow Template to execute +1. Define default values for pipeline workflow template arguments +1. Configure trigger conditions for events +1. Generate manifests +1. Commit resource files and create pipeline + +#### Define pipeline name and select Workflow Template to execute +The Delivery Pipeline creation flow starts with defining a name for the pipeline, selecting the Git Source with the runtime, and selecting the Workflow Template to execute when the pipeline is run. You can use the Codefresh starter Workflow Template, or select an existing Workflow Template you have downloaded to a Git Source. + +Both Argo and Codefresh have examples and libraries of Workflow Templates you can use: +* For conceptual information on Argo Workflows, read the [official documentation](https://argoproj.github.io/argo-workflows/){:target="\_blank"}. +* For examples of Workflow Templates in Argo, see their [examples](https://github.com/argoproj/argo-workflows/tree/master/examples){:target="\_blank"} page. +* For a fully-certified library of ready-to-use Workflow Templates by Codefresh, see [Codefresh Hub for Argo](https://codefresh.io/argohub/){:target="\_blank"}. + +In the Delivery Pipeline wizard, we have our starter Workflow Template to use as a base, or the option to select an existing one, or copy and paste any Workflow Template, and then modify as needed. +>Important: +> If you select the starter Workflow Template or one of the example templates from the Codefresh Hub for Argo, it is converted to a standalone, independent pipeline workflow template. + > To avoid conflicts, the pipeline workflow template is not synced to the original Workflow Template. Any changes to the original starter or example Workflow Template are also not updated in the pipeline workflow template. + + + +> To share artifacts between steps in workflows, and to view archived logs for completed workflows, you must [configure an artifact repository in Codefresh]({{site.baseurl}}/docs/pipelines/configure-artifact-repository). + + + +#### Define default values for Workflow Template arguments +Workflow Template arguments are the list of arguments described in the Workflow Template, and expected to be passed to the workflow when submitted. They are displayed in the **Arguments** tab. You can define the default values for any argument here. + +{% include + image.html + lightbox="true" + file="/images/pipeline/create/pipeline-wizard-arguments-tab.png" + url="/images/pipeline/create/pipeline-wizard-arguments-tab.png" + alt="Arguments tab in Delivery Pipeline wizard" + caption="Arguments tab in Delivery Pipeline wizard" + max-width="30%" + %} + +#### Configure Trigger Conditions for events +The **Trigger Conditions** tab in the Delivery Pipeline wizard collates the requirements to set up and configure entities for Argo Events. Here you select the event-source, the event of interest, the Git repositories to listen to for the event, and the sensor trigger for the event. + +> To create a Delivery Pipeline, you must have _at least one_ Trigger Condition. + + +{% include + image.html + lightbox="true" + file="/images/pipeline/create/pipeline-wizard-trigger-tab.png" + url="/images/pipeline/create/pipeline-wizard-trigger-tab.png" + alt="Trigger Conditions tab in Delivery Pipeline wizard" + caption="Trigger Conditions tab in Delivery Pipeline wizard" + max-width="30%" + %} + +For conceptual information on Argo Events, read the [official documentation](https://argoproj.github.io/argo-events/){:target="\_blank"}. + +The Delivery Pipeline wizard guides you through selecting the event-source, the event to listen to, and the conditions to trigger the event. +Let's review the main entities in Trigger Conditions. + +**Git repositories** +For every sensor trigger condition, you can select single or multiple Git repositories to which to listen to for the event. +> Only those Git repos to which you have write-permissions are displayed. + +**Event-sources and Events** +Currently, we support GitHub as an event-source, and an extensive list of GitHub events you can select from. + +**Sensor trigger arguments** +The sensor trigger arguments are identical to the Workflow Template arguments. If Workflow Template arguments have default values, these values are displayed for the corresponding Sensor arguments as well. +> If values are defined for an argument both in the Workflow Template and in Trigger Conditions, the value defined in Trigger Conditions takes precedence. + +You can override the default values or define custom values for trigger condition arguments through _parameterization_ and _Sprig template functions for Go_. For more information, see [Parameteization for Argo Events](https://argoproj.github.io/argo-events/tutorials/02-parameterization/){:target="\_blank"}, and [Sprig Function Documentation](http://masterminds.github.io/sprig/){:target="\_blank"}. + +Argo Events uses parameterization to pass data from the event payload to the workflow submitted by the sensor trigger. But where in Argo Workflows you would need to manually define the JSON path to the data in the event payload, our Delivery Pipeline wizard automates path definitions through predefined variables. + +Every event has a specific payload and a specific list of predefined variables you can select from. You can either parameterize an argument through one or more predefined variables, or use Sprig template functions to define the values. In either case, when the manifests are generated, Codefresh replaces the variables or templated values with the actual JSON path in the event payload. + + +**Filters** +Filters create conditions for event triggers by enforcing validity constraints on when to trigger the event. For example, add a filter to a Git push event that triggers that event only on push to a particular _branch_. + +**Examples of common events and use of filters** + +Here are some examples of common Git events that are triggers to run pipelines, and when you would use filters to further control when these Git events run the pipeline. + +* Git commits which are push events +* Git pull requests (PRs), which are opened PRs + +The table below summarizes the use cases, events, and filters that control the events. + +{: .table .table-bordered .table-hover} +|#|Trigger requirement | Event | Filter | +|--| -------------- | ---------------- | -----------| +|1| On Git commit |`Commit pushed` | Implicitly on `Commit pushed` | +|2| On Git commit, _only_ when the commit is on a specific branch. This requires a filter to define the target branch. | `Commit pushed` | Implicitly on `Commit pushed`, and explicitly when `Git branch` = ``, for example, `main` | +|3| On an opened PR | `PR opened` | Implicitly on `PR opened` | +|4|On an opened PR, _only_ for a specific branch | `PR opened` | Implicitly on `PR opened`, and explicitly when `PR target branch` = ``, for example, `production` | +|5|On an opened PR, _only_ for a specific branch, and _only_ when the PR name includes the entered value| `PR opened` | Implicitly on `PR opened`, and explicitly when `PR target branch` = ``, for example, `production` and when `PR labels` = ``, for example, `cf-hotifx-xxxx`| + +Now let's review the use cases in more detail. + +#1 The `Commit pushed` event on any of the Git repos defined runs the pipeline. + +#2 The `Commit pushed` event on any of the Git repos runs the pipeline, _but only_ if the branch is `production`, and not if the branch is `staging` for example. + +#3 The `PR opened` event runs the pipeline when any PR is opened on any Git repo defined. + +#4 The `PR opened` event with the `PR Target Branch` filter runs the pipeline _only_ when the PR target branch matches the value entered. You want to run the pipeline when the PR is opened on either `master` or `production`, but not when opened on `staging` or `qa`. + +#5 The `PR opened` event with the `PR Target Branch` and `PR label` filters is a more complex scenario that runs the pipeline when a PR is opened on the target branch, but only when the PR name starts with or includes the provided value. Useful when collaborating on features or when deploying a critical fix. Both the `PR Target Branch` and `PR label` must match for the pipeline to run. The filters automatically excludes all PRs opened on the `production` branch but not matching the `PR label`, `hotfix-runtime`. + + +#### Generate manifests +Manifests are automatically generated on committing changes after defining at least one Trigger Condition. + +Manifests typically include: +* Sensor +* EventSource +* WorkflowTemplate (the pipeline workflow template) + +{% include + image.html + lightbox="true" + file="/images/pipeline/create/pipeline-wizard-resources.png" + url="/images/pipeline/create/pipeline-wizard-resources.png" + alt="Argo resources in Delivery Pipeline wizard" + caption="Argo resources in Delivery Pipeline wizard" + max-width="30%" + %} +#### Commit resource files and create pipeline +Once Codefresh generates the manifests, and you validate them, you commit all the changes. The commits are synced to the Git source defined for the pipeline, and then synced to the cluster. + + +### How to: Create a Delivery Pipeline +Follow the step-by-step instructions to guide you through Delivery Pipeline wizard and create a Codefresh pipeline. + +1. In the Codefresh UI, go to [Delivery Pipelines](https://g.codefresh.io/2.0/pipelines){:target="\_blank"}. +1. Select **+ Add Delivery Pipeline**. + + {% include + image.html + lightbox="true" + file="/images/pipeline/create/create-add-delivery-pipeline.png" + url="/images/pipeline/create/create-add-delivery-pipeline.png" + alt="Add Delivery Pipeline panel in Codefresh" + caption="Add Delivery Pipeline panel in Codefresh" + max-width="30%" + %} + +{:start="3"} +1. Enter a name for the Delivery Pipeline. + The name is created from the names of the sensor and the trigger (alphanumeric lowercase, and the - character). + * **Sensor Name**: The name of the sensor resource. For example, the application name, or `codefresh`. + * **Trigger Name**: The template that defines the context of the trigger and the actual resources the sensor must execute. For example, the flow that will be run,`ci`. +1. Select the **Codefresh Starter Template** or **Browse Existing Template**. +1. From the list of **Git Sources**, select the Git Source to which to commit the resources for this pipeline. + > Only those Git Sources to which you have write permissions are displayed. + If you have multiple runtimes installed, the Git Source you select also determines the runtime on which the pipeline is executed. +1. Select **Next**. +1. If needed, select the Git Source, and then the Workflow Template to work with. + In the **Configuration** tab, **Workflow Templates** is selected. Our CI Starter Workflow Template is shown. + Copy and paste any Workflow Template you want to work with, or edit the starter template as needed. + > Tip: + > Codefresh notifies you that you have uncommitted changes. The Commit button remains disabled until you define at least one Trigger Condition. + + {% include + image.html + lightbox="true" + file="/images/pipeline/create/pipeline-wizard-workflow-tab.png" + url="/images/pipeline/create/pipeline-wizard-workflow-tab.png" + alt="Workflow Template tab in Delivery Pipeline wizard" + caption="Workflow Template tab in Delivery Pipeline wizard" + max-width="30%" + %} + +{:start="8"} +1. Select **Arguments**. + The Arguments defined in the Workflow Template and passed to the workflow when the pipeline is run, are displayed. +1. Enter default values for the arguments as needed. +1. Select **Trigger Conditions**. + * From the **Add** dropdown, select **Git Events**. + * In the **Git Repository URLs** field, select one or more repositories from the list to listen to for the selected event. + + {% include + image.html + lightbox="true" + file="/images/pipeline/create/pipeline-wizard-trigger-git-repos.png" + url="/images/pipeline/create/pipeline-wizard-trigger-git-repos.png" + alt="Select Git repos to listen to for events" + caption="Select Git repos to listen to for events" + max-width="30%" + %} + + * From the **Event** dropdown, select the event for the sensor trigger. For example, **Commit pushed**. + Codefresh displays all the **Arguments** available for the sensor trigger, identical to the list of Workflow Template arguments. + * Customize the value for an argument by selecting single or a combination of predefined variables. + In each field, type `$` and from the list of predefined variables, select the one you need. + Codefresh automatically maps to the correct JSON path in the event payload when manifests are generated before commit. Argo Workflow then instantiates the values from the event payload. + + {% include + image.html + lightbox="true" + file="/images/getting-started/quick-start/quick-start-ci-pipeline-arguments.png" + url="/images/getting-started/quick-start/quick-start-ci-pipeline-arguments.png" + alt="Predefined variables for sensor arguments" + caption="Predefined variables for arguments" + max-width="30%" + %} +{:start="11"} +1. To create filters for the event payload: + * From **Event Filters**, select the filter, and select **+Add**. + * Select the operational expression and define the value of the filter. + + {% include + image.html + lightbox="true" + file="/images/pipeline/create/pipeline-wizard-event-filters.png" + url="/images/pipeline/create/pipeline-wizard-event-filters.png" + alt="Event filters" + caption="Event filters" + max-width="30%" + %} + +{:start="12"} +1. To transform a predefined filter to a standard data filter, select **Detach & Customize**. + + +{:start="13"} +1. Select **Apply**, and then **Commit** on the top-right. + The Commit Changes panel shows the resource files created for the pipeline. These files are committed to the repository linked to the Git Source you selected in the first step of the wizard. + {% include + image.html + lightbox="true" + file="/images/pipeline/create/pipeline-wizard-resources.png" + url="/images/pipeline/create/pipeline-wizard-resources.png" + alt="Pipeline resource files generated on commit" + caption="Pipeline resource files generated on commit" + max-width="30%" + %} +{:start="14"} +1. Enter a message (optional), and then select **Commit**. + +Codefresh commits the pipeline to the Git repository, and then syncs it to the cluster. Wait a few seconds for the sync to complete, and verify that the pipeline is displayed in the [Delivery Pipelines](https://g.codefresh.io/2.0/pipelines){:target="\_blank"} page. + diff --git a/_docs/pipelines/images.md b/_docs/pipelines/images.md new file mode 100644 index 00000000..0b87937d --- /dev/null +++ b/_docs/pipelines/images.md @@ -0,0 +1,112 @@ +--- +title: "Viewing Images in Codefresh" +description: "" +group: pipelines +toc: true +--- + +Building Docker images is one of the most basic requirements for creating Delivery Pipelines. +Once you create an image, push the image to a registry, and report it to Codefresh, image information is continually updated in the Codefresh UI. + +### Requirements for images in Codefresh +Complete the mandatory steps to see your images in Codefresh. Each step has links to examples in the Codefresh Hub for Argo. + +1. (Mandatory) Build the Docker image, and push the image to any registry. + See [Create a Docker image using Kaniko](https://codefresh.io/argohub/workflow-template/kaniko){:target="\_blank"}. +1. (Optional) Enrich image information with annotations and metadata. + For Git and Jira image enrichment examples, see [Codefresh-metadata image enrichment](https://codefresh.io/argohub/workflow-template/CSDP-metadata){:target="\_blank"}. +1. (Mandatory) Report image information to Codefresh. + See the [report-image-info](https://github.com/codefresh-io/argo-hub/blob/main/workflows/codefresh-csdp/versions/0.0.6/docs/report-image-info.md){:target="\_blank"} example. + + +### Image views in Codefresh +* In the Codefresh UI, go to [Images](https://g.codefresh.io/2.0/images){:target="\_blank"}. + +Image views are layered to show three levels of data: +* Repository and application deployment +* Tags +* Summary with metadata and binary information + +#### Filters for image views +As with any resource in Codefresh, image views support filters that allow you focus on the data that's important to you. +Most image filters support multi-selection. Unless otherwise indicated, the filters are common to all view levels. + +{: .table .table-bordered .table-hover} +| Filter | Description| +| -------------- | -------------- | +| **Repository Names** | The Git repository or repositories that contain the image. | +| **Tag** | The tag by which to filter. | +| **Registry Types** | The registry which stores your image. To filter by registries that are not listed, select **Other types**.| +| **Git branch** | The Git branch to which the image is pushed.| +| **Git repositories** | The Git provider you use.| +| **Deployed in application**| The application or applications in which the image is currently deployed.| +| **Sorted by** | List images by **Name**, or by the most recent update, **Last update**. + + + +#### Image repository and deployment view +The default view for image resources shows repository and deployment information. + +{% include + image.html + lightbox="true" + file="/images/image/application-level.png" + url="/images/image/application-level.png" + alt="Repository & deployment info for Images in Codefresh" + caption="Repository & deployment info for Images in Codefresh" + max-width="30%" + %} + +{: .table .table-bordered .table-hover} +| Legend | Description| +| -------------- | -------------- | +| **1** | The name of the image. | +| **2** | The applications in which the image is currently deployed. Select the application to go to the Applications dashboard.| +| **3** | The details on the most recent commit associated with the image. Select the commit to view the changes in the Git repository.| +| **4** | Binary information on the image.| +| **5** | The registry to which the image is pushed, and from which it is distributed.| + +### Image tag view +Drilldown on the repository shows tag information for the image. +{% include + image.html + lightbox="true" + file="/images/image/tag-view.png" + url="/images/image/tag-view.png" + alt="Tag info for Images in Codefresh" + caption="Tag info for Images in Codefresh" + max-width="30%" + %} + +{: .table .table-bordered .table-hover} +| Legend | Description| +| -------------- | -------------- | +| **1** | The image tag. | +| **2** | The comment describing the commit or change, with the name of the Git provider and the corresponding PR. To view details of the commit changes in the Git repository, select the commit text.| +| **3** | The hash of the Docker image, generated as sha256. A change in the digest indicates that something has changed in the image.| +| **4** | The registry to which the image is pushed (stored), and from which it is distributed.| +| **5** | The OS and architecture in which the image was created. The date and time of the most recent update is in the local time zone| +| **6** | Additional information on the image. To view the Summary, select **more details**.| + +### Image summary view +The Summary view shows metadata for the image. +Selecting **more details** for an image tag. + +{% include + image.html + lightbox="true" + file="/images/image/summary-view.png" + url="/images/image/summary-view.png" + alt="Summary info for Images in Codefresh" + caption="Summary info for Images in Codefresh" + max-width="30%" + %} + +{: .table .table-bordered .table-hover} +| Legend | Description| +| -------------- | -------------- | +| **1** | The bugs or fix requests opened and being worked on for this image tag. | +| **2** | The pull request or requests pending commit.| +| **3** | The Git details for this image tag, such as the Git hash, the Jira issue number, Git Pull Request, commit information, the name of the user who performed the commit. | +| **4** | The workflow for the image step. Select to go to the Workflow.| +| **5** | The log information for the build image step in the relevant workflow. Select to view Logs panel. | diff --git a/_docs/pipelines/managing-pipelines.md b/_docs/pipelines/managing-pipelines.md index 53fa7da1..77e1779b 100644 --- a/_docs/pipelines/managing-pipelines.md +++ b/_docs/pipelines/managing-pipelines.md @@ -1,8 +1,171 @@ --- -title: "Managing your pipelines" +title: "Managing pipelines" description: "" group: pipelines toc: true --- -Coming soon +Once a Delivery Pipeline is [created and triggered]({{site.baseurl}}/docs/pipelines/create-pipeline/),Codefresh continuously collects and displays real-time analytics on the pipeline and the workflows submitted. +>This article focuses on pipeline management. For information on managing workflows in pipelines, see [Managing workflows]({{site.baseurl}}/docs/pipelines/workflows/). + + +Manage Delivery Pipelines in Codefresh by monitoring pipeline performance and analytics, and by optimizing pipeline configurations and manifests. + + +**Monitoring pipeline performance and analytics** +Monitor pipelines performance at the global and individual levels. Both levels provide metrics for KPIs for insights into trends and performance. + +* At the global level (Home dashboard), Codefresh aggregates performance analytics for all pipelines with active workflows. +* At the individual level (Delivery Pipelines list), Codefresh aggregates performance based on the pipeline's workflows, including step analytics across all the workflows in the pipeline. Step analytics allow you to analyze the resources consumed by a pipeline. +* Monitoring sensor and event-source errors for + + +**Optimizing pipeline configuration** +Use insights and trends from performance and KPI metrics to optimize the pipeline's Workflow Template, trigger conditions, and arguments. + + + + + + + +### Monitor sensor and event source notifications for pipelines in Activity Log +Monitor logs for sensors and event-sources in pipelines in the Activity Log. A pull-down panel in the Codefresh toolbar, the Activity Log shows ongoing, success, and error notifications, by date, starting with today's date. Syntax errors that prevent the sensor from triggering the pipeline are displayed here. + +1. In the Codefresh UI, on the top-right of the toolbar, select ![](/images/pipeline/monitoring/pipeline-activity-log-toolbar.png?display=inline-block) **Activity Log**. +1. To see pipeline activity, select **Event Source** and **Sensor** filters. + + {% include image.html + lightbox="true" + file="/images/pipeline/monitoring/monitor-activity-log.png" + url="/images/pipeline/monitoring/monitor-activity-log.png" + alt="Activity Log filtered by Event Source and Sensor" + caption="Activity Log filtered by Event Source and Sensor" + max-width="30%" + %} + +{:start="3"} +1. To see more information on an error, select the **+** sign. + +### Monitor global pipeline performance +Monitor performance of all active pipelines in the Home dashboard. Active pipelines are those that have at least one active or complete workflow. +The KPI metrics provides insights into trends for pipelines. Analytics are derived by comparing the selected time range to the corresponding reference period. If your time range is the last seven days, the reference period is the seven days that precede the time range. + + +1. In the Codefresh UI, go to the [Home](https://g.codefresh.io/2.0/){:target="\_blank"} page. +1. Set the **Time** frame for which to show pipeline data, as the **Last 7 days** (the default), **Last 30 days**, or **Last 90 days**. +1. Scroll down to Delivery Pipelines: + 1. To customize the view, select **Filters**. + 2. To switch to individual pipeline view, select **View**. + 3. To get day-to-day data for a metric, select the line-chart. + +Here is an example of the global pipeline view in the Home page. + + {% include image.html + lightbox="true" + file="/images/pipeline/monitoring/monitor-aggregated-view.png" + url="/images/pipeline/monitoring/monitor-aggregated-view.png" + alt="Global analytics for Delivery Pipelines in Home page" + caption="Global analytics for Delivery Pipelines in Home page" + max-width="30%" + %} + + + + +#### Filters for global pipeline view +Filters narrow the scope of aggregated data, allowing you to focus on the information you want to see. Unless otherwise indicated, all filters support multi-selection. + +{: .table .table-bordered .table-hover} +| Filter | Description| +| -------------- | --------------| +| **Status** | {::nomarkdown}
  • Succeeded: Pipelines with workflows completed successfully.
  • Failed: Pipelines with workflows that failed.
  • Error: Pipelines with workflows that resulted in errors.
    • {:/}| +| **Repository** |The Git repository or repositories tracked, with the events that triggered or ran the pipelines. | +| **Event Type** | The Git or Calendar event or events by which to view pipelines. If you select Git push, only those pipelines configured to be run on Git push are displayed. | +| **Initiator** | The user who made the commit that triggered the event and caused the pipeline to run.| + +#### Metrics in global pipeline view + +Pipeline metrics (KPIs), are displayed as line charts and in list formats. +* Line charts + Quick views of KPIs for the selected time frame. To see detailed day-to-day values, select a line chart. +* List formats + Display the average values for the same KPIs, sorted by activity and duration. The different perspectives illustrate both the fluctuations in the KPIs compared to the reference time range, and trending pipelines. The reference time range is the period of time that corresponds to and precedes the selected time range. + + {::nomarkdown}
    • Pipelines without numbers prefixing the names indicate new pipelines within the selected time frame.
    • Pipelines prefixed with numbers (encircled in the image above) indicate existing pipelines.
      The number indicates the change in position of the pipeline compared to the reference period.
    • To drill down into a specific pipeline, select the pipeline.
    + +{: .table .table-bordered .table-hover} +| Metric | Description| +| -------------- | --------------| +| **Success Rate** | The average number of successful executions, in percentage. | +| **Average Duration** | The average length of time to complete execution, in mm:ss. | +| **Executions** | The average number of times the pipeline was triggered, in percentage. | +| **Committers** | The number of users whose commits on the repository or repositories triggered the pipelines. User count is aggregated per user, so multiple commits from the same user are counted as a single commit.| + + +### Monitor individual pipeline performance + +Monitor and compare KPIs for all pipelines in your cluster, including those that are not active, meaning pipelines for which workflows have not been submitted. + +View pipeline activity for the last seven days, the status and the sync state. Compare KPIs for all the pipelines in the cluster, and identify inactive pipelines. + +1. In the Codefresh UI, go to the [Delivery Pipelines](https://g.codefresh.io/2.0/pipelines){:target="\_blank"} page. +1. To find specific pipelines, in the search field, enter a part of the pipeline name. For example, to find all CI-based pipelines, enter `ci`. + +Here is an example of the list view of individual pipelines. + + {% include image.html + lightbox="true" + file="/images/pipeline/monitoring/pipeline-list-view.png" + url="/images/pipeline/monitoring/pipeline-list-view.png" + alt="List view with individual Delivery Pipelines" + caption="List view with individual Delivery Pipelines" + max-width="30%" + %} + +The table describes the information for each pipeline in the list view. +> The list view displays data for the last seven days. + + +{: .table .table-bordered .table-hover} +| Legend | Description| +| --------------| -------------- | +| **Name** | The name of the pipeline. Select the name to drill down into step analytics, workflows, and configuration.| +| **Recent Activity**| Bar chart of up to ten of the most recent workflows submitted for the pipeline. {::nomarkdown}
    • Each bar represents a workflow that is color-coded to indicate the workflow's status: Green for completed, red for failed, and blue for ongoing workflows.
    • Mouse over a bar to see a pop-up with the metadata for the workflow.
    • Selecting View Workflow Details takes you to the Workflow tab where you have several options to manage the workflow and view logs. For more information, see Managing workflows.
    {:/}| +| **Last Run**| The time of the most recent run of the pipeline, when a workflow was submitted. The time is also color-coded to indicate the status of the workflow. Empty Last Run columns identify pipelines that have not been triggered to submit workflows.| +| **Success Rate**| The number of workflows that completed successfully in the last seven days, and the comparison to the reference period in percentage. | +| **Avg. Duration**| The average length of time for the pipeline's workflows to complete execution, in mm:ss. | +| **Weekly Runs**| The number of times the pipeline was run and its workflows submitted in the last seven days, and the difference in percentage compared to the reference period. | +| **Runtime**| The runtime in which the pipeline is run. | +| **Last Modified**| The date and time that the pipeline was recently updated. The updates include changes in configuration and manifests.| +| **Sync Status**| The sync status of the live state in the cluster with the desired state in Git.| + + + +### Update pipeline configuration settings or manifests +Update the pipeline's Workflow Template, arguments, sensor and event source manifests to optimize or fix performance issues. +You can update the settings in the Configuration tab or in the Manifests tab, working in the mode that you are comfortable with. +* The Configuration tab shows a modular view of the settings in form mode, and makes for easier editing. +* The Manifests tab shows the YAMLs generated on commit. Here you can see the Git, desired, and live states of each manifest in parallel. + The Git state is the state-of-truth and is the only editable state. The desired state is the state after the changes are committed, before they are synced to the cluster. The live state is the actual state currently in the cluster. + +For information on the settings, review [Delivery Pipeline creation flow]({{site.baseurl}}/docs/pipelines/create-pipeline/#delivery-pipeline-creation-flow) + +1. From either the **Home** or the **Delivery Pipelines** pages, select a pipeline. +1. Select the **Configuration** tab. + * Select the component, and modify settings as needed. + * For the Workflow Template, use the **Diff View** to see changes. + +{:start="3"} +1. Select the **Manifests** tab. + * Check if there are Errors or Warnings for the manifest. + * To review the changes by manifest, from the drop-down list, select any YAML manifest. + * Compare the Git, desired, and actual versions if needed. + * To update, switch to the **Git State** and Select **Edit**. + * To view commit history, select **Sync History**. + Codefresh validates the settings in real-time alerting you to errors and warnings. + + > If there are Errors, Commit is disabled until you resolve the errors. + +### What to read next +[Managing workflows]({{site.baseurl}}/docs/pipelines/workflows/) \ No newline at end of file diff --git a/_docs/pipelines/workflows.md b/_docs/pipelines/workflows.md new file mode 100644 index 00000000..8951fbb5 --- /dev/null +++ b/_docs/pipelines/workflows.md @@ -0,0 +1,389 @@ +--- +title: "Manage workflows" +description: "" +group: pipelines +toc: true +--- + + +Workflows in Codefresh are integrated with and run Argo Workflows, an open-source container-native workflow engine for orchestrating parallel jobs on Kubernetes, implemented as a K8s CRD (Custom Resource Definition). Read more in [Argo Workflows documentation](https://argoproj.github.io/argo-workflows/). + +Workflows are submitted when pipelines are triggered. A workflow executes a series of steps through one or more templates defined in its specification. View, analyze, and manage workflows in Codefresh through the Workflow and Delivery Pipeline dashboards: + +* Track ongoing and completed workflows + View and monitor submitted workflows across all pipelines in the Workflows dashboard. Select a time range, or view up to fifty of the most recent workflows for all the pipelines in the runtime. Use filters to customize the dashboard view. Drill down to any workflow for further analysis. + + {% include image.html + lightbox="true" + file="/images/workflows/workflows-dashboard.png" + url="/images/workflows/workflows-dashboard.png" + alt="Workflows dashboard" + caption="Workflows dashboard" + max-width="60%" + %} + +* Track workflow performance by pipelines + Track workflow performance in the context of the pipelines from which they were submitted. + See performance KPIs for the workflows such as the success rate, execution rate, and for the steps across all the workflows submitted for the same pipeline. + + {% include image.html + lightbox="true" + file="/images/workflows/dashboard-workflows-in-pipeline.png" + url="/images/workflows/dashboard-workflows-in-pipeline.png" + alt="Workflows in Delivery Pipeline" + caption="Workflows in Delivery Pipeline" + max-width="60%" + %} + +* Analyze and troubleshoot workflow executions + Select a workflow and take actions in the context of the pipeline from which it was submitted: + * Analyze each step in the workflow, including steps related to the events that triggered the pipeline. + * Troubleshoot failed steps through real-time logs for ongoing workflows, and archived logs for completed workflows + * Manage workflows based on the current status; suspend, stop, or terminate ongoing workflows, and retry, resubmit, or delete completed workflows. + +>This article focuses on workflow management. For information on managing Delivery Pipelines, see [Managing Delivery Pipelines]({{site.baseurl}}/docs/pipelines/managing-pipelines/). + + +### Aggregated workflow performance (Workflows dashboard) +The Workflows dashboard displays a list of all the _active_ workflows across all Delivery Pipelines. Active workflows are either running or completed workflows. Set filters to view subsets of workflows, including pipeline filters to focus on specific workflows. Then drill down on any workflow to view execution details and manage it. + + {% include image.html + lightbox="true" + file="/images/workflows/workflows-dashboard.png" + url="/images/workflows/workflows-dashboard.png" + alt="Workflows dashboard: Aggregated workflow performance" + caption="Workflows dashboard: Aggregated workflow performance" + max-width="50%" + %} + +The table describes the information in the Workflows dashboard. + +{: .table .table-bordered .table-hover} +| Item | Description| +|---------------------|-------------| +| **Filters** | The filters available to customize the view. Selecting **More filters** allows you to filter workflows by one or more pipelines. For details, see [aggregated view]({{site.baseurl}}/docs/pipelines/managing-pipelines/#filters-for-aggregated-views). | +| **Workflow chart** | The bar chart displaying the workflows for the selected time range. Up to 50 workflows are displayed, starting with the oldest. The color of the bar indicates if the workflow is active (blue), completed successfully (green), failed (red), or unknown (purple). For workflow-specific metadata, mouse over the bar. To drill down on that workflow, select **View Workflow Details** link. (see image below entitled, Pop-up with workflow metadata). | +| **Workflow list** | The list of workflows with workflow-specific metadata and links, similar to what you see in the bar-chart pop-ups. You can see the git hash, the name of the user who made the commit, the pipeline that submitted the workflow, the start time and duration. Selecting **View Workflow Details** opens the Workflows tab with execution details, visualization of workflow steps for troubleshooting, analysis, and management.| + + {% include image.html + lightbox="true" + file="/images/pipeline/monitoring/monitor-workflows-tab-popup.png" + url="/images/pipeline/monitoring/monitor-workflows-tab-popup.png" + alt="Workflows dashboard: Pop-up with metadata for workflow in bar chart" + caption="Workflows dashboard: Pop-up with metadata for workflow in bar chart" + max-width="50%" + %} + +### Tracking workflow performance by pipeline +View and monitor the collective performance of workflows in the selected pipeline in the Delivery Pipelines dashboard. Performance KPIs are available for the workflow, and for every step across workflows. At the workflow level, view success and execution rates for the workflows, and at the step level, view the average durations and resource consumption for each step. Compare with the performance in the reference period to derive insights. + +1. From the **Delivery Pipelines** page, select a pipeline to see its workflows. +1. Select the [Dashboard](https://g.codefresh.io/2.0/pipelines/edit/codefresh-v2-production/codefresh-v2-production/argo-platform-push%2Fservice-yaml/dashboard){:target="\_blank"} tab. + + {% include image.html + lightbox="true" + file="/images/workflows/monitor-step-analytics.png" + url="/images/workflows/monitor-step-analytics.png" + alt="Workflow performance for selected pipeline" + caption="Workflow performance for selected pipeline" + max-width="60%" + %} + +**Aggregated workflow analytics** + +The upper half shows KPIs for all workflows submitted for the pipeline. To customize the view, select filters. In this view, you can also filter by **Branch** which is the Git branch or branches with the events that triggered the pipeline. + +**Step-level analytics** +The Step Analytics list in the lower half displays the aggregated average for KPIs in each step, across all active workflows for the selected pipeline. +Each metric shows the difference in percentage compared to the reference period corresponding to the Time range selected, to help identify how the metrics are trending. + +{: .table .table-bordered .table-hover} +| Step Analytics | Description| +| --------------| -------------- | +| **Step** | The name of the step in the workflow. | +| **Type** | The action executed by the step. For example, the step can execute a Container template, or skip the step. For details, see [Template types in Core Concepts](https://argoproj.github.io/argo-workflows/workflow-concepts/#template-types){:target="\_blank"}.| +| **Template** | The template called by the step. | +| **Workflow Template**| The Workflow Template referenced by the step. Different steps can reference the same or different Workflow Templates.| +| **Avg. Duration**| The average length of time for all active workflows to complete execution of this step, in mm:ss. | +| **Executions**| The number of times the step was executed. | +| **CPU** and **Memory**| The average CPU and memory consumed by the step, across all the active workflows.| +| **Errors**| The number of times that the execution of this step resulted in errors.| + + +### Managing workflows + +Both the Workflow and the Delivery Pipeline dashboards allow you to drill down into a specific workflow to view, analyze, and troubleshoot execution. When you drill down from a Delivery Pipeline, you can see the workflow in the context of its pipeline, including the pipeline's configuration settings, and sensor and event-source manifests. The integrated view of both the workflow steps, workflow logs, and the pipeline configuration in the same location makes it easy to make changes when troubleshooting. + + {% include image.html + lightbox="true" + file="/images/pipeline/monitoring/pipeline-list-view.png" + url="/images/pipeline/monitoring/pipeline-list-view.png" + alt="Workflows in a Delivery Pipeline" + caption="Workflows in a Delivery Pipeline" + max-width="60%" + %} + + +#### Select a workflow +Select the workflow to focus on, either from the Workflows dashboard or from a Delivery Pipeline. + +1. In the [Workflows dashboard](https://g.codefresh.io/2.0/workflows), set filters to view the subset of workflows you are interested in. + OR + In the **Delivery Pipelines** page, select a pipeline, and then select the [Workflows](https://g.codefresh.io/2.0/workflows) tab to see all its workflows. + +1. To drill down into a workflow, select **View workflow details** for that workflow. + + {% include image.html + lightbox="true" + file="/images/workflows/workflow-drill-down.png" + url="/images/workflows/workflow-drill-down.png" + alt="View Workflow Details" + caption="View Workflow Details" + max-width="50%" + %} + + +#### Visualizing workflow steps + +View the connections between steps in the workflow, the status of each step, and additional information for the step. + +* Visualize the entire flow, starting with the Argo Events that triggered the workflow, followed by the steps in the workflow itself. +* View detailed information on a step in a pull-out panel. Easily copy paths for attributes from event payloads, view logs for pods, and download artifacts. +* Troubleshoot failed steps + + +{% include image.html + lightbox="true" + file="/images/workflows/workflow-steps.png" + url="/images/workflows/workflow-steps.png" + alt="Workflow steps" + caption="Workflow steps" + max-width="30%" + %} + + +**Step status** +Every step has a status indication of either active ({::nomarkdown} +{:/}), synced ({::nomarkdown} +{:/}), or failed ({::nomarkdown} +{:/}). + +**Step types and filters** +Steps in a workflow are either Kubernetes resources (Pods, Containers for example), Argo templates and template invocators (DAG, Step, StepGroup for example), or Resources (Event Sources, Sensors). For more information, see [Template types in Core concepts](https://argoproj.github.io/argo-workflows/workflow-concepts/#template-types). + + +> Important: Node and Phase filters for steps have an _AND_ relationship. To see results, you must select at least one Node type and Phase status. + + + {% include image.html + lightbox="true" + file="/images/workflows/filters-workflow-steps.png" + url="/images/workflows/filters-workflow-steps.png" + alt="Filters for workflow steps" + caption="Filters for workflow steps" + max-width="50%" + %} + + + +Resource-type steps have labels within the step to differentiate them from workflow steps. + +{% include image.html + lightbox="true" + file="/images/workflows/argo-events-in-wrkflow.png" + url="/images/workflows/argo-events-in-wrkflow.png" + alt="Argo Event steps in workflow" + caption="Argo Event steps in workflow" + max-width="30%" + %} + + +#### Troubleshooting failed steps +Identify failed steps in a workflow through the error notifications alert in the workflow status bar, through Phase filters, or the search mechanism. With Phase status filters, remember to also select at least one Node type for results. +For further analysis, select the step, or click Logs in the toolbar. + + +**Error notifications for failed steps** + +* The status bar alerts you to failed steps through an error notification. + Clicking the notification opens the list of steps in the Errors tab. + +{% include image.html + lightbox="true" + file="/images/workflows/workflow-error-notification.png" + url="/images/workflows/workflow-error-notification.png" + alt="Error notifications for failed steps" + caption="Error notifications for failed steps" + max-width="50%" + %} + + {% include image.html + lightbox="true" + file="/images/workflows/workflow-error-notifications-open.png" + url="/images/workflows/workflow-error-notifications-open.png" + alt="Error notifications panel" + caption="Error notifications panel" + max-width="50%" + %} + + The Errors tab has links to the logs. + + {% include image.html + lightbox="true" + file="/images/workflows/workflow-error-notifications-open.png" + url="/images/workflows/workflow-error-notifications-open.png" + alt="Error notifications panel" + caption="Error notifications panel" + max-width="30%" + %} + +**Error and Failed Phase filters** + +Selecting the Error and Failed status filters by steps in the workflow that the statuses. + + + {% include image.html + lightbox="true" + file="/images/workflows/workflow-steps-failed.png" + url="/images/workflows/workflow-steps-failed.png" + alt="Identifying failed steps with Phase filters" + caption="Identifying failed steps with Phase filters" + max-width="30%" + %} + +**Search for failed steps** +If you know the name of the step, use the Search field to navigate to and between failed steps. + +{% include image.html + lightbox="true" + file="/images/workflows/failed-steps-search.png" + url="/images/workflows/failed-steps-search.png" + alt="Search for failed steps" + caption="Search for failed steps" + max-width="30%" + %} + + + +#### Detailed information for steps +To get detailed information for a step, select the step. +The tabs displayed differ according to the step type: + + * All workflow step types show the Summary, Manifest, Containers, Inputs, Outputs. + * Pod step-types also display the Logs tab. + * Event-step types show Manifest, Summary and Payload. + > For Cron and Unknown event types, only the Event Sources are shown. + + Example: event-source manifest. + + {% include image.html + lightbox="true" + file="/images/workflows/event-source.png" + url="/images/workflows/event-source.png" + alt="Additional info for event-source manifest in workflow" + caption="Additional info for event-source manifest in workflow" + max-width="30%" + %} + + Example: event-payload. + + {% include image.html + lightbox="true" + file="/images/workflows/event-payload.png" + url="/images/workflows/event-payload.png" + alt="Additional info for event payload in workflow" + caption="Additional info for event payload in workflow" + max-width="30%" + %} + + Example: pod step type + + {% include image.html + lightbox="true" + file="/images/workflows/workflow-pod-step.png" + url="/images/workflows/workflow-pod-step.png" + alt="Additional info for pod step type in workflow" + caption="Additional info for od step type in workflow" + max-width="30%" + %} + +#### View logs for steps or workflows + +View logs for ongoing or completed workflows. As with logs in any standard terminal, you can copy/cut/paste log info. The commands differ based on the OS. + +* For ongoing workflows, you can see live logs as the steps in the workflow are being executed. +* For completed workflows, you can view logs for any step in the workflow. + +> To view logs for completed workflows, you must configure an artifact repository in CSDP to archive them. + +**Before you begin** +[Configure an artifact repository]({{site.baseurl}}/docs/pipelines/configure-artifact-repository/) + +**How to** +1. Select the [workflow](#select-the-workflow-to-monitor). +1. Filter by **Node Type** of **Pods**, and then select a step to view its logs. + + {% include image.html + lightbox="true" + file="/images/workflows/view-logs-pull-out.png" + url="/images/workflows/view-logs-pull-out.png" + alt="Event payload in workflow" + caption="Event source in workflow" + max-width="30%" + %} + + +OR + +1. In the Workflows tab, select **Logs**. +1. From the **Select Step (Pod)** dropdown, do one of the following: + * To view live logs for an ongoing workflow, select **All**. + * To view archived logs for a completed workflow, select the step and from the **Select Container** dropdown, select the container. + + {% include image.html + lightbox="true" + file="/images/workflows/view-logs-logs-tab.png" + url="/images/workflows/view-logs-logs-tab.png" + alt="Event payload in workflow" + caption="Event source in workflow" + max-width="30%" + %} + +{:start="3"} +1. If needed, copy/cut/paste log details. Refer to the table below for help on commands compatible with your OS. + + +{: .table .table-bordered .table-hover} +|OS/terminal emulator|Cut |Copy |Paste | +| -------------- | ----- | ----------- | --------| +| **Apple** | `Command`+`X` | `Command`+`C` | `Command`+`V` | +| **Windows/ GNOME/KDE**| `Control`+`X` or `Shift`+`Delete`| `Control`+`C` or `Control`+`Insert`| `Control`+`V` or `Shift`+`Insert`| +| **GNOME/KDE terminal emulators**|N/A|`Control`+`Shift`+`C` or `Control`+`Insert`| `Control`+`Shift`+`V` or `Control`+`Shift`+`Insert`; (to paste selected text `Shift`+`Insert` or middle mouse button) | + +### Manage running/completed workflows +When you drill down into the workflow details for a running or completed workflow, the toolbar displays several actions. +>The actions in the toolbar are _manual_ actions, different from the same actions that are built into the template which are executed automatically. For example, the Suspend option in the toolbar can be configured in the template as well. + +{: .table .table-bordered .table-hover} +|Action |Description | +| -------------- | ---------------------------------- | +| **Summary** | Detailed information for both active and completed workflows. | +| **Suspend**/**Resume** | Temporarily pause execution of a running workflow. Resume execution from the point at which it was suspended. | +| **Stop** | Stop execution of an active workflow through a graceful shutdown. Graceful shutdown implements the actions configured in the ExitHandler, such as cleaning up resources, sending Slack notifications, for example. Compare with Terminate.| +| **Retry** | Restart a completed but failed workflow. You may want to retry a failed workflow, to retry end-to-end testing steps for example. The retry option is available only for workflows with errors. | ` +| **Resubmit** | Resubmit a successfully completed workflow to create a new instance of the workflow. | +| **Terminate** | Force shutdown to stop the execution of an active workflow. Force shutdown summarily terminates the workflow ignoring the ExitHandler. | ` +| **Delete** |Delete an unused or legacy completed workflow. Deleting a workflow removes it from the pipeline's list and from the Workflows dashboard.| +| **Logs** |[View logs for the workflow](#view-logs-forworkflows). | ` + +#### View native workflows +You can also view the workflow in the Argo UI. + + {% include image.html + lightbox="true" + file="/images/workflows/view-native-workflow.png" + url="/images/workflows/view-native-workflow.png" + alt="Workflows tab: View Native Workflow option" + caption="Workflows tab: View Native Workflow option" + max-width="50%" + %} diff --git a/images/applications/current-state-logs.png b/images/applications/current-state-logs.png new file mode 100644 index 00000000..9446928d Binary files /dev/null and b/images/applications/current-state-logs.png differ diff --git a/images/applications/current-state-resource-summary.png b/images/applications/current-state-resource-summary.png new file mode 100644 index 00000000..d9e33cd4 Binary files /dev/null and b/images/applications/current-state-resource-summary.png differ diff --git a/images/applications/current-state-tree-app-in-progress.png b/images/applications/current-state-tree-app-in-progress.png new file mode 100644 index 00000000..c2d8f911 Binary files /dev/null and b/images/applications/current-state-tree-app-in-progress.png differ diff --git a/images/applications/current-state-tree-resource-filtered.png b/images/applications/current-state-tree-resource-filtered.png new file mode 100644 index 00000000..80d26d89 Binary files /dev/null and b/images/applications/current-state-tree-resource-filtered.png differ diff --git a/images/applications/current-state-tree-resource-list.png b/images/applications/current-state-tree-resource-list.png new file mode 100644 index 00000000..b0fccd5e Binary files /dev/null and b/images/applications/current-state-tree-resource-list.png differ diff --git a/images/applications/current-state-tree-search.png b/images/applications/current-state-tree-search.png new file mode 100644 index 00000000..71278cba Binary files /dev/null and b/images/applications/current-state-tree-search.png differ diff --git a/images/applications/current-state-tree-view.png b/images/applications/current-state-tree-view.png new file mode 100644 index 00000000..e465e44b Binary files /dev/null and b/images/applications/current-state-tree-view.png differ diff --git a/images/current-state-missing 2.png b/images/current-state-missing 2.png new file mode 100644 index 00000000..25f70007 Binary files /dev/null and b/images/current-state-missing 2.png differ diff --git a/images/current-state-missing.png b/images/current-state-missing.png new file mode 100644 index 00000000..25f70007 Binary files /dev/null and b/images/current-state-missing.png differ diff --git a/images/icons/active.png b/images/icons/active.png new file mode 100644 index 00000000..1016f3c1 Binary files /dev/null and b/images/icons/active.png differ diff --git a/images/pipeline/badges/badge.png b/images/pipeline/badges/badge.png deleted file mode 100644 index 57e4f438..00000000 Binary files a/images/pipeline/badges/badge.png and /dev/null differ diff --git a/images/pipeline/badges/get-build-badge.png b/images/pipeline/badges/get-build-badge.png deleted file mode 100644 index 2c857fcc..00000000 Binary files a/images/pipeline/badges/get-build-badge.png and /dev/null differ diff --git a/images/pipeline/badges/get-public-url.png b/images/pipeline/badges/get-public-url.png deleted file mode 100644 index 9fb28cc7..00000000 Binary files a/images/pipeline/badges/get-public-url.png and /dev/null differ diff --git a/images/pipeline/badges/toggle-public-logs.png b/images/pipeline/badges/toggle-public-logs.png deleted file mode 100644 index fc677262..00000000 Binary files a/images/pipeline/badges/toggle-public-logs.png and /dev/null differ diff --git a/images/pipeline/badges/view-public-logs.png b/images/pipeline/badges/view-public-logs.png deleted file mode 100644 index 395c4046..00000000 Binary files a/images/pipeline/badges/view-public-logs.png and /dev/null differ diff --git a/images/pipeline/caching/cache-from.png b/images/pipeline/caching/cache-from.png deleted file mode 100644 index a817bcf1..00000000 Binary files a/images/pipeline/caching/cache-from.png and /dev/null differ diff --git a/images/pipeline/caching/codefresh-shared-volume.png b/images/pipeline/caching/codefresh-shared-volume.png deleted file mode 100644 index 09d01f74..00000000 Binary files a/images/pipeline/caching/codefresh-shared-volume.png and /dev/null differ diff --git a/images/pipeline/caching/concurrent-build-caching.png b/images/pipeline/caching/concurrent-build-caching.png deleted file mode 100644 index 28033b27..00000000 Binary files a/images/pipeline/caching/concurrent-build-caching.png and /dev/null differ diff --git a/images/pipeline/caching/concurrent-build-caching.svg b/images/pipeline/caching/concurrent-build-caching.svg deleted file mode 100644 index 28499a9f..00000000 --- a/images/pipeline/caching/concurrent-build-caching.svg +++ /dev/null @@ -1,904 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - image/svg+xml - - - - - - - Build 1 - - - - - - - - - - /codefresh/volume - - - - Pipeline volume cache - - - Save - Restore - - Allocate - Build 2 - - - - - - - - - - /codefresh/volume - - - Save - - Build 3 - - - - - - - - - - /codefresh/volume - - - Overwrite - - Allocate - - diff --git a/images/pipeline/caching/distributed-docker-layer-cache.png b/images/pipeline/caching/distributed-docker-layer-cache.png deleted file mode 100644 index 02751104..00000000 Binary files a/images/pipeline/caching/distributed-docker-layer-cache.png and /dev/null differ diff --git a/images/pipeline/caching/distributed-layer-cache.png b/images/pipeline/caching/distributed-layer-cache.png deleted file mode 100644 index 45699936..00000000 Binary files a/images/pipeline/caching/distributed-layer-cache.png and /dev/null differ diff --git a/images/pipeline/caching/distributed-layer-cache.svg b/images/pipeline/caching/distributed-layer-cache.svg deleted file mode 100644 index f1304a09..00000000 --- a/images/pipeline/caching/distributed-layer-cache.svg +++ /dev/null @@ -1,648 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - image/svg+xml - - - - - - - - Docker layer A - - - Build Node 5 - - - - Docker layer B - - - - Docker layer C - - - - Docker layer D - - - - - Docker layer X - - - - Build Node 23 - - - Docker layer Y - - - - Docker layer Z - - - Build Node 18 - - - - Shared Layer cache - - - - - - diff --git a/images/pipeline/caching/image-cache-hit.png b/images/pipeline/caching/image-cache-hit.png deleted file mode 100644 index 18ca7c89..00000000 Binary files a/images/pipeline/caching/image-cache-hit.png and /dev/null differ diff --git a/images/pipeline/caching/image-cache-miss.png b/images/pipeline/caching/image-cache-miss.png deleted file mode 100644 index 6b7c3c64..00000000 Binary files a/images/pipeline/caching/image-cache-miss.png and /dev/null differ diff --git a/images/pipeline/caching/image-caching.png b/images/pipeline/caching/image-caching.png deleted file mode 100644 index 6bfc6efa..00000000 Binary files a/images/pipeline/caching/image-caching.png and /dev/null differ diff --git a/images/pipeline/caching/image-caching.svg b/images/pipeline/caching/image-caching.svg deleted file mode 100644 index b8abde7a..00000000 --- a/images/pipeline/caching/image-caching.svg +++ /dev/null @@ -1,627 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - image/svg+xml - - - - - - - step 1 - cache hit - - step 2 - cache miss  - - step 3 - cache miss  - - 15s - First build - - - - - Shared image cache - - - - - Pull images - Restore images - 2min - 5min - step 1 - cache hit - - step 2 - cache hit  - - step 3 - cache hit  - - 15s - Second build - - - - 15s - 15s - - diff --git a/images/pipeline/caching/no-distributed-layer-cache.png b/images/pipeline/caching/no-distributed-layer-cache.png deleted file mode 100644 index 8448ce6a..00000000 Binary files a/images/pipeline/caching/no-distributed-layer-cache.png and /dev/null differ diff --git a/images/pipeline/caching/no-distributed-layer-cache.svg b/images/pipeline/caching/no-distributed-layer-cache.svg deleted file mode 100644 index 5767fdb6..00000000 --- a/images/pipeline/caching/no-distributed-layer-cache.svg +++ /dev/null @@ -1,532 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - image/svg+xml - - - - - - - Docker layer A - - Build Node 5 - - - Docker layer B - - Docker layer C - - Docker layer D - - Docker layer X - - Build Node 23 - - Docker layer Y - - Docker layer Z - - Build Node 18 - - - diff --git a/images/pipeline/caching/pipeline-volume-caching.png b/images/pipeline/caching/pipeline-volume-caching.png deleted file mode 100644 index 8f0cc93a..00000000 Binary files a/images/pipeline/caching/pipeline-volume-caching.png and /dev/null differ diff --git a/images/pipeline/caching/pipeline-volume-caching.svg b/images/pipeline/caching/pipeline-volume-caching.svg deleted file mode 100644 index 1a78c609..00000000 --- a/images/pipeline/caching/pipeline-volume-caching.svg +++ /dev/null @@ -1,1037 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - image/svg+xml - - - - - - - pipeline step A - - pipeline step B  - - pipeline step C  - - Build 1 - - - - - - - - - - - - /codefresh/volume - - - - - - Pipeline volume cache - - - - - pipeline step A - - pipeline step B  - - pipeline step C  - - Build 2 - - - - - - - - - - - - /codefresh/volume - - - - pipeline step A - - pipeline step B  - - pipeline step C  - - Build 3 - - - - - - - - - - - - /codefresh/volume - - - - - Save in cache - Save in cache - Restore - Restore - - Save in cache - - Allocate - - diff --git a/images/pipeline/caching/skip-build.png b/images/pipeline/caching/skip-build.png deleted file mode 100644 index c6851382..00000000 Binary files a/images/pipeline/caching/skip-build.png and /dev/null differ diff --git a/images/pipeline/create/add-pipeline-to-project.png b/images/pipeline/create/add-pipeline-to-project.png deleted file mode 100644 index 41fd8dd8..00000000 Binary files a/images/pipeline/create/add-pipeline-to-project.png and /dev/null differ diff --git a/images/pipeline/create/create-template-menu.png b/images/pipeline/create/create-template-menu.png deleted file mode 100644 index 7914b9a8..00000000 Binary files a/images/pipeline/create/create-template-menu.png and /dev/null differ diff --git a/images/pipeline/create/custom-yml.png b/images/pipeline/create/custom-yml.png deleted file mode 100644 index 925d9ad8..00000000 Binary files a/images/pipeline/create/custom-yml.png and /dev/null differ diff --git a/images/pipeline/create/editor.png b/images/pipeline/create/editor.png deleted file mode 100644 index cea04bef..00000000 Binary files a/images/pipeline/create/editor.png and /dev/null differ diff --git a/images/pipeline/create/external-resources.png b/images/pipeline/create/external-resources.png deleted file mode 100644 index 559439dc..00000000 Binary files a/images/pipeline/create/external-resources.png and /dev/null differ diff --git a/images/pipeline/create/inline-editor.png b/images/pipeline/create/inline-editor.png deleted file mode 100644 index 94c82166..00000000 Binary files a/images/pipeline/create/inline-editor.png and /dev/null differ diff --git a/images/pipeline/create/pipeline-from-internal-repo.png b/images/pipeline/create/pipeline-from-internal-repo.png deleted file mode 100644 index 29d47914..00000000 Binary files a/images/pipeline/create/pipeline-from-internal-repo.png and /dev/null differ diff --git a/images/pipeline/create/pipeline-manager.png b/images/pipeline/create/pipeline-manager.png deleted file mode 100644 index 0018fa70..00000000 Binary files a/images/pipeline/create/pipeline-manager.png and /dev/null differ diff --git a/images/pipeline/create/pipelines-from-repository.png b/images/pipeline/create/pipelines-from-repository.png deleted file mode 100644 index b1205e53..00000000 Binary files a/images/pipeline/create/pipelines-from-repository.png and /dev/null differ diff --git a/images/pipeline/create/pipelines-no-repository.png b/images/pipeline/create/pipelines-no-repository.png deleted file mode 100644 index 7b9c7e39..00000000 Binary files a/images/pipeline/create/pipelines-no-repository.png and /dev/null differ diff --git a/images/pipeline/create/predefined-steps.png b/images/pipeline/create/predefined-steps.png deleted file mode 100644 index 15a6939d..00000000 Binary files a/images/pipeline/create/predefined-steps.png and /dev/null differ diff --git a/images/pipeline/create/restrict-parallelism.png b/images/pipeline/create/restrict-parallelism.png deleted file mode 100644 index d6c3c613..00000000 Binary files a/images/pipeline/create/restrict-parallelism.png and /dev/null differ diff --git a/images/pipeline/create/template-dialog.png b/images/pipeline/create/template-dialog.png deleted file mode 100644 index b359eea2..00000000 Binary files a/images/pipeline/create/template-dialog.png and /dev/null differ diff --git a/images/pipeline/create/template-tag.png b/images/pipeline/create/template-tag.png deleted file mode 100644 index bd950367..00000000 Binary files a/images/pipeline/create/template-tag.png and /dev/null differ diff --git a/images/pipeline/create/use-template.png b/images/pipeline/create/use-template.png deleted file mode 100644 index 1eaa5ccc..00000000 Binary files a/images/pipeline/create/use-template.png and /dev/null differ diff --git a/images/pipeline/debug/alternative-debugger.png b/images/pipeline/debug/alternative-debugger.png deleted file mode 100644 index a8ba1f94..00000000 Binary files a/images/pipeline/debug/alternative-debugger.png and /dev/null differ diff --git a/images/pipeline/debug/breakpoint.png b/images/pipeline/debug/breakpoint.png deleted file mode 100644 index c60a2adc..00000000 Binary files a/images/pipeline/debug/breakpoint.png and /dev/null differ diff --git a/images/pipeline/debug/debug-session.png b/images/pipeline/debug/debug-session.png deleted file mode 100644 index c544385b..00000000 Binary files a/images/pipeline/debug/debug-session.png and /dev/null differ diff --git a/images/pipeline/debug/debug-window.png b/images/pipeline/debug/debug-window.png deleted file mode 100644 index a5595112..00000000 Binary files a/images/pipeline/debug/debug-window.png and /dev/null differ diff --git a/images/pipeline/debug/enter-debug-mode.png b/images/pipeline/debug/enter-debug-mode.png deleted file mode 100644 index da99671d..00000000 Binary files a/images/pipeline/debug/enter-debug-mode.png and /dev/null differ diff --git a/images/pipeline/debug/restart-in-debug.png b/images/pipeline/debug/restart-in-debug.png deleted file mode 100644 index b663c547..00000000 Binary files a/images/pipeline/debug/restart-in-debug.png and /dev/null differ diff --git a/images/pipeline/debug/resume-button.png b/images/pipeline/debug/resume-button.png deleted file mode 100644 index f2b49f1c..00000000 Binary files a/images/pipeline/debug/resume-button.png and /dev/null differ diff --git a/images/pipeline/debug/run-pipeline-debug.png b/images/pipeline/debug/run-pipeline-debug.png deleted file mode 100644 index 6299efe9..00000000 Binary files a/images/pipeline/debug/run-pipeline-debug.png and /dev/null differ diff --git a/images/pipeline/monitoring/build-badge.png b/images/pipeline/monitoring/build-badge.png deleted file mode 100644 index a69bff75..00000000 Binary files a/images/pipeline/monitoring/build-badge.png and /dev/null differ diff --git a/images/pipeline/monitoring/build-details-entry.png b/images/pipeline/monitoring/build-details-entry.png deleted file mode 100644 index 611fe317..00000000 Binary files a/images/pipeline/monitoring/build-details-entry.png and /dev/null differ diff --git a/images/pipeline/monitoring/build-filter-date.png b/images/pipeline/monitoring/build-filter-date.png deleted file mode 100644 index 2e2d1959..00000000 Binary files a/images/pipeline/monitoring/build-filter-date.png and /dev/null differ diff --git a/images/pipeline/monitoring/build-filtering.png b/images/pipeline/monitoring/build-filtering.png deleted file mode 100644 index 7111a0a9..00000000 Binary files a/images/pipeline/monitoring/build-filtering.png and /dev/null differ diff --git a/images/pipeline/monitoring/build-logs.png b/images/pipeline/monitoring/build-logs.png deleted file mode 100644 index 46719e8f..00000000 Binary files a/images/pipeline/monitoring/build-logs.png and /dev/null differ diff --git a/images/pipeline/monitoring/build-view-selection.png b/images/pipeline/monitoring/build-view-selection.png deleted file mode 100644 index de81d11f..00000000 Binary files a/images/pipeline/monitoring/build-view-selection.png and /dev/null differ diff --git a/images/pipeline/monitoring/builds-dashboard.png b/images/pipeline/monitoring/builds-dashboard.png deleted file mode 100644 index 18ebdcf5..00000000 Binary files a/images/pipeline/monitoring/builds-dashboard.png and /dev/null differ diff --git a/images/pipeline/monitoring/monitor-activity-log.png b/images/pipeline/monitoring/monitor-activity-log.png new file mode 100644 index 00000000..18704ee9 Binary files /dev/null and b/images/pipeline/monitoring/monitor-activity-log.png differ diff --git a/images/pipeline/monitoring/monitor-aggregated-view.png b/images/pipeline/monitoring/monitor-aggregated-view.png new file mode 100644 index 00000000..8053432f Binary files /dev/null and b/images/pipeline/monitoring/monitor-aggregated-view.png differ diff --git a/images/pipeline/monitoring/monitor-pipeline-workflow-details.png b/images/pipeline/monitoring/monitor-pipeline-workflow-details.png new file mode 100644 index 00000000..12fdd54f Binary files /dev/null and b/images/pipeline/monitoring/monitor-pipeline-workflow-details.png differ diff --git a/images/pipeline/monitoring/monitor-workflows-tab-popup.png b/images/pipeline/monitoring/monitor-workflows-tab-popup.png new file mode 100644 index 00000000..5659a513 Binary files /dev/null and b/images/pipeline/monitoring/monitor-workflows-tab-popup.png differ diff --git a/images/pipeline/monitoring/monitor-workflows-tab.png b/images/pipeline/monitoring/monitor-workflows-tab.png new file mode 100644 index 00000000..ed3d338f Binary files /dev/null and b/images/pipeline/monitoring/monitor-workflows-tab.png differ diff --git a/images/pipeline/monitoring/pipeline-activity-log-toolbar.png b/images/pipeline/monitoring/pipeline-activity-log-toolbar.png new file mode 100644 index 00000000..271fb6b1 Binary files /dev/null and b/images/pipeline/monitoring/pipeline-activity-log-toolbar.png differ diff --git a/images/pipeline/monitoring/pipeline-list-view.png b/images/pipeline/monitoring/pipeline-list-view.png new file mode 100644 index 00000000..6012bbfa Binary files /dev/null and b/images/pipeline/monitoring/pipeline-list-view.png differ diff --git a/images/pipeline/monitoring/pipeline-metrics.png b/images/pipeline/monitoring/pipeline-metrics.png deleted file mode 100644 index 3a775238..00000000 Binary files a/images/pipeline/monitoring/pipeline-metrics.png and /dev/null differ diff --git a/images/pipeline/monitoring/pipeline-view.png b/images/pipeline/monitoring/pipeline-view.png deleted file mode 100644 index ae7acacb..00000000 Binary files a/images/pipeline/monitoring/pipeline-view.png and /dev/null differ diff --git a/images/pipeline/monitoring/possible-filters.png b/images/pipeline/monitoring/possible-filters.png deleted file mode 100644 index 476151ba..00000000 Binary files a/images/pipeline/monitoring/possible-filters.png and /dev/null differ diff --git a/images/pipeline/monitoring/quick-pipeline-metrics.png b/images/pipeline/monitoring/quick-pipeline-metrics.png deleted file mode 100644 index 59f75888..00000000 Binary files a/images/pipeline/monitoring/quick-pipeline-metrics.png and /dev/null differ diff --git a/images/pipeline/monitoring/report-notification-checkbox.png b/images/pipeline/monitoring/report-notification-checkbox.png deleted file mode 100644 index ef92dce2..00000000 Binary files a/images/pipeline/monitoring/report-notification-checkbox.png and /dev/null differ diff --git a/images/pipeline/monitoring/restart-failed.png b/images/pipeline/monitoring/restart-failed.png deleted file mode 100644 index f114e369..00000000 Binary files a/images/pipeline/monitoring/restart-failed.png and /dev/null differ diff --git a/images/pipeline/monitoring/restart-pipeline.png b/images/pipeline/monitoring/restart-pipeline.png deleted file mode 100644 index d5018e4b..00000000 Binary files a/images/pipeline/monitoring/restart-pipeline.png and /dev/null differ diff --git a/images/pipeline/monitoring/restart-step.png b/images/pipeline/monitoring/restart-step.png deleted file mode 100644 index 1c823f73..00000000 Binary files a/images/pipeline/monitoring/restart-step.png and /dev/null differ diff --git a/images/pipeline/monitoring/show-yaml.png b/images/pipeline/monitoring/show-yaml.png deleted file mode 100644 index 235d9f41..00000000 Binary files a/images/pipeline/monitoring/show-yaml.png and /dev/null differ diff --git a/images/pipeline/monitoring/step-metrics.png b/images/pipeline/monitoring/step-metrics.png deleted file mode 100644 index df68bf75..00000000 Binary files a/images/pipeline/monitoring/step-metrics.png and /dev/null differ diff --git a/images/pipeline/monitoring/step-state.png b/images/pipeline/monitoring/step-state.png deleted file mode 100644 index 48aa42d9..00000000 Binary files a/images/pipeline/monitoring/step-state.png and /dev/null differ diff --git a/images/pipeline/monitoring/view-pipeline-state.png b/images/pipeline/monitoring/view-pipeline-state.png deleted file mode 100644 index 62c0b9b8..00000000 Binary files a/images/pipeline/monitoring/view-pipeline-state.png and /dev/null differ diff --git a/images/pipeline/monitoring/view-pipeline-yaml.png b/images/pipeline/monitoring/view-pipeline-yaml.png deleted file mode 100644 index 943f85af..00000000 Binary files a/images/pipeline/monitoring/view-pipeline-yaml.png and /dev/null differ diff --git a/images/pipeline/monitoring/yaml-from-step.png b/images/pipeline/monitoring/yaml-from-step.png deleted file mode 100644 index 997ebb58..00000000 Binary files a/images/pipeline/monitoring/yaml-from-step.png and /dev/null differ diff --git a/images/runtime/edit-git-source.png b/images/runtime/edit-git-source.png new file mode 100644 index 00000000..c1f7a3d9 Binary files /dev/null and b/images/runtime/edit-git-source.png differ diff --git a/images/runtime/managed-cluster-add-panel.png b/images/runtime/managed-cluster-add-panel.png new file mode 100644 index 00000000..5cd4f663 Binary files /dev/null and b/images/runtime/managed-cluster-add-panel.png differ diff --git a/images/runtime/managed-cluster-add.png b/images/runtime/managed-cluster-add.png new file mode 100644 index 00000000..32199e42 Binary files /dev/null and b/images/runtime/managed-cluster-add.png differ diff --git a/images/runtime/runtiime-topology-uninstall.xcf b/images/runtime/runtiime-topology-uninstall.xcf new file mode 100644 index 00000000..67bec9f9 Binary files /dev/null and b/images/runtime/runtiime-topology-uninstall.xcf differ diff --git a/images/runtime/runtiime-topology-upgrade.png b/images/runtime/runtiime-topology-upgrade.png new file mode 100644 index 00000000..c6b74337 Binary files /dev/null and b/images/runtime/runtiime-topology-upgrade.png differ diff --git a/images/runtime/runtiime-topology-upgrade.xcf b/images/runtime/runtiime-topology-upgrade.xcf new file mode 100644 index 00000000..224913a0 Binary files /dev/null and b/images/runtime/runtiime-topology-upgrade.xcf differ diff --git a/images/runtime/runtime-activity-log.png b/images/runtime/runtime-activity-log.png new file mode 100644 index 00000000..64e4f6b5 Binary files /dev/null and b/images/runtime/runtime-activity-log.png differ diff --git a/images/runtime/runtime-health-sync-errors.png b/images/runtime/runtime-health-sync-errors.png new file mode 100644 index 00000000..1ec67844 Binary files /dev/null and b/images/runtime/runtime-health-sync-errors.png differ diff --git a/images/runtime/runtime-list-drilldown.png b/images/runtime/runtime-list-drilldown.png new file mode 100644 index 00000000..2cb015d5 Binary files /dev/null and b/images/runtime/runtime-list-drilldown.png differ diff --git a/images/runtime/runtime-list-view-managed-cluster.png b/images/runtime/runtime-list-view-managed-cluster.png new file mode 100644 index 00000000..e784c27c Binary files /dev/null and b/images/runtime/runtime-list-view-managed-cluster.png differ diff --git a/images/runtime/runtime-list-view-upgrade.png b/images/runtime/runtime-list-view-upgrade.png new file mode 100644 index 00000000..2cb015d5 Binary files /dev/null and b/images/runtime/runtime-list-view-upgrade.png differ diff --git a/images/runtime/runtime-list-view.png b/images/runtime/runtime-list-view.png new file mode 100644 index 00000000..a968f126 Binary files /dev/null and b/images/runtime/runtime-list-view.png differ diff --git a/images/runtime/runtime-topology-uninstall.png b/images/runtime/runtime-topology-uninstall.png new file mode 100644 index 00000000..0514a6a9 Binary files /dev/null and b/images/runtime/runtime-topology-uninstall.png differ diff --git a/images/runtime/runtime-topology-view.png b/images/runtime/runtime-topology-view.png new file mode 100644 index 00000000..793ebae5 Binary files /dev/null and b/images/runtime/runtime-topology-view.png differ diff --git a/images/runtime/runtime-topology-view.xcf b/images/runtime/runtime-topology-view.xcf new file mode 100644 index 00000000..14658d65 Binary files /dev/null and b/images/runtime/runtime-topology-view.xcf differ diff --git a/images/view-native-workflow.png b/images/view-native-workflow.png new file mode 100644 index 00000000..5b11fe8b Binary files /dev/null and b/images/view-native-workflow.png differ diff --git a/images/workflows/argo-event-steps.png b/images/workflows/argo-event-steps.png new file mode 100644 index 00000000..f1e567c7 Binary files /dev/null and b/images/workflows/argo-event-steps.png differ diff --git a/images/workflows/argo-events-in-wrkflow.png b/images/workflows/argo-events-in-wrkflow.png new file mode 100644 index 00000000..3d4eca9a Binary files /dev/null and b/images/workflows/argo-events-in-wrkflow.png differ diff --git a/images/workflows/dashboard-workflows-in-pipeline.png b/images/workflows/dashboard-workflows-in-pipeline.png new file mode 100644 index 00000000..721942b7 Binary files /dev/null and b/images/workflows/dashboard-workflows-in-pipeline.png differ diff --git a/images/workflows/delete-workflow.png b/images/workflows/delete-workflow.png new file mode 100644 index 00000000..58c99e27 Binary files /dev/null and b/images/workflows/delete-workflow.png differ diff --git a/images/workflows/event-payload.png b/images/workflows/event-payload.png new file mode 100644 index 00000000..0c477519 Binary files /dev/null and b/images/workflows/event-payload.png differ diff --git a/images/workflows/event-source.png b/images/workflows/event-source.png new file mode 100644 index 00000000..0b1e80dc Binary files /dev/null and b/images/workflows/event-source.png differ diff --git a/images/workflows/failed-steps-search.png b/images/workflows/failed-steps-search.png new file mode 100644 index 00000000..ca999e14 Binary files /dev/null and b/images/workflows/failed-steps-search.png differ diff --git a/images/workflows/filters-workflow-steps.png b/images/workflows/filters-workflow-steps.png new file mode 100644 index 00000000..549fff03 Binary files /dev/null and b/images/workflows/filters-workflow-steps.png differ diff --git a/images/workflows/monitor-step-analytics.png b/images/workflows/monitor-step-analytics.png new file mode 100644 index 00000000..3ac25447 Binary files /dev/null and b/images/workflows/monitor-step-analytics.png differ diff --git a/images/workflows/resubmit-workflow.png b/images/workflows/resubmit-workflow.png new file mode 100644 index 00000000..458ad90a Binary files /dev/null and b/images/workflows/resubmit-workflow.png differ diff --git a/images/workflows/retry-workflow.png b/images/workflows/retry-workflow.png new file mode 100644 index 00000000..824ceb5a Binary files /dev/null and b/images/workflows/retry-workflow.png differ diff --git a/images/workflows/step-error-yaml.png b/images/workflows/step-error-yaml.png new file mode 100644 index 00000000..6f0fddaf Binary files /dev/null and b/images/workflows/step-error-yaml.png differ diff --git a/images/workflows/view-logs-logs-tab.png b/images/workflows/view-logs-logs-tab.png new file mode 100644 index 00000000..9faad2c5 Binary files /dev/null and b/images/workflows/view-logs-logs-tab.png differ diff --git a/images/workflows/view-logs-pull-out.png b/images/workflows/view-logs-pull-out.png new file mode 100644 index 00000000..78c4f0ab Binary files /dev/null and b/images/workflows/view-logs-pull-out.png differ diff --git a/images/workflows/workflow-argo-ui.png b/images/workflows/workflow-argo-ui.png new file mode 100644 index 00000000..bcd2c0f7 Binary files /dev/null and b/images/workflows/workflow-argo-ui.png differ diff --git a/images/workflows/workflow-drill-down.png b/images/workflows/workflow-drill-down.png new file mode 100644 index 00000000..f0a52ce8 Binary files /dev/null and b/images/workflows/workflow-drill-down.png differ diff --git a/images/workflows/workflow-error-notification.png b/images/workflows/workflow-error-notification.png new file mode 100644 index 00000000..ab3a3f00 Binary files /dev/null and b/images/workflows/workflow-error-notification.png differ diff --git a/images/workflows/workflow-error-notifications-open.png b/images/workflows/workflow-error-notifications-open.png new file mode 100644 index 00000000..bc250b1c Binary files /dev/null and b/images/workflows/workflow-error-notifications-open.png differ diff --git a/images/workflows/workflow-pod-step.png b/images/workflows/workflow-pod-step.png new file mode 100644 index 00000000..7f825da9 Binary files /dev/null and b/images/workflows/workflow-pod-step.png differ diff --git a/images/workflows/workflow-steps-failed.png b/images/workflows/workflow-steps-failed.png new file mode 100644 index 00000000..2d865773 Binary files /dev/null and b/images/workflows/workflow-steps-failed.png differ diff --git a/images/workflows/workflow-steps.png b/images/workflows/workflow-steps.png new file mode 100644 index 00000000..e70d1386 Binary files /dev/null and b/images/workflows/workflow-steps.png differ diff --git a/images/workflows/workflows-dashboard.png b/images/workflows/workflows-dashboard.png new file mode 100644 index 00000000..7fc434bc Binary files /dev/null and b/images/workflows/workflows-dashboard.png differ diff --git a/managed-cluster.md b/managed-cluster.md new file mode 100644 index 00000000..0033af54 --- /dev/null +++ b/managed-cluster.md @@ -0,0 +1,262 @@ +--- +title: "Add and manage external clusters" +description: "" +group: runtime +toc: true +--- + +Manage external clusters in CSDP by registering them to provisioned runtimes. Instead of having a runtime per cluster, manage multiple clusters through a single runtime with the spoke-and-hub method. + +When you add an external cluster to a provisioned runtime, the cluster is registered as a managed cluster. A managed cluster is treated as any other managed K8s resource, meaning that you can monitor its health and sync status, deploy applications on the cluster and view information in the Applications dashboard, and remove the cluster from the runtime's managed list. + +Add managed clusters in CSDP: +* Through the CLI +* Kustomize +* Helm + +Doing so via CSDP ensures that CSDP applies the required RBAC resources (`ServiceAccount`, `ClusterRole` and `ClusterRoleBinding`) to the target cluster, creates a `Job` that updates the selected runtime with the information, registers the cluster in Argo CD as a managed cluster, and updates the platform with the new cluster information. + +### How to add a managed cluster with CSDP CLI +Add the external cluster to a provisioned runtime through the CSDP CLI. +Optionally, to first generate the YAML manifests, and then manually apply them, use the `dry-run` flag in the CLI. + +**Before you begin** + +* Make sure your Git personal access token is valid and has the correct permissions + +**How to** + +1. In the CSDP UI, go to the [Runtimes](https://g.codefresh.io/2.0/account-settings/runtimes){:target="\_blank"} page. +1. From either the **Topology** or **List** views, select the runtime to which to add the cluster. +1. Topology View: Select ![](/images/icons/icon-add-cluster.png?display=inline-block). + List View: Select the **Managed Clusters** tab, and then select **+ Add Cluster**. +1. In the Add Managed Cluster panel: + * **Cluster Name**: Enter the context(kubecontext) for the cluster. + * Define the parameters and then run the command: + `cf cluster add --context [context_name] --dry-run` + where: + `` is the runtime to which to register the cluster. The name of the selected runtime is automatically added. + `` is the kube context with the credentials to communicate with the managed cluster. If not supplied, the CLI displays the list of available clusters as defined in `kubeconfig`. + `--dry-run` is optional, and required if you want to generate a list of YAML manifests that you can redirect and apply manually with `kubectl`. + + {% include + image.html + lightbox="true" + file="/images/runtime/managed-cluster-add-panel.png" + url="/images/runtime/managed-cluster-add-panel.png" + alt="Add Managed Cluster panel" + caption="Add Managed Cluster panel" + max-width="30%" +%} + +{:start="5"} +1. If you used `dry-run`, apply the generated manifests to the same target cluster on which you ran the command. + Define the `server` value as the cluster's API server endpoint. + Here is an example of the YAML manifest generated with the `--dry-run` flag. Note that there are placeholders instead of actual values for several attributes. + + +```yaml +apiVersion: v1 +kind: ServiceAccount +metadata: + name: argocd-manager + namespace: kube-system +--- +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: argocd-manager-role +rules: +- apiGroups: + - '*' + resources: + - '*' + verbs: + - '*' +- nonResourceURLs: + - '*' + verbs: + - '*' +--- +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRoleBinding +metadata: + name: argocd-manager-role-binding +roleRef: + apiGroup: rbac.authorization.k8s.io + kind: ClusterRole + name: argocd-manager-role +subjects: +- kind: ServiceAccount + name: argocd-manager + namespace: kube-system +--- +apiVersion: v1 +data: + contextName: + ingressUrl: + server: +kind: ConfigMap +metadata: + name: csdp-add-cluster-cm + namespace: kube-system +--- +apiVersion: v1 +data: + csdpToken: +kind: Secret +metadata: + name: csdp-add-cluster-secret + namespace: kube-system +type: Opaque +--- +apiVersion: batch/v1 +kind: Job +metadata: + name: csdp-add-cluster-job + namespace: kube-system +spec: + template: + metadata: + name: csdp-add-cluster-pod + spec: + containers: + - args: + - ./add-cluster.sh + command: + - bash + env: + - name: SERVICE_ACCOUNT_NAME + valueFrom: + fieldRef: + fieldPath: spec.serviceAccountName + - name: INGRESS_URL + valueFrom: + configMapKeyRef: + key: ingressUrl + name: csdp-add-cluster-cm + - name: CSDP_TOKEN + valueFrom: + secretKeyRef: + key: csdpToken + name: csdp-add-cluster-secret + - name: CONTEXT_NAME + valueFrom: + configMapKeyRef: + key: contextName + name: csdp-add-cluster-cm + - name: SERVER + valueFrom: + configMapKeyRef: + key: server + name: csdp-add-cluster-cm + image: quay.io/codefresh/csdp-add-cluster:0.1.0 + imagePullPolicy: Always + name: main + resources: + limits: + cpu: "1" + memory: 512Mi + requests: + cpu: "0.2" + memory: 256Mi + restartPolicy: Never + serviceAccount: argocd-manager + ttlSecondsAfterFinished: 600 +``` + +The new cluster is registered to the runtime as a managed cluster. + +### Adding a managed cluster with Kustomize +Create a `kustomization.yaml` file with the information shown in the example below, and run `kustomize build` on it. + +```yaml +apiVersion: kustomize.config.k8s.io/v1beta1 +kind: Kustomization +namespace: kube-system + +configMapGenerator: + - name: csdp-add-cluster-cm + namespace: kube-system + behavior: merge + literals: + # contextName is the name of the kube context (in the local kubeconfig file) that connects to the target cluster + - "contextName=" + # ingressUrl is the url used to access the CSDP runtime + # example https://some.domain.name + - "ingressUrl=" + # server is the k8s cluster API endpoint url + # can be obtained by + # CONTEXT_NAME= + # CLUSTER_NAME=$(kubectl config view --raw --flatten -o jsonpath='{.contexts[?(@.name == "'"${CONTEXT_NAME}"'")].context.cluster}') + # kubectl config view --raw --flatten -o jsonpath='{.clusters[?(@.name == "'"${CLUSTER_NAME}"'")].cluster.server}' + - "server=" +secretGenerator: + - name: csdp-add-cluster-secret + namespace: kube-system + behavior: merge + literals: + # csdpToken is the user's Personal Access Token + - "csdpToken=" + +resources: + - https://github.com/codefresh-io/cli-v2/manifests/add-cluster/kustomize?ref=v +``` + +### Adding a managed cluster with Helm +Create a `values.yaml` file with the information shown in the example below, and run `helm` commands on it. + +```yaml +# serviceAccountName is the name of the ServiceAccount Argo-CD will use to access the cluster +serviceAccountName: argocd-manager + +# ingressUrl is the url used to access the CSDP runtime +# example https://some.domain.name +ingressUrl: + +# csdpToken is the user's Personal Access Token +csdpToken: + +# contextName is the name of the kube context (in the local kubeconfig file) that connects to the target cluster +contextName: + +# server is the k8s cluster API endpoint url +# can be obtained by +# CONTEXT_NAME= +# CLUSTER_NAME=$(kubectl config view --raw --flatten -o jsonpath='{.contexts[?(@.name == "'"${CONTEXT_NAME}"'")].context.cluster}') +# kubectl config view --raw --flatten -o jsonpath='{.clusters[?(@.name == "'"${CLUSTER_NAME}"'")].cluster.server}' +server: +``` + + +### Work with managed clusters +Use the Topology or List runtime views to work with managed clusters. For information on runtime views, see [Runtime views]({{site.baseurl}}/docs/runtime/runtime-views). +* Monitor cluster + View connection status for the managed cluster, and health and sync errors. Health and sync errors are flagged by the error notification in the toolbar, and visually flagged in the List and Topology views. + +* Install/uninstall cluster components + Install components on one or more managed clusters, and monitor deployed application status and data in the Applications dashboard. + Uninstalling a component from one or more managed clusters do not affect the runtime, but removes the data from those components Applications dashboard. + +* Automatic upgrade + As the components are managed as part of the runtime, updates to the runtime automatically updates the components on all the managed clusters that include it. + +* Remove cluster + Remove a cluster registered with a runtime from the runtime's list of managed clusters. + >Removing a managed cluster from a runtime also removes all the applications deployed to the cluster, and removes their data from the Applications dashboard. + +**How to** + +{:start="1"} +1. In the CSDP UI, go to the [Runtimes](https://g.codefresh.io/2.0/account-settings/runtimes){:target="\_blank"} page. +2. Select either the **Topology View** or the **List View** tabs. +3. Do one of the following: + * In the Topology View, select the cluster node from the runtime it is registered to. + * In the List View, select the runtime, and then select the **Managed Clusters** tab. +{:start="4"} +4. To uninstall a cluster component from the list, select the three dots next to the component, and then select **Uninstall**. +5. To remove the cluster from the list managed by the runtime, select the three dots next to the cluster name, and then select **Uninstall**. + +### What to read next +[Manage runtimes]({{site.baseurl}}/docs/runtime/monitor-manage-runtimes/) +[Manage Git Sources]({{site.baseurl}}/docs/runtime/git-sources/) diff --git a/monitor-manage-runtimes.md b/monitor-manage-runtimes.md new file mode 100644 index 00000000..16a3ff08 --- /dev/null +++ b/monitor-manage-runtimes.md @@ -0,0 +1,289 @@ +--- +title: "Management" +description: "" +group: runtime +toc: true +--- + + +The **Runtimes** page displays the runtimes deployed across your environment, which you can view in List or Topology view formats. +Work in the view mode of your choice to monitor and manage runtimes. + +### Runtime views +View provisioned runtimes in Topology or List view formats. +* Topology view: The default view, displays a hierarchical structure of runtimes and their clusters, with health and sync status of the associated clusters. +* List view: Displays the list of runtimes and their clusters, and Git Sources. + +To manage and monitor runtimes, see: +* [Runtime management](#runtime-management) +* [Runtime monitoring](#runtime-monitoring) + + +#### Topology view +The visualization of the runtime hierarchy in the Topology view makes it easy to identify key information such as versions, health and sync status. +Here is an example of the Topology view for runtimes. + {% include + image.html + lightbox="true" + file="/images/runtime/runtime-topology-view.png" + url="/images/runtime/runtime-topology-view.png" + alt="Runtime Topology View" + caption="Runtime Topology View" + max-width="30%" +%} + +And a description of the information in the Topology view. + +{: .table .table-bordered .table-hover} +| Topology View Item | Description | +| ------------------------| ---------------- | +|**Runtime** | ![](/images/icons/codefresh-runtime.png?display=inline-block) indicates the cluster on which the runtime is provisioned. The cluster name is identical to that of the in-cluster. | +|**Cluster** | The local, and managed clusters if any, for the runtime. {::nomarkdown}
    • indicates the local or in-cluster. The name of the local cluster is identical to that of the runtime cluster.
    • indicates a managed cluster.
    • select to add a new managed cluster.
    To view cluster components, select the cluster.
    To add and work with managed clusters, see [Managed clusters]({{site.baseurl}}/docs/runtime/managed-cluster.md). {:/}| +|**Health/Sync status** |The health and sync status of the runtime or cluster. {::nomarkdown}
    • indicates health or sync errors in the runtime, or a managed cluster if one was added to the runtime.
      The runtime or cluster node is bordered in red and the name is colored red.
    • indicates that the runtime is being synced to the cluster on which it is provisioned.
    {:/} | +|**Search and View options** | {::nomarkdown}
    • Find a runtime or its clusters by typing part of the runtime/cluster name, and then navigate to the entries found.
    • Topology view options: Resize to window, zoom in, zoom out, full screen view.
    {:/}| + + + +#### List view +The List view is a grid-view of the provisioned runtimes. + +Here is an example of the List view for runtimes. +{% include + image.html + lightbox="true" + file="/images/runtime/runtime-list-view.png" + url="/images/runtime/runtime-list-view.png" + alt="Runtime List View" + caption="Runtime List View" + max-width="30%" +%} + +And a description of key information in the List view. + +{: .table .table-bordered .table-hover} +| List View Item| Description | +| -------------- | ---------------- | +|**Status**| The health and sync status of the runtime or cluster. {::nomarkdown}
    • indicates health or sync errors in the runtime, or a managed cluster if one was added to the runtime.
      The runtime name is colored red.
    • indicates that the runtime is being synced to the cluster on which it is provisioned.
    {:/} | +|**Managed Cluster**| The number of managed clusters if any, for the runtime. To view list of managed clusters, select the runtime, and then the **Managed Clusters** tab. To work with managed clusters, see [Runtime Management](#runtime-management) in this article.| +|**Version**|**Update Available!** indicates there are later versions of the runtime. To see all the commits to the runtime, mouse over **Update Available!**, and select **View Complete Change Log**.| + + +### Runtime management +Work in either the Topology or the List views to manage runtimes: +* Add managed clusters to runtimes (see [Managed Clusters]({{site.baseurl}}/docs/runtime/managed-cluster/)) +* Manage Git Sources associated with runtimes (see [Manage Git Sources]({{site.baseurl}}/docs/runtime/git-sources/)) +* Upgrade runtimes +* Uninstall runtimes + +#### Upgrade runtimes +Upgrade existing runtimes to install critical security updates or the latest version of all components. Upgrade through the CLI wizard or by running a silent upgrade. + +> When there are security updates, the UI displays the alert, _At least one runtime requires a security update_. The Version column displays an _Update Required!_ notification. + > If you have managed clusters for the runtime, upgrading the runtime automatically updates runtime components within the managed cluster as well. + +**Before you begin** +For both types of upgrades, make sure you have: + +* The latest version of the CSDP CLI +* A valid runtime Git token + +**Silent upgrade** + +Pass the mandatory flags in the upgrade command: + `cf runtime upgrade --git-token --silent` + where: + `` is a valid runtime token with the `repo` and `admin-repo.hook` scopes. + +**How to upgrade with the CLI wizard** + +1. In the CSDP UI, make sure you are in the [Runtimes](https://g.codefresh.io/2.0/account-settings/runtimes){:target="\_blank"} page. +1. Switch to either the **Topology View** or to the **List View**. +1. **Topology view**: Select the runtime cluster, and from the panel, select the three dots and then select **Upgrade Runtime**. + {% include + image.html + lightbox="true" + file="/images/runtime/runtiime-topology-upgrade.png" + url="/images/runtime/runtiime-topology-upgrade.png" + alt="Topology View: Upgrade runtime option" + caption="Topology View: Upgrade runtime option" + max-width="30%" +%} + + **List view**: + * Select the runtime name. + * To see all the commits to the runtime, in the Version column, mouse over **Update Available!**, and select **View Complete Change Log**. + * On the top-right, select **Upgrade**. + + {% include + image.html + lightbox="true" + file="/images/runtime/runtime-list-view-upgrade.png" + url="/images/runtime/runtime-list-view-upgrade.png" + alt="List View: Upgrade runtime option" + caption="List View: Upgrade runtime option" + max-width="30%" + %} + +{:start="4"} +1. If you have already installed the Codefresh CLI, in the Install Upgrades panel, copy the upgrade command. + + {% include + image.html + lightbox="true" + file="/images/runtime/install-upgrades.png" + url="/images/runtime/install-upgrades.png" + alt="Upgrade runtime" + caption="Upgrade runtime panel" + max-width="30%" +%} + +{:start="5"} +1. In your terminal, paste the command, and update the Git token value. +1. Confirm to start the upgrade. + + + +#### Uninstall runtimes +Uninstall CSDP runtimes that are not in use. Uninstall a runtime through the CLI wizard, or by running a silent uninstall. +> Uninstalling a runtime removes the Git Sources and managed clusters associated with the runtime. + +**Before you begin** +For both types of uninstalls, make sure you have: + +* The latest version of the CSDP CLI +* A valid runtime Git token +* The Kube context from which to uninstall the runtime + +**Silent uninstall** +Pass the mandatory flags in the uninstall command: + `cf runtime uninstall --context --git-token --silent` + where: + `--context` is the Kube context from which to uninstall the runtime. If not passed, uninstalls the runtime from the current Kube context. + `--git-token` is a valid runtime token with the `repo` and `admin-repo.hook` scopes. + +**How to uninstall with the CLI wizard** + +1. In the CSDP UI, make sure you are in the [Runtimes](https://g.codefresh.io/2.0/account-settings/runtimes){:target="\_blank"} page. +1. Switch to either the **Topology View** or to the **List View**. +1. **Topology view**: Select the runtime node, and from the panel, select the three dots and then select **Uninstall Runtime**. + {% include + image.html + lightbox="true" + file="/images/runtime/runtime-topology-uninstall.png" + url="/images/runtime/runtime-topology-uninstall.png" + alt="Topology View: Uninstall runtime option" + caption="Topology View: Uninstall runtime option" + max-width="30%" +%} + + **List view**: On the top-right, select the three dots and then select **Uninstall**. + + {% include + image.html + lightbox="true" + file="/images/runtime/uninstall-location.png" + url="/images/runtime/uninstall-location.png" + alt="List View: Uninstall runtime option" + caption="List View: Uninstall runtime option" + max-width="30%" +%} + +{:start="4"} +1. If you already have the latest version of the CSDP CLI, in the Uninstall Codefresh Runtime panel, copy the uninstall command. + + {% include + image.html + lightbox="true" + file="/images/runtime/uninstall.png" + url="/images/runtime/uninstall.png" + alt="Uninstall Codefresh runtime" + caption="Uninstall Codefresh runtime" + max-width="40%" +%} + +{:start="5"} +1. In your terminal, paste the command, and update the Git token value. +1. Select the Kube context from which to uninstall the runtime, and then confirm the uninstall. +1. If you get errors, run the uninstall command again, with the `--force` flag. + +### Runtime monitoring +Monitor runtimes for security, and health and sync errors: +* Configure browsers to allow access to insecure runtimes +* Monitor notifications in the Activity Log + +#### How to configure browser to allow insecure runtimes +If at least one of your runtimes was installed in insecure mode (without an SSL certificate for the ingress controller from a CA), the UI alerts you that _At least one runtime was installed in insecure mode_. +{% include + image.html + lightbox="true" + file="/images/runtime/runtime-insecure-alert.png" + url="/images/runtime/runtime-insecure-alert.png" + alt="Insecure runtime installation alert" + caption="Insecure runtime installation alert" + max-width="100%" +%} + +All you need to do is to configure the browser to trust the URL and receive content. + +1. Select **View Runtimes** to the right of the alert. + You are taken to the Runtimes page, where you can see insecure runtimes tagged as **Allow Insecure**. + {% include + image.html + lightbox="true" + file="/images/runtime/runtime-insecure-steps.png" + url="/images/runtime/runtime-insecure-steps.png" + alt="Insecure runtimes in Runtime page" + caption="Insecure runtimes in Runtime page" + max-width="40%" +%} +{:start="2"} +1. For _every_ insecure runtime, select **Allow Insecure**, and when the browser prompts you to allow access, do as relevant: + * Chrome: Click **Advanced** and then **Proceed to site**. + * Firefox: Click **Advanced** and then **Accept the risk and continue**. + * Safari: Click **Show Certificate**, and then select **Always allow content from site**. + * Edge: Click **Advanced**, and then select **Continue to site(unsafe)**. + +#### How to view runtime notifications in Activity Log +The Activity Log is a quick way to monitor notifications for runtime events such as upgrades. A pull-down panel in the CSDP toolbar, the Activity Log shows ongoing, success, and error notifications, sorted by date, starting with today's date. + +1. In the CSDP UI, on the top-right of the toolbar, select ![](/images/pipeline/monitoring/pipeline-activity-log-toolbar.png?display=inline-block) **Activity Log**. +1. To see runtime notifications, filter by **Runtime**. + + {% include image.html + lightbox="true" + file="/images/runtime/runtime-activity-log.png" + url="/images/runtime/runtime-activity-log.png" + alt="Activity Log filtered by Runtime events" + caption="Activity Log filtered by Runtime events" + max-width="30%" + %} + +{:start="3"} +1. To see more information on an error, select the **+** sign. + +#### Troubleshoot health and sync errors +The ![](/images/icons/error.png?display=inline-block) icon with the runtime in red indicates either health or sync errors. + +**Health errors** +Health errors are generated by Argo CD and by CSDP for runtime components. + + +**Sync errors** +Runtimes with sync errors display an **Out of sync** status in Sync Status column. They are related to discrepancies between the desired and actual state of a runtime component or one of the Git sources associated with the runtime. + +**View errors** +For both views, select the runtime, and then select **Errors Detected**. +Here is an example of health errors for a runtime. + + {% include image.html + lightbox="true" + file="/images/runtime/runtime-health-sync-errors.png" + url="/images/runtime/runtime-health-sync-errors.png" + alt="Health errors for runtime example" + caption="Health errors for runtime example" + max-width="30%" + %} + +### What to read next +[Manage Git Sources]({{site.baseurl}}/docs/runtime/git-sources/) +[Managed clusters]({{site.baseurl}}/docs/runtime/managed-cluster/) \ No newline at end of file