.A comprehensive read-only view of the deployment and definition information for the application.
Manually synchronize the application.
Modify application definitions.
- Refresh: Retrieve desired (Git) state, compare with the live (cluster) state, and refresh the application to sync with the desired state.
- Hard Refresh: Refresh the application to sync with the Git state, while removing the cache.
- Quick view
A comprehensive read-only view of the deployment and definition information for the application. {:/}See [Application Quick View](#view-deployment-and-configuration-info-for-selected-application) in this article.{::nomarkdown} - Synchronize/Sync
Manually synchronize the application. {:/}See [Manually sync applications]({{site.baseurl}}/docs/deployments/gitops/manage-application/#manually-synchronize-an-application).{::nomarkdown} - Edit
Modify application definitions. {:/}See [Edit application definitions]({{site.baseurl}}/docs/deployments/gitops/manage-application/#edit-application-definitions).{::nomarkdown} - Refresh and Hard Refresh: Available in Card view only. In List view, you must first select the application.
- Refresh: Retrieve desired (Git) state, compare with the live (cluster) state, and refresh the application to sync with the desired state.
- Hard Refresh: Refresh the application to sync with the Git state, while removing the cache.
{:/} -#### Warning: Missing Rollouts reporter in cluster +### Warning: Missing Rollouts reporter in cluster **Reason**: Codefresh has detected that Argo Rollouts is not installed on the target cluster. Rollout instructions are therefore not executed and the application is not deployed. Applications with `rollout` resources need Argo Rollouts on the target cluster, both to visualize rollouts in the Applications dashboard and control rollout steps with the Rollout Player. @@ -108,7 +109,7 @@ Applications with `rollout` resources need Argo Rollouts on the target cluster,
{:/} -#### Warning: Long sync +### Warning: Long sync **Reason**: Ongoing sync for application exceeds 30 minutes (Argo CD's default duration for a sync operation). **Corrective Action**: @@ -119,7 +120,7 @@ Applications with `rollout` resources need Argo Rollouts on the target cluster, * Drill down into the application to investigate the issue and make changes. -### View deployment and configuration info for selected application +## View deployment and configuration info for selected application View deployment, definition, and event information for the selected application in a centralized location through the Quick View. A read-only view, the Quick View displays information on the application state and location, labels and annotations, parameters, sync options, manifest, status and sync events. @@ -165,7 +166,7 @@ max-width="50%" -##### Quick View: Summary +#### Quick View: Summary Displays health, sync status, and source and destination definitions. {% include @@ -178,7 +179,7 @@ caption="Application Quick View: Summary" max-width="30%" %} -##### Quick View: Metadata +#### Quick View: Metadata Displays labels and annotations for the application. {% include @@ -191,7 +192,7 @@ caption="Application Quick View: Metadata" max-width="30%" %} -##### Quick View: Parameters +#### Quick View: Parameters Displays parameters configured for the application, based on the tool used to create the application's manifests. The parameters displayed differ according to the tool: `directory` (as in the screenshot below), `Helm` charts, or `Kustomize` manifests, or the specific plugin. @@ -205,7 +206,7 @@ caption="Application Quick View: Parameters" max-width="30%" %} -##### Quick View: Sync Options +#### Quick View: Sync Options Displays sync options enabled for the application. {% include @@ -218,7 +219,7 @@ caption="Application Quick View: Parameters" max-width="30%" %} -##### Quick View: Manifest +#### Quick View: Manifest Displays the YAML version of the application manifest. {% include @@ -231,7 +232,7 @@ caption="Application Quick View: Manifest" max-width="30%" %} -##### Quick View: Events +#### Quick View: Events Displays status and sync events for the application. {% include @@ -244,7 +245,7 @@ caption="Application Quick View: Events" max-width="30%" %} -### Monitor health and sync statuses for selected application +## Monitor health and sync statuses for selected application Monitor the health status of the selected application, the current sync status, and the result of the previous sync operation. Once you select an application, the quickest option to monitor statuses is through the application header which is always displayed, no matter what tab you navigate to. @@ -274,7 +275,7 @@ max-width="40%" You can also view the current health and sync status for the application as a resource in the Current State tab. -### Monitor resources for selected application +## Monitor resources for selected application Monitor the resources deployed in the current version of the selected application in the Current State tab. Selecting an application from the Applications dashboard takes you to the Current State tab, which as its title indicates, displays the @@ -335,7 +336,7 @@ max-width="50%" -##### Working with resources in Tree view +#### Working with resources in Tree view The Tree view is designed to impart key information at a glance. Review the sections that follow for pointers to quickly get to what you need in the Tree view. **Context menu** @@ -415,7 +416,7 @@ max-width="50%" %} -#### Filters for application resources +### Filters for application resources Filters are common to both Tree and List views, and when applied are retained when switching between views. `IgnoreExtraneous` is a filter in [Argo CD](https://argo-cd.readthedocs.io/en/stable/user-guide/compare-options){:target="\_blank"} that allows you to hide specific resources from the Current State views. These resources are usually generated by a tool and their sync statuses have no impact on the sync status of the application. For example, `ConfigMap` and `pods`. The application remains in-sync even when such resources are syncing or out-of-sync. @@ -450,7 +451,7 @@ max-width="50%" %} -#### Health status for application resources +### Health status for application resources View and monitor health status of the selected application's resources in the Current State tab, in Tree or List views. Identify the health of an application resource through the color-coded border and the resource-type icon (Tree view), or the textual labels at the right of the resource (List view). @@ -469,7 +470,7 @@ See also [Argo CD's set of health checks](https://argo-cd.readthedocs.io/en/stab -#### Sync status for application resources +### Sync status for application resources Similar to the health status, the Current State also tracks the sync status of all application resources. The sync status identifies if the live state of the application resource on the cluster is synced with its desired state in Git. Identify the sync status through the icon on the left of the resource name and the color of the resource name (Tree view), or the textual labels at the right of the resource (List view). @@ -487,7 +488,7 @@ The table describes the possible sync statuses for an application resource, and > The application header displays the statuses of the current and previous sync operations. Clicking **More** opens the Sync panels with Sync Info, Sync Result and Commit Info. The Application Warnings/Errors panel surfaces sync errors on exceeding the maximum number of retries and when a sync operation extends beyond 30 minutes. -#### Manifests for application resources +### Manifests for application resources In either Tree or List views, double-click an application resource to see its manifests. The manifests are displayed in the Summary tab. > Based on the selected resource type, you can also view logs, and events. Endpoints for example show only manifests, while pods show manifests, logs, and events. @@ -519,7 +520,7 @@ Here's what you can see and do in the Summary tab:
{:/} -#### Logs for application resources +### Logs for application resources In either Tree or List views, double-click an application resource to see its logs. Logs are available only for resource types such as pods. {% include @@ -541,7 +542,7 @@ max-width="50%"
{:/} -#### Events for application resources +### Events for application resources In either Tree or List views, double-click an application resource to see events in the Events tab. > If your runtime is lower than the version required to view events, you are notified to upgrade to the required version. @@ -563,7 +564,7 @@ max-width="50%" -### Monitor deployments for selected application +## Monitor deployments for selected application Monitor an ongoing deployment for the selected application, and review its historical deployments. The Timeline tab displays the history of deployments for the selected application, sorted by the most recent deployment (default), labeled **Current Version** at the top. @@ -600,7 +601,7 @@ caption="Applications Dashboard: Deployment chart" max-width="30%" %} -#### Monitor CI details by deployment +### Monitor CI details by deployment Each deployment record displays the complete CI history for that deployment. @@ -611,7 +612,7 @@ Each deployment record displays the complete CI history for that deployment. * The **Committer** who made the changes. -#### Monitor updated resources by deployment +### Monitor updated resources by deployment Each deployment record also identifies the resources that were changed (created, updated, or removed) as part of that deployment in **Updated Resources**. You can trace the history of a resource, from the original to their final versions. For each version, you can see the actual change or changes through the Diff view. The Full View shows the complete resource manifest, with the diff view of the changes, while the Compact View shows only those lines with the changes. > For detailed information on the current state of a resource, switch to the Current State tab and click the resource node. See [Monitoring application resources](#monitoring-application-resources). @@ -657,15 +658,15 @@ max-width="70%" -#### Monitor rollouts by deployment +### Monitor rollouts by deployment A rollout is initiated when there is an Argo CD sync due to a change in the desired state. Visualize ongoing and completed rollouts by deployments in **Services**. -> To view and manage a rollout, you must have an Argo `rollout` resource defined for your application, and [install Argo Rollouts in the cluster]({site.baseurl}}/docs/_docs/deployment/install-argo-rollouts). +> To view and manage a rollout, you must have an Argo `rollout` resource defined for your application, and [install Argo Rollouts in the cluster]({site.baseurl}}/docs/deployments/gitops/install-argo-rollouts). For detailed information on Argo Rollouts, see [Argo Rollouts documentation](https://argoproj.github.io/argo-rollouts/){:target="\_blank"}. -##### Rollout progress +#### Rollout progress For an ongoing rollout, the rollout bar displays the progress of the rollout. You can also visualize the steps in the rollout, and control the rollout using the options in the Rollout Player. Here is an example of an ongoing rollout for a canary deployment in Updated Services. The rollout comprising four steps has not started, and no traffic has not been routed as yet to the new version of the application. @@ -693,7 +694,7 @@ caption="Rollout completed for deployment" max-width="50%" %} -##### Manage ongoing rollout +#### Manage ongoing rollout Click the rollout name to visualize its steps. Manually manage the rollout through the controls in the Rollout Player. Here you can see that two out of four steps have been completed, 25% of the traffic has been routed, and the rollout has been paused for the defined length of time. @@ -720,7 +721,7 @@ The table lists the controls in the Rollout Player to manage an ongoing rollout. -##### View analysis run +#### View analysis run If you have defined an analysis template for the rollout, you can check the run results and the manifest. The result of an analysis run determines if the rollout is completed, paused, or aborted. For detailed information, see the [Analysis section in Argo Rollouts](https://argoproj.github.io/argo-rollouts/features/analysis/){:target="\_blank"}. @@ -749,7 +750,7 @@ max-width="50%" %} -### Monitor services for selected application +## Monitor services for selected application The Services tab 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. @@ -765,6 +766,10 @@ caption="Applications Dashboard: Services tab" max-width="50%" %} - +## Related articles +[Creating GitOps applications]({{site.baseurl}})/docs/deployments/gitops/create-application) +[Managing GitOps applications]({{site.baseurl}})/docs/deployments/gitops/manage-applications) +[Home dashboard]({{site.baseurl}}/docs/reporting/home-dashboard) +[DORA metrics]({{site.baseurl}}/docs/reporting/dora-metrics/) diff --git a/_docs/deployment/create-application.md b/_docs/deployments/gitops/create-application.md similarity index 96% rename from _docs/deployment/create-application.md rename to _docs/deployments/gitops/create-application.md index 47aea2d7..27425172 100644 --- a/_docs/deployment/create-application.md +++ b/_docs/deployments/gitops/create-application.md @@ -1,7 +1,8 @@ --- -title: "Creating applications" +title: "Creating GitOps applications" description: "" -group: deployment +group: deployments +sub_group: gitops toc: true --- @@ -19,7 +20,7 @@ Codefresh provides all the options and functionality to create and manage Argo C * Edit and delete applications Once the application is created and synced to the cluster, it is displayed in the Applications dashboard. Here, you can select an application to update the application's configuration settings, or delete it. - To monitor the health and sync status, deployments, and resources for the application, see [Monitoring applications]({{site.baseurl}}/docs/deployment/applications-dashboard/). + To monitor the health and sync status, deployments, and resources for the application, see [Monitoring GitOps applications]({{site.baseurl}}/docs/deployments/gitops/applications-dashboard/). ### Application: Definitions Application definitions include the name, runtime, and the name of the YAML manifest. By default, the YAML manifest has the same name as that of the application. @@ -225,7 +226,7 @@ Track the application in the [Applications dashboard](https://g.codefresh.io/2.0 ### Related articles -[Monitoring applications]({{site.baseurl}})/docs/deployment/applications-dashboard) -[Managing applications]({{site.baseurl}})/docs/deployment/manage-applications) -[Home dashboard]({{site.baseurl}})docs/reporting/home-dashboard) -[DORA metrics]({{site.baseurl}}/docs/reporting/dora-metrics/) \ No newline at end of file +[Monitoring GitOps applications]({{site.baseurl}})/docs/deployments/gitops/applications-dashboard) +[Managing GitOps applications]({{site.baseurl}})/docs/deployments/gitops/manage-applications) +[Home dashboard]({{site.baseurl}}/docs/reporting/home-dashboard) +[DORA metrics]({{site.baseurl}}/docs/reporting/dora-metrics/) \ No newline at end of file diff --git a/_docs/deployment/images.md b/_docs/deployments/gitops/images.md similarity index 92% rename from _docs/deployment/images.md rename to _docs/deployments/gitops/images.md index d4538a52..eb46e3d9 100644 --- a/_docs/deployment/images.md +++ b/_docs/deployments/gitops/images.md @@ -1,7 +1,8 @@ --- title: "Images in Codefresh" description: "" -group: deployment +group: deployments +sub_group: gitops toc: true --- @@ -18,7 +19,7 @@ Complete the mandatory steps to see your Images in the Codefresh UI. Each step h 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. -> If you are using an external GitHub Actions-based pipeline, we have a new template that combines image reporting and enrichment. See [Image enrichment with integrations]({{site.baseurl}}/docs/integrations/image-enrichment-overview/). +> If you are using an external GitHub Actions-based pipeline, we have a new template that combines image reporting and enrichment. See [Image enrichment with integrations]({{site.baseurl}}/docs/integrations/gitops/image-enrichment-overview/). ### Image views in Codefresh * In the Codefresh UI, go to [Images](https://g.codefresh.io/2.0/images){:target="\_blank"}. @@ -111,3 +112,9 @@ Selecting **more details** for an image tag. | **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. | + +## Related articles +[Creating GitOps applications]({{site.baseurl}})/docs/deployments/gitops/create-application) +[Managing GitOps applications]({{site.baseurl}})/docs/deployments/gitops/manage-applications) +[Image enrichment with integrations]({{site.baseurl}}/integrations/image-enrichment-overview) +[Home dashboard]({{site.baseurl}}/docs/reporting/home-dashboard) diff --git a/_docs/deployment/install-argo-rollouts.md b/_docs/deployments/gitops/install-argo-rollouts.md similarity index 74% rename from _docs/deployment/install-argo-rollouts.md rename to _docs/deployments/gitops/install-argo-rollouts.md index 22f6afb7..0847b58c 100644 --- a/_docs/deployment/install-argo-rollouts.md +++ b/_docs/deployments/gitops/install-argo-rollouts.md @@ -1,12 +1,13 @@ --- -title: "Install Argo Rollouts" +title: "Progressive delivery with GitOps" description: "" -group: deployment +group: deployments +sub_group: gitops toc: true --- -Install Argo Rollouts on managed clusters with a single click. With Argo Rollouts installed on your cluster, you can visualize rollout progress for deployed applications in the [Applications dashboard]({{site.baseurl}}/docs/deployment/applications-dashboard/#rollout-progress-visualization). +Install Argo Rollouts on managed clusters with a single click. With Argo Rollouts installed on your cluster, you can visualize rollout progress for deployed applications in the [Applications dashboard]({{site.baseurl}}/docs/deployments/gitops/applications-dashboard/#rollout-progress-visualization). If Argo Rollouts has not been installed, an **Install Argo Rollouts** button is displayed on selecting the managed cluster. 1. In the Codefresh UI, go to [Runtimes](https://g.codefresh.io/2.0/account-settings/runtimes){:target="\_blank"}. @@ -24,4 +25,4 @@ If Argo Rollouts has not been installed, an **Install Argo Rollouts** button is %} ### Related articles -[Add external clusters to runtimes]({{site.baseurl}}/docs/runtime/managed-cluster/) \ No newline at end of file +[Add external clusters to runtimes]({{site.baseurl}}/docs/installation/managed-cluster/) \ No newline at end of file diff --git a/_docs/deployment/manage-application.md b/_docs/deployments/gitops/manage-application.md similarity index 96% rename from _docs/deployment/manage-application.md rename to _docs/deployments/gitops/manage-application.md index 2ccd3e16..15a0049d 100644 --- a/_docs/deployment/manage-application.md +++ b/_docs/deployments/gitops/manage-application.md @@ -1,7 +1,8 @@ --- -title: "Managing applications" +title: "Managing GitOps applications" description: "" -group: deployment +group: deployments +sub_group: gitops toc: true --- @@ -49,8 +50,8 @@ Update General or Advanced configuration settings for a deployed application thr {:start="3"} 1. Update the **General** or **Advanced** configuration settings as needed: - [General configuration]({{site.baseurl}}/docs/deployment/create-application/#application-general-configuration-settings) - [Advanced configuration]({{site.baseurl}}/docs/deployment/create-application/#application-advanced-configuration-settings) + [General configuration]({{site.baseurl}}/docs/deployments/gitops/create-application/#application-general-configuration-settings) + [Advanced configuration]({{site.baseurl}}/docs/deployments/gitops/create-application/#application-advanced-configuration-settings) When you change a setting, the Commit and Discard Changes buttons are displayed. {% include @@ -218,7 +219,7 @@ For example, if you made changes to `api` resources or `audit` resources, type ` Delete an application from Codefresh. Deleting an application deletes the manifest from the Git repository, and then from the cluster where it is deployed. When deleted from the cluster, the application is removed from the Applications dashboard in Codefresh. >**Prune resources** in the application's General settings determines the scope of the delete action. -When selected, both the application and its resources are deleted. When cleared, only the application is deleted. For more information, review [Sync settings]({{site.baseurl}}/docs/deployment/create-application/#sync-settings). +When selected, both the application and its resources are deleted. When cleared, only the application is deleted. For more information, review [Sync settings]({{site.baseurl}}/docs/deployments/gitops/create-application/#sync-settings). Codefresh warns you of the implication of deleting the selected application in the Delete form. 1. In the Codefresh UI, go to the [Applications dashboard](https://g.codefresh.io/2.0/applications-dashboard/list){:target="\_blank"}. @@ -351,10 +352,9 @@ The table describes the options for the `Rollout` resource. ### Related articles -[Creating applications]({{site.baseurl}}/docs/deployment/create-application) +[Creating GitOps applications]({{site.baseurl}}/docs/deployments/gitops/create-application) [Home dashboard]({{site.baseurl}}/docs/reporting/home-dashboard) -[DORA metrics]({{site.baseurl}}/docs/reporting/dora-metrics) - +[DORA metrics]({{site.baseurl}}/docs/reporting/dora-metrics) diff --git a/_docs/deployments/helm/custom-helm-uploads.md b/_docs/deployments/helm/custom-helm-uploads.md new file mode 100644 index 00000000..46da0a4d --- /dev/null +++ b/_docs/deployments/helm/custom-helm-uploads.md @@ -0,0 +1,125 @@ +--- +title: "Creating and uploading Helm packages" +description: "Manually create and upload Helm packages" +group: deployments +sub_group: helm +redirect_from: + - /docs/create-helm-artifacts-using-codefresh-pipeline/ +toc: true +--- + +Helm packages are just TAR files. Helm repositories are simple file hierarchies with an extra [index.yaml](https://helm.sh/docs/developing_charts/#the-chart-repository-structure){:target="\_blank"}. +You can run custom commands and manually upload indexes and packages to a Helm repo. + +>This articles shows some non-standard Helm examples. + For the basic use cases, or if you are just getting started with Helm, see our [Helm quick start guide]({{site.baseurl}}/docs/getting-started/helm-quick-start-guide/) and [Using Helm in CI pipelines]({{site.baseurl}}/docs/deployments/helm/using-helm-in-codefresh-pipeline/). + +## Package a Helm chart +Below is an example of a freestyle step in a Codefresh pipeline that packages the Helm chart and then extracts the chart name from the command output. It also saves that package name in an environment variable for later use. + + `YAML` +{% highlight yaml %} +{% raw %} +helm_package: + image: devth/helm + commands: + - cf_export PACKAGE=$(helm package| cut -d " " -f 8) +{% endraw %} +{% endhighlight %} + +The `helm package` command expects a path to an unpacked chart. Replace ` ` in the example with the directory that holds your chart files. Note that this directory must have the same name as the chart name, as per Helm requirements.
+See [Helm package docs](https://github.com/kubernetes/helm/blob/master/docs/helm/helm_package.md){:target="_blank"} and [Helm charts overview](https://github.com/kubernetes/helm/blob/master/docs/charts.md){:target="_blank"} for more information. + +{{site.data.callout.callout_info}} +To use `cf_export`and make the variable available to other steps in the pipeline, see [Variables in pipelines]({{site.baseurl}}/docs/pipelines/variables). +{{site.data.callout.end}} + +## Example 1: Push the chart to GCS based Helm Repository +The first example pushes the packaged chart into a public cloud storage service, like AWS S3, Azure Storage, or Google Cloud Storage. We chose Google Cloud Storage (GCS) for this example. +Our pipeline has three steps: + +{:start="1"} +1. download_index: download the Helm `index.yaml` file from GCS, or create one of it's not there. + +{:start="2"} +2. helm_package_merge: package the chart as described earlier, and also merge the new package into the downloaded `index.yaml` file, using the `helm repo index --merge` command. + +{:start="3"} +3. push_gcs: upload the updated `index.yaml` file and the newly created package to GCS. + + `YAML` +{% highlight yaml %} +{% raw %} +steps: + download_index: + image: appropriate/curl:latest + commands: + - 'curl https://storage.googleapis.com/$GOOGLE_BUCKET_NAME/index.yaml --output ./index.yaml --fail || :' + - '[ ! -f ./index.yaml ] && echo "apiVersion: v1">./index.yaml' + helm_package_merge: + image: devth/helm + commands: + - cf_export PACKAGE=$(helm package| cut -d " " -f 8) + - helm repo index --merge ./index.yaml . + push_gcs: + image: camil/gsutil + commands: + - echo -E $GOOGLE_CREDENTIALS > /gcs-creds.json + - echo -e "[Credentials]\ngs_service_key_file = /gcs-creds.json\n[GSUtil]\ndefault_project_id = $GOOGLE_PROJECT_ID" > /root/.boto + - gsutil cp ./index.yaml gs://$GOOGLE_BUCKET_NAME + - gsutil cp $PACKAGE gs://$GOOGLE_BUCKET_NAME +{% endraw %} +{% endhighlight %} + + +### Environment setup + +This pipeline references some predefined environment variables such as `GOOGLE_BUCKET_NAME`, `GOOGLE_PROJECT_ID` and `GOOGLE_CREDENTIALS`. +For this example, we created a service account with appropriate permissions in Google Cloud, and saved the credentials into `GOOGLE_CREDENTIALS` as a Codefresh Secret.
+For more information, see: +[Authenticating with Google services](https://cloud.google.com/storage/docs/authentication#service_accounts){:target="_blank"}.
+[Codefresh pipeline configuration and secrets](https://codefresh.io/docs/docs/codefresh-yaml/variables/#user-provided-variables){:target="_blank"}. + +## Example 2: Push the chart to Chart Museum +Chart Museum is a Helm repository *server* that has an HTTP API, pluggable backends, authentication, and more. +Read more about [Chart Museum](https://github.com/kubernetes-helm/chartmuseum){:target="_blank"}. + +In this example, we already have a Chart Museum server running, so we'll push the packaged chart to it. + +The steps will be: + +{:start="1"} +1. helm_package: package the chart as described earlier. + +{:start="2"} +2. get_repo_url: In order to avoid hard-coding the repository URL into the pipeline, we will retrieve it from the Codefresh Helm integration. +In this case, we have added our repository with Codefresh as described in [Using external Helml repos in Codefresh pipelines]({{site.baseurl}}/docs/deployments/helm/helm-charts-and-repositories). +Replace `` in the example with the name you gave to your repository when you added it to Codefresh. + +{:start="3"} +3. helm_push: call the Chart Museum HTTP api to just upload the package. Chart Museum will take care of the rest. + + `YAML` +{% highlight yaml %} +{% raw %} +steps: + helm_package: + image: devth/helm + commands: + - cf_export PACKAGE=$(helm package | cut -d " " -f 8) + get_repo_url: + image: codefresh/cli:latest + commands: + - cf_export HELM_URL=$(codefresh get ctx -o=yaml | grep repositoryUrl | cut -d "'" -f 2) + helm_push: + image: appropriate/curl + commands: + - curl --data-binary "@$PACKAGE" $HELM_URL/api/charts +{% endraw %} +{% endhighlight %} + + +## Related articles +[Using Helm in a Codefresh pipeline]({{site.baseurl}}/docs/deployments/helm/using-helm-in-codefresh-pipeline/) +[Using a managed Helm repository]({{site.baseurl}}/docs/deployments/helm/managed-helm-repository/) +[Helm environment promotion]({{site.baseurl}}/docs/deployments/helm/helm-environment-promotion) diff --git a/_docs/deployments/helm/helm-charts-and-repositories.md b/_docs/deployments/helm/helm-charts-and-repositories.md new file mode 100644 index 00000000..1fd079d3 --- /dev/null +++ b/_docs/deployments/helm/helm-charts-and-repositories.md @@ -0,0 +1,115 @@ +--- +title: "Using external Helml repos in Codefresh pipelines" +description: "Use external Helm Charts and repositories in Codefresh pipelines" +group: deployments +sub_group: helm +permalink: /:collection/deployments/helm/add-helm-repository/ +redirect_from: + - /docs/deployments/helm/ + - /docs/add-helm-repository/ +toc: true +--- +Codefresh allows you to integrate with external Helm repositories and Helm charts in the Helm Charts page. +It is optional to use external Helm repositories as all Codefresh accounts already include a [built-in Helm repository]({{site.baseurl}}/docs/deployments/helm/managed-helm-repository/). + +## Add an external Helm repository + +Easily add your own Helm charts. +By default, we show charts from the [official Helm repository](https://github.com/kubernetes/charts){:target="_blank"}. + +1. In the Codefresh UI, from the Artifacts section in the sidebar, select [**Helm Charts**](https://g.codefresh.io/helm/releases/releasesNew/){:target="\_blank"}. +1. On the top right, click **Add Existing Helm Repository**. + You are taken to Pipeline Integrations. +1. In the Integrations page, click **Add Helm Repository**, and then select the type of Helm repo to add from the list. +1. Enter the **Helm repository name** and **URL**. + Do not include the specific path to `index.yaml` in the URL. + +{% include image.html +lightbox="true" +file="/images/kubernetes-helm/quick-helm-integration.png" +url="/images/kubernetes-helm/quick-helm-integration.png" +alt="Adding a Helm repository" +caption="Adding a Helm repository" +max-width="70%" +%} + +1. If your repository doesn't require authentication, to complete the process, click **Save**. + +For more details on adding Helm repositories, see [Helm integrations]({{site.baseurl}}/docs/integrations/helm/). + +## Use a Helm repository in a Codefresh pipeline + +Once connected, inject any Helm repository context into Codefresh pipelines. + +1. From the Pipelines page, select the pipeline into which to import the Helm configuation. +1. In the Workflows tab, do one of the following: + * Click **Variables** on the right, and then click the **Settings** (gear) icon. + * Click the context menu next to the settings icon. +1. Click on **Import from/Add shared configuration**, and select the name of the repository. + The repository settings are injected as environment variables into the pipeline. + +{% include image.html +lightbox="true" +file="/images/kubernetes-helm/connect-helm-repo.png" +url="/images/kubernetes-helm/connect-helm-repo.png" +alt="Connecting a Helm repository in the pipeline" +caption="Connecting a Helm repository in the pipeline" +max-width="70%" +%} + +1. If you are using the Helm step, the step uses these settings to connect to your authenticated repository automatically. For details, see [Using Helm in Codefresh pipelines]({{site.baseurl}}/docs/deployments/helm/using-helm-in-codefresh-pipeline/). + +## Install a chart from your Helm repository +Install a chart from a Helm repository to your cluster. + +* Values in the Chart Install wizard are provided in the following order: + 1. Chart Default Values (implicitly part of the chart). + 2. Overridden default values (provided as values file, provided only if edited by the user). + 3. Supplied values files from Yaml Shared Configuration. + 4. Override variables are provided as `--set` arguments. +* Variables available for custom pipelines: + If you select a custom pipeline, the following variables are available: + * `CF_HELM_RELEASE` - name of release + * `CF_HELM_KUBE_CONTEXT` - kubectl context name of target cluster (cluster name from [dashboard]({{site.baseurl}}/docs/deploy-to-kubernetes/manage-kubernetes/#work-with-your-services)) + * `CF_HELM_INSTALLATION_NAMESPACE` - desired namespace for the release + * `CF_HELM_CHART_VERSION` - Chart Version, + * `CF_HELM_CHART_NAME` - Chart Name + * `CF_HELM_CONTEXTS` - values from [shared configuration]({{site.baseurl}}/docs/pipelines/shared-configuration/#using-shared-helm-values) + * `CF_HELM_VALUES` - extra values + * `CF_HELM_SET` - extra values, + * `CF_HELM_CHART_REPO_URL` - URL of Chart repository + * `CF_HELM_COMMIT_MESSAGE` - Message to show in Helm GUI, + +
+ +**Before you begin** +* Make sure tht you have a Kubernetes integration with the cluster and namespace, as described [here]({{site.baseurl}}/docs/deploy-to-kubernetes/add-kubernetes-cluster/) + +**How to** +1. In the Codefresh UI, from the Artifacts section in the sidebar, select [**Helm Charts**](https://g.codefresh.io/helm/releases/releasesNew/){:target="\_blank"}. +1. In the row with the chart to install, click **Install**. +1. Enter the **Release name** for the chart, and select the **Chart version** to install. +1. From Cluster Information, select a Kubernetes **Cluster** and the **Namespace** to install to. +1. Select the **Pipeline** to install to. +1. If required, edit the **Default Chart Values** to view and override them. + When the default values yaml is changed, it is provided to Helm install as a values file. You can revert to the original values cby clicking Revert. +1. To provide additional values files, do the following: + * From the **Import from configuration** list, select **Add new context of type: YAML**. + * Enter the **Context name**. + * Insert your values YAML, and click **Save**. + The YAML is saved and added to the list of configuration files that you can import from. +1. To override variable values, click **+Add variable**, and then enter the Key and Value. + > The order of value configurations matter for Helm: most recently provided values override earlier ones. +1. Click **Install**. You can observe the newly installed release in Helm Releases. + +You can also install Helm releases from [any Helm environment board]({{site.baseurl}}/docs/deployments/helm/helm-environment-promotion). + + +## Related articles +[Using Helm in a Codefresh pipeline]({{site.baseurl}}/docs/deployments/helm/using-helm-in-codefresh-pipeline/) +[Helm integrations]({{site.baseurl}}/docs/integrations/helm/) +[Helm Dashboard]({{site.baseurl}}/docs/deployments/helm/helm-releases-management) +[Helm Promotion boards]({{site.baseurl}}/docs/deployments/helm/helm-environment-promotion) +[Helm best practices]({{site.baseurl}}/docs/ci-cd-guides/helm-best-practices/) + + diff --git a/_docs/deployments/helm/helm-environment-promotion.md b/_docs/deployments/helm/helm-environment-promotion.md new file mode 100644 index 00000000..2b526b14 --- /dev/null +++ b/_docs/deployments/helm/helm-environment-promotion.md @@ -0,0 +1,289 @@ +--- +title: "Helm Environment Promotion" +description: "Manage your Helm Environments with the Codefresh UI" +group: deployments +sub_group: helm +toc: true +--- +Apart from the [Helm Releases]({{site.baseurl}}/docs/deployments/helm/helm-releases-management) that show your Kubernetes clusters at the application level, Codefresh also comes with a special environment board that allows you to track one or more applications as they move within your infrastructure (example, Dev, QA, Prod). + +The environment board can function both as an overview of the whole lifecycle of the application, as well as a tool to shift-left/right Helm releases between environments. + +Here is an example board: + +{% include +image.html +lightbox="true" +file="/images/kubernetes-helm/promotion/board.png" +url="/images/kubernetes-helm/promotion/board.png" +alt="Helm Environment Dashboard" +caption="Helm Environment Dashboard" +max-width="80%" +%} + +This board has three environments that correspond to Kubernetes clusters: + * A Load-testing environment where applications are stress-tested + * A Staging environment where smoke tests are performed + * The Production environment where applications go live + +You can see that a Python example app at version 0.2.0 is already in production. Version 0.3.0 is waiting in the staging environment for smoke tests. Once it is tested it can be dragged to the production column therefore *promoting* it to production status. + + +## Using the Helm Environment Board + +You can create and manage as many Helm promotion boards as you want. +For each board, you define how many columns it will contain, where each column is a Helm-enabled Kubernetes cluster. + +{% include +image.html +lightbox="true" +file="/images/kubernetes-helm/promotion/helm-environments.png" +url="/images/kubernetes-helm/promotion/helm-environments.png" +alt="Helm environments column structure" +caption="Helm environments column structure" +max-width="80%" +%} + +You can use different clusters for each column or different namespaces from the same cluster. You can even mix and match both approaches. +As an example, you could create a Helm board with the following environments: + +* Column 1, dev cluster showing all namespaces (DEV) +* Column 2, namespace qa from cluster staging (QA) +* Column 3, namespace staging from cluster staging (STAGING) +* Column 4, namespace production from cluster prod (PRODUCTION) + +Once you have your columns in place, you can move Helm releases between clusters/namespaces by drag-n-drop. Each Helm release can be dragged to any other column either promoting it, for example, from QA to Production, or shifting it left, for example, from Production to QA. + +## Creating a custom Helm Board + +Create your own Helm board with a single or multiple Helm applications. You can create as many boards as you want. + +1. In the Codefresh UI, from the DevOps Insights section in the sidebar, select [**Helm Boards**](https://g.codefresh.io/helm/helm-kanban/){:target="\_blank"}. + +{% include +image.html +lightbox="true" +file="/images/kubernetes-helm/promotion/board-selection.png" +url="/images/kubernetes-helm/promotion/board-selection.png" +alt="Helm board selection" +caption="Helm board selection" +max-width="80%" +%} + +{:start="2"} +1. On the top-right, click **Add board**. +1. Enter the title of your board as the **Board Name**. +1. Optional. In the **Release name regex expression** field, enter the Regex expression for this board to filter all its environments to show only Helm releases that match this regular expression. + Regex expressions are very helpful if you want your environment board to focus only on a single or set of Helm applications. + To see all Helm releases of your clusters, leave empty. + +You can edit both options for an existing board if you change your mind later. + +### Define Clusters/Namespaces for each Environment + +Once you create your Helm environment board, you are ready to define its columns. + +* To add a column, on the top-right, click **Add environment***. + You will see the environment details dialog: + +{% include +image.html +lightbox="true" +file="/images/kubernetes-helm/promotion/edit-helm-environment.png" +url="/images/kubernetes-helm/promotion/edit-helm-environment.png" +alt="Edit Helm environment" +caption="Edit Helm environment" +max-width="50%" +%} + + For each environment you can select: + * A name for that column + * The Kubernetes cluster it corresponds to + * One or more namespaces that define this environment (You can even toggle the switch for a regex match) + * A custom pipeline that will be used when a Helm release is installed for the first time in this column + * A custom pipeline that will be used when a Helm release is dragged in this column (promoted from another column) + * Optional. One or more charts to use for the environment. Defining charts for the environment saves you from having to search through all the charts in your Helm repository. When you install an application from the install graphical dialog, only the selected chart(s) are displayed. + * A presentation color to easily identify the environment on the board (For example, a "production" environment should have a red color) + +You can also select no namespace at all. In that case, the column will show Helm releases for all namespaces in that cluster. +You can change all these options after creation, so feel free to change your mind. + +Repeat the same process for additional environments. Remember that you can name your environment as you want and define any combination of cluster/namespace for any of the columns. This gives you a lot of power to define a Helm environment board that matches exactly your own process. + +You don't have to define the environments in order. You can drag-n-drop columns to change their order after the initial creation. + + +### Installing Helm Releases on each Environment + +If you already have [pipelines that deploy Helm releases]({{site.baseurl}}/docs/deployments/helm/using-helm-in-codefresh-pipeline/), your columns are populated automatically with information. + +For each Helm release, you will get some basic details such as the chart version and the name of the release. You can expand a release by clicking on the arrow button to get additional information such as the docker images and the replicas of each pod that are contained in the release. + +{% include +image.html +lightbox="true" +file="/images/kubernetes-helm/promotion/expand.png" +url="/images/kubernetes-helm/promotion/expand.png" +alt="Helm release details" +caption="Helm release details" +max-width="50%" +%} + +You can even install manually a Helm release from any external repository by clicking on the *PLUS* button at the header of each column. In that case you will see a list of possible Helm applications to choose from. + +You will be able to select the target cluster and namespace as well as the chart values [as any other Helm release]({{site.baseurl}}/docs/deployments/helm/helm-charts-and-repositories/#install-chart-from-your-helm-repository). + + +## Moving Releases between Environments + +A Helm environment board can be used by different stakeholders in order to get the detailed status of all defined environments. In that aspect it can act as a read-only tool that simply shows the results of Codefresh pipelines that deploy Helm applications. + +### Promoting Helm Releases with the UI + +You can also use the board as an action tool in order to promote/demote a Helm release between individual environments. To move a Helm release between environments just drag-n-drop it to a different column. + +{% include +image.html +lightbox="true" +file="/images/kubernetes-helm/promotion/shift-right.png" +url="/images/kubernetes-helm/promotion/shift-right.png" +alt="Promoting a Helm release" +caption="Promoting a Helm release" +max-width="80%" +%} + +Once you drop the release you will also see the promotion dialog. + +{% include +image.html +lightbox="true" +file="/images/kubernetes-helm/promotion/promote-settings.png" +url="/images/kubernetes-helm/promotion/promote-settings.png" +alt="Promotion Settings" +caption="Promotion Settings" +max-width="40%" +%} + +All fields here will be auto-filled according to the Helm release that you dragged. You can also choose a custom pipeline (see below) for the promotion if you don't want to use the default one. + +By clicking the *Variables* button you can override the chart values, import a specific shared configuration or add new values. + +{% include +image.html +lightbox="true" +file="/images/kubernetes-helm/promotion/value-options.png" +url="/images/kubernetes-helm/promotion/value-options.png" +alt="Changing deployment values" +caption="Changing deployment values" +max-width="40%" +%} + +By default Codefresh will use a built-in install/upgrade pipeline for performing the promotion. You can choose your own pipeline from the promotion dialog. That pipeline will be automatically provided with the following [environment variables]({{site.baseurl}}/docs/deployments/helm/helm-releases-management/#overriding-the-default-helm-actions): + +* `CF_HELM_RELEASE` - name of release +* `CF_HELM_KUBE_CONTEXT` - `kubectl` context name of target cluster (cluster name from [dashboard]({{site.baseurl}}/docs/deploy-to-kubernetes/manage-kubernetes/#work-with-your-services)) +* `CF_HELM_NAMESPACE` - Tiller Namespace if you use Helm 2 +* `CF_HELM_INSTALLATION_NAMESPACE` - namespace where release is promoted to +* `CF_HELM_CONTEXTS` - [shared configuration]({{site.baseurl}}/docs/configure-ci-cd-pipeline/shared-configuration) Helm contexts +* `CF_HELM_VALUES` - Helm chart values +* `CF_HELM_SET` - Additional values there were overriden +* `CF_HELM_CHART_JSON_GZIP` - Gzipped JSON of Helm chart (only for Helm 3) +* `CF_HELM_CHART_JSON` - JSON of Helm chart (only for Helm 2) +* `CF_HELM_BOARD` - Name of the board that is used for the drag-n-drop-action +* `CF_HELM_TARGET_SECTION` - Name of the Source Environment that you are promoting from +* `CF_HELM_SOURCE_SECTION` - Name of the Target Environment that you are promoting to + + +Note that the variable `CF_HELM_CHART_JSON_GZIP` is both compressed and base64 encoded. To get the raw value you need a command like `echo $CF_HELM_CHART_JSON_GZIP | base64 -d | gunzip` + +>Overriding the default pipeline can only be done by [Codefresh admin users]({{site.baseurl}}/docs/administration/access-control/#users-and-administrators). + +Once you click the *update* button, a new build will run that will perform the deployment. + +Note that you can move releases to any column both on the right and on the left of the current column. This is helpful if for example you find a bug in your production environment and you want to bring it back to a staging environment for debugging. + +### Promoting Helm releases programmatically + +You can also promote Helm releases with the [Codefresh CLI](https://codefresh-io.github.io/cli/predefined-pipelines/promote-helm-release/){:target="\_blank"}. + +Once you have [installed the CLI](https://codefresh-io.github.io/cli/getting-started/){:target="\_blank"}, you can use it from an external script or terminal with the `helm-promotion` parameter: + +{% highlight shell %} +{% raw %} +codefresh helm-promotion --board MySampleBoard --source Staging --target Production --source-release my-app --set myenv=prod +{% endraw %} +{% endhighlight %} + +Here we promote the Helm release `my-app` to the *Production* column overriding also the `myenv` value. + +Remember that the Codefresh CLI can also run in a Codefresh pipeline with a [freestyle step]({{site.baseurl}}/docs/pipelines/steps/freestyle/). +Here is an example of a Helm promotion from within a Codefresh pipeline. + + +`codefresh.yml` +{% highlight yaml %} +{% raw %} +version: '1.0' +steps: + triggerstep: + title: trigger + image: codefresh/cli + commands: + - 'codefresh helm-promotion --board MySampleBoard --source Staging --target Production --source-release my-app --namespace my-namespace --set myenv=prod' +{% endraw %} +{% endhighlight %} + +## Viewing the promotion pipeline + +When you promote a Helm Release for a Board, you can view the pipeline for that release. + +1. Click on Boards under the Helm section on the left-hand side +2. Select the board you want to view +3. Select the Builds tab on the top +4. Here, you can see the Promotion Pipelines / builds for promoting a Release + +## Editing your Helm Boards + +For any existing Helm board, you have the following options: + +{% include +image.html +lightbox="true" +file="/images/kubernetes-helm/promotion/board-management.png" +url="/images/kubernetes-helm/promotion/board-management.png" +alt="Editing a Helm environment" +caption="Editing a Helm environment" +max-width="80%" +%} + + +1. The refresh button will update the board with the current state of the clusters +1. The filtering menu can be used to further constrain the Helm releases shown in each column. +1. The *edit properties* button allows you to change again the title of the board as well as a global filter for Helm releases +1. The *remove board* completely deletes the present board from the Codefresh UI +1. The environment details on the environment header are: +* The edit button to change again the options for this column (shown on mouse hover) +* The delete button to remove this column from the board (shown on mouse hover) +* The plus button to install a new chart. If you selected one or more charts when you defined your environment, only the selected charts are displayed. +* A numeric value that shows how many releases are contained on this environment +1. The delete button allows you to uninstall a Helm release for an environment + +The filtering options allow you to further constrain the Helm release shown for the whole board. + +{% include +image.html +lightbox="true" +file="/images/kubernetes-helm/promotion/filter.png" +url="/images/kubernetes-helm/promotion/filter.png" +alt="Filtering options" +caption="Filtering options" +max-width="50%" +%} + +The filters are especially helpful in Helm boards with large numbers of environments and/or releases. + +## Related articles +[Using Helm in a Codefresh pipeline]({{site.baseurl}}/docs/deployments/helm/using-helm-in-codefresh-pipeline/) +[Using external Helml repos in Codefresh pipelines]({{site.baseurl}}/docs/deployments/helm/helm-charts-and-repositories/#add-helm-repository) +[Managing Helm releases]({{site.baseurl}}/docs/deployments/helm/helm-releases-management) +[Environment Dashboard]({{site.baseurl}}/docs/deploy-to-kubernetes/environment-dashboard/) diff --git a/_docs/deployments/helm/helm-releases-management.md b/_docs/deployments/helm/helm-releases-management.md new file mode 100644 index 00000000..aeffd4b6 --- /dev/null +++ b/_docs/deployments/helm/helm-releases-management.md @@ -0,0 +1,263 @@ +--- +title: "Managing Helm releases" +description: "Manage Helm deployments from the Codefresh UI" +group: deployments +sub_group: helm +redirect_from: + - /docs/helm-releases-management/ + - /docs/deployments/helm/helm3/ +toc: true +--- +Codefresh has built-in integration for Helm that provides a unique view into your production Kubernetes cluster. +In Helm Releases, you can see the current status of your cluster, including the currently deployed releases, their previous revisions including change tracking, and even roll back to a previous release. + +Codefresh also offers [an environment view for Helm releases]({{site.baseurl}}/docs/deploy-to-kubernetes/environment-dashboard/) as well as [a promotion dashboard]({{site.baseurl}}/docs/deployments/helm/helm-environment-promotion). + + +## View Helm releases and release information + +View all the Helm releases in your cluster, and drill down into a specific release to see its services, deployed versions, manifests and more. + +> Make sure you have [connected your Kubernetes cluster]({{site.baseurl}}/docs/integrations/kubernetes/adding-non-gke-kubernetes-cluster/) to Codefresh. + +1. In the Codefresh UI, from the DevOps Insights section in the sidebar, select [**Helm Releases**](https://g.codefresh.io/helm/releases/releasesNew/){:target="\_blank"}. + +{% include +image.html +lightbox="true" +file="/images/kubernetes-helm/dashboard/helm-release-dashboard.png" +url="/images/kubernetes-helm/dashboard/helm-release-dashboard.png" +alt="Helm Releases" +caption="Helm Releases" +max-width="90%" +%} + + + + +{:start="2"} +1. To see details for a specific release, click the release name. + +{% include +image.html +lightbox="true" +file="/images/kubernetes-helm/dashboard/services.png" +url="/images/kubernetes-helm/dashboard/services.png" +alt="Kubernetes Services" +caption="Kubernetes Services" +max-width="70%" +%} + +The History tab shows all previous releases. + +{% include +image.html +lightbox="true" +file="/images/kubernetes-helm/dashboard/history.png" +url="/images/kubernetes-helm/dashboard/history.png" +alt="Helm History" +caption="Helm History" +max-width="60%" +%} + +You can further expand a release revision to see exactly what files were changed in this release. + +{% include +image.html +lightbox="true" +file="/images/kubernetes-helm/dashboard/diff.png" +url="/images/kubernetes-helm/dashboard/diff.png" +alt="Helm diff" +caption="Helm diff" +max-width="60%" +%} + +There are other tabs that show you the chart used, the values as well as the final manifests that were actually deployed. + +{% include +image.html +lightbox="true" +file="/images/kubernetes-helm/dashboard/manifests.png" +url="/images/kubernetes-helm/dashboard/manifests.png" +alt="Final rendered manifests" +caption="Final rendered manifests" +max-width="50%" +%} + +## Add labels to Kubernetes services + +For better visibility into services, add the [recommended labels](https://helm.sh/docs/topics/chart_best_practices/labels/){:target="\_blank"} to your Kubernetes service. + +{% highlight yaml %} +{% raw %} + apiVersion: v1 +kind: Service +metadata: + name: {{ template "fullname" . }} + labels: + app.kubernetes.io/name: "{{ template "name" . }}" + helm.sh/chart: "{{ .Chart.Name }}-{{ .Chart.Version | replace "+" "_" }}" + app.kubernetes.io/managed-by: "{{ .Release.Service }}" + app.kubernetes.io/instance: "{{ .Release.Name }}" +{% endraw %} +{% endhighlight %} + +To use the instance label for something different, you can also use a release label instead: + +{% highlight yaml %} +{% raw %} +release: {{ .Release.Name }} +{% endraw %} +{% endhighlight %} + + + +## Add an upgrade message + +Codefresh allows you to display a meaningful description for each release in the release history. This message +can help show the main reason behind each release, or any other message that is convenient for you. + +{% include +image.html +lightbox="true" +file="/images/kubernetes-helm/dashboard/helm-commit-message.png" +url="/images/kubernetes-helm/dashboard/helm-commit-message.png" +alt="Helm release message" +caption="Helm release message" +max-width="70%" +%} + +You can set this message for your Helm release in three ways: + +1. When you manually install a Helm release from the [Helm charts screen]({{site.baseurl}}/docs/deployments/helm/helm-charts-and-repositories/#install-chart-from-your-helm-repository), there is a field for this message. +1. Set the property `commit_message` inside the [notes.txt](https://helm.sh/docs/chart_template_guide/notes_files/){:target="\_blank"} file of your chart. +1. By providing an environment variable called `COMMIT_MESSAGE` within your [pipeline Helm step]({{site.baseurl}}/docs/deployments/helm/using-helm-in-codefresh-pipeline/). + + +## Roll back a Helm release + +You can rollback to a previous revision of a release in the History tab. + +1. Click the Helm release for which to perform a rollback, and then click the **History** tab. +1. To rollback to a specific release, click **Rollback** in the row. + +{% include +image.html +lightbox="true" +file="/images/kubernetes-helm/dashboard/rollback.png" +url="/images/kubernetes-helm/dashboard/rollback.png" +alt="Rolling back to a previous release" +caption="Rolling back to a previous release" +max-width="50%" +%} + +>It takes time to complete rollback for a release, and the change in the cluster is not instantly updated in the Codefresh UI. If you also use a [custom rollback pipeline](#overriding-the-default-helm-actions), the delay between the cluster update and the UI refresh is even longer. + +## Helm UI actions + +From the main release screen, you have some additional actions. + +You can issue a [Helm test](https://github.com/kubernetes/helm/blob/master/docs/chart_tests.md) by clicking on the 'Run Test' button on the desired chart row. + +You can delete a release by clicking on the 'Delete' button on the desired chart row. +For deletion options, see the [helm delete documentation](https://github.com/kubernetes/helm/blob/master/docs/helm/helm_delete.md){:target="\_blank"}, for example, *purge* will remove the revision from the release history. + +## Helm deployment badge + +Similar to a [build badge]({{site.baseurl}}/docs/pipelines/build-status/#using-the-build-badge), you can also get a deployment badge for a Helm release. + +1. In the Codefresh UI, from the DevOps Insights section in the sidebar, select [**Helm Releases**](https://g.codefresh.io/helm/releases/releasesNew/){:target="\_blank"}. +1. In the row with the Helm release for which to add a deployment badge, click the **Settings** (gear) icon. + +{% include +image.html +lightbox="true" +file="/images/kubernetes-helm/dashboard/helm-badge.png" +url="/images/kubernetes-helm/dashboard/helm-badge.png" +alt="Helm Deployment badge" +caption="Helm Deployment badge" +max-width="60%" +%} + +{:start="3"} +1. To get deployment information, click **Badge**. + Codefresh provides the Markdown/HTML/Link segment that you can embed in README or other documents to show deployment information. + +## Overriding default Helm actions for releases + +By default, when you take an action in the UI, Codefresh executes the native Helm command corresponding to that action: + +* `helm test` for testing a chart +* `helm rollback` for rollbacks +* `helm delete` or `helm uninstall --keep-history` for delete +* `helm delete --purge ` or `helm uninstall ` for purging a release + +You can override these actions for a specific Helm release by defining custom pipelines for each action. This way you can add your extra logic on top of these actions. For example your own Helm uninstall pipeline might also have a notification step that posts a message to a Slack channel after a release is removed. + +>Only [Codefresh admin users]({{site.baseurl}}/docs/administration/access-control/#users-and-administrators) can override the default pipelines defined for a Helm release. + +1. In the Codefresh UI, from the DevOps Insights section in the sidebar, select [**Helm Releases**](https://g.codefresh.io/helm/releases/releasesNew/){:target="\_blank"}. +1. In the row with the Helm release for which to override default actions, click the **Settings** (gear) icon. + +{% include +image.html +lightbox="true" +file="/images/kubernetes-helm/dashboard/override-helm-actions.png" +url="/images/kubernetes-helm/dashboard/override-helm-actions.png" +alt="Changing default Helm actions" +caption="Changing default Helm actions" +max-width="50%" +%} + +{:start="3"} +1. Select the pipeline to use for the respective actions. + +### Environment variables for custom Helm commands +If you do override any of these actions, the following [environment variables]({{site.baseurl}}/docs/codefresh-yaml/variables/) are available in the respective pipeline, so that you can use your own custom Helm command. + +**Helm Test pipeline** +* `CF_HELM_RELEASE`: Name of release +* `CF_HELM_KUBE_CONTEXT`: `kubectl` context name of target cluster (cluster name from [dashboard]({{site.baseurl}}/docs/deployments/kubernetes/manage-kubernetes/#work-with-your-services)) +* `CF_HELM_NAMESPACE`: Namespace where release is stored +* `CF_HELM_TIMEOUT`: Time in seconds to wait for any individual Kubernetes operation +* `CF_HELM_CLEANUP`: Delete test pods upon completion + + + +**Helm Rollback pipeline** +* `CF_HELM_VERSION`: Helm version, ex.: 3.0.1, 2.7.0 +* `CF_HELM_RELEASE`: Name of release on cluster +* `CF_HELM_REVISION`: Revision to use for rollback +* `CF_HELM_KUBE_CONTEXT`: `kubectl` context name of target cluster (cluster name from [dashboard]({{site.baseurl}}/docs/deployments/kubernetes/manage-kubernetes/#work-with-your-services)) +* `CF_HELM_NAMESPACE`: Namespace where release is stored + + +**Helm Delete pipeline** +* `CF_HELM_PURGE`: Boolean, delete release from store +* `CF_HELM_RELEASE`: Name of release +* `CF_HELM_TIMEOUT`: Time in seconds to wait for any individual Kubernetes operation +* `CF_HELM_HOOKS`: Prevent hooks from running during install +* `CF_HELM_KUBE_CONTEXT`: `kubectl` context name of target cluster (cluster name from [dashboard]({{site.baseurl}}/docs/deployments/kubernetes/manage-kubernetes/#work-with-your-services)) +* `CF_HELM_VERSION`: Helm version, ex.: 3.0.1, 2.7.0 +* `CF_HELM_NAMESPACE`: Namespace where release is stored + + +## Related articles +[Using Helm in a Codefresh pipeline]({{site.baseurl}}/docs/deployments/helm/using-helm-in-codefresh-pipeline/) +[Helm charts and repositories]({{site.baseurl}}/docs/deployments/helm/helm-charts-and-repositories/) +[Codefresh-managed Helm Repositories]({{site.baseurl}}/docs/deployments/helm/managed-helm-repository/) +[Helm promotion boards]({{site.baseurl}}/docs/deployments/helm/helm-environment-promotion) \ No newline at end of file diff --git a/_docs/deployments/helm/managed-helm-repository.md b/_docs/deployments/helm/managed-helm-repository.md new file mode 100644 index 00000000..b06a0e5d --- /dev/null +++ b/_docs/deployments/helm/managed-helm-repository.md @@ -0,0 +1,137 @@ +--- +title: "Using a managed Helm repository" +description: "Use the Codefresh integrated Helm repository" +group: deployments +sub_group: helm +toc: true +--- + +Codefresh provides fully managed, hosted Helm repositories for users. +While we automatically create a default managed repo for every Codefresh account, you can also add [external Helm repositories]({{site.baseurl}}/docs/deployments/helm/helm-charts-and-repositories/). + +The built-in Helm repo that Codefresh creates, is private by default, allowing access only via Codefresh or via a Codefresh API token. + +> Tip: + You may be familiar with the popular open source Helm repository implementation called 'ChartMuseum', that Codefresh sponsors. Codefresh-managed repositories are based on, and therefore compatible with, ChartMuseum and its unique features. For details, see [ChartMuseum](https://github.com/kubernetes-helm/chartmuseum){:target="\_blank"}. + +## View Helm repository integrations + +The Codefresh-managed Helm repo is displayed with other Helm repositories you have added to Helm integrations. + +>You cannot delete the built-in Helm repo that Codefresh creates for you. + +1. In the Codefresh UI, on the toolbar, click the **Settings** icon, and then from the sidebar, select **Pipeline Integrations**. +1. Scroll to **Helm Repositories**, and then click **Configure**. + All the Helm integrations you set up are displayed. + +{% include +image.html +lightbox="true" +file="/images/kubernetes-helm/private-helm-repo/managed-helm-repo.png" +url="/images/kubernetes-helm/private-helm-repo/managed-helm-repo.png" +alt="Codefresh built-in Helm repository" +caption="Codefresh built-in Helm repository" +max-width="50%" +%} + + +## Get the chart repository URL +Get the chart repository URL for any Helm integration. +The URL is in the format: `cm://h.cfcr.io// `, where the default repo is `default`. + +* From the list of Helm integrations, select the integration and then click the **Edit** icon on the left. + The Helm Repository URL field displays the chart URL. + +## Codefresh Helm dashboards + +The Helm Charts and Helm Releases dashboards are automatically configured to work with your default managed repo to easily install charts and manage releases. +For more information, see [install chart from a Helm repository]({{site.baseurl}}/docs/deployments/helm/helm-charts-and-repositories/#install-chart-from-your-helm-repository) and [Managing Helm releases]({{site.baseurl}}/docs/deployments/helm/helm-releases-management/). + +## Use Codefresh CLI for advanced Helm repo management + +The Codefresh CLI supports advanced management options for your managed repository, without having to log in to the Codefresh UI. +For more information on CLI support for Helm repos, see the [CLI documentation on Helm Repos](https://codefresh-io.github.io/cli/helm-repos/){:target="\_blank"}. + + +## Set access level for managed repo + +The managed Helm repository supports two modes of access: +* Private +* Public + +By default, the managed Helm repo is created with `Private` access, meaning that read/write access is protected by Codefresh authentication. + +You can switch the access level to `Public`, which will make the repository accessible to anonymous users only *for read operations*. Write operations, even in public access mode, always require authentication. +Be very careful when you make your repo public, as the whole world will be able to access your charts. We recommend this setting only for quick demos and POCs. + +**How to** + +* Use the Codefresh CLI to toggle access level on a managed repo: + +{% highlight bash %} +codefresh patch helm-repo mycfrepo -public +{% endhighlight %} + +For more info, see the relevant section in the [Codefresh CLI documentation](https://codefresh-io.github.io/cli/helm-repos/update-helm-repo/){:target="\_blank"}. + +## Working with Helm CLI + +The private Helm repository offered by Codefresh is a standard Helm repo and will work with the vanilla Helm executable even outside of the Codefresh UI. +We suggest using the private [Helm repo from Codefresh pipelines]({{site.baseurl}}/docs/example-catalog/cd-examples/helm/), but you can also use it from your workstation. + +### Add a Public repo to Helm + +If your repo is set to `public` access mode, you can use it just like any other HTTP Helm repository. +You can: + +{% highlight bash %} +helm repo add mycfrepo https://h.cfcr.io/ / +{% endhighlight %} + +### Add a Private repo to Helm + +If your repo is set to `private` access mode, the default, then the Helm client needs to authenticate with Codefresh. +To authenticate, you can use ChartMuseum's 'Helm Push' CLI plugin which adds support for authentication and chart manipulation on top of the basic Helm CLI functionality. + +We highly recommend that you familiarize yourself with the [Helm Push plugin](https://github.com/chartmuseum/helm-push){:target="\_blank"}. + +#### Install the Helm Push plugin + +{% highlight bash %} +helm plugin install https://github.com/chartmuseum/helm-push +{% endhighlight %} + +#### Configure the Helm Push plugin + +If you have the Codefresh CLI installed and configured, there's nothing you need to do. The Helm Push plugin picks up your settings automatically. +To learn about getting started with Codefresh CLI, see [CLI getting started](https://codefresh-io.github.io/cli/getting-started/). +To learn about manual authentication without depending on the Codefresh CLI, see [here](https://github.com/chartmuseum/helm-push#token). + +#### Add the private repo + +{% highlight bash %} +helm repo add mycfrepo cm://h.cfcr.io/kostis-codefresh/default +{% endhighlight %} + +Notice the protocol is `cm://` instead of `https://`. This indicates the custom authentication scheme supported by ChartMuseum Helm Push plugin. + +## Using in a Codefresh pipeline + +The Codefresh Helm plugin automatically handles authentication for managed repositories. You can use the plugin as you usually would. For more information, see the [Codefresh Helm plugin]({{site.baseurl}}/docs/deployments/helm/using-helm-in-codefresh-pipeline/). + +## Removing a Helm chart from a private Codefresh repository + +You can delete a Helm chart from your own Helm repository with the following HTTP call. + +{% highlight bash %} +curl -X DELETE -v -H "Authorization: Bearer " https://h.cfcr.io/api/ / /charts/ / +{% endhighlight %} + +Replace values in `<>` with your own (also removing `<>` in the process). + +Generate an api key from [https://g.codefresh.io/user/settings](https://g.codefresh.io/user/settings) as explained in the [API page]({{site.baseurl}}/docs/integrations/codefresh-api/). + +## Related articles +[Using Helm in a Codefresh pipeline]({{site.baseurl}}/docs/deployments/helm/using-helm-in-codefresh-pipeline/) +[Helm integration]({{site.baseurl}}/docs/integrations/helm/) +[Managing Helm releases]({{site.baseurl}}/docs/deployments/helm/helm-releases-management) diff --git a/_docs/deployments/helm/using-helm-in-codefresh-pipeline.md b/_docs/deployments/helm/using-helm-in-codefresh-pipeline.md new file mode 100644 index 00000000..6e3a66a6 --- /dev/null +++ b/_docs/deployments/helm/using-helm-in-codefresh-pipeline.md @@ -0,0 +1,346 @@ +--- +title: "Using Helm in a Codefresh pipeline" +description: "Deploy and push Helm charts with Codefresh" +group: deployments +sub_group: helm +redirect_from: + - /docs/deployments/helm/create-helm-artifacts-using-codefresh-pipeline/ + - /docs/install-helm-chart-using-codefresh-pipeline/ +toc: true +--- + +We created a [special Helm step](https://codefresh.io/steps/step/helm){:target="\_blank"} for easy integration of Helm in Codefresh pipelines. The Helm step facilitates authentication, configuration, and execution of Helm commands. + +> If you have a special use case that is not covered by the Codefresh Helm step, you can always use the regular `helm` cli in a freestyle step. + In this case, you can use the simpler container `codefresh/kube-helm` which includes only Kubectl and helm tools. `kube-helm` is available on DockerHub: [https://hub.docker.com/r/codefresh/kube-helm/](https://hub.docker.com/r/codefresh/kube-helm/){:target="\_blank"}. + +If you are just starting with Helm, refer to our [Helm quick start guide]({{site.baseurl}}/docs/getting-started/helm-quick-start-guide/). And, if you prefer to work directly with code, see our [full Helm example]({{site.baseurl}}/docs/example-catalog/cd-examples/helm/). + +## Helm setup + + + +To use Helm in your Codefresh pipeline you must do the following: + +1. Make sure that your application has a [Helm chart](https://helm.sh/docs/chart_template_guide/getting_started/) +1. Create a Helm package for your application from the chart +1. [Add a Kubernetes cluster]({{site.baseurl}}/docs/deploy-to-kubernetes/add-kubernetes-cluster/) in Codefresh +1. Define a Helm repository or use the [one offered by Codefresh to all accounts]({{site.baseurl}}/docs/deployments/helm/managed-helm-repository/) +1. Import the Helm [configuration]({{site.baseurl}}/docs/pipelines/shared-configuration/) into your pipeline variables +1. Use the Helm step in your [yml build definition]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/) + +Let's see these steps in order. + +### Step 1: Create a Helm chart for your application + +Helm applications are bundled in special archives called *Charts*. You can create a Helm +chart for your application by following [the official documentation on charts](https://helm.sh/docs/chart_template_guide/getting_started/){:target="\_blank"}. + +The example Codefresh application includes a [sample chart](https://github.com/codefresh-contrib/python-flask-sample-app/tree/with-helm/charts/python){:target="\_blank"}, used in our Helm quick start guide, mentioned earlier in this article. + +You can create the chart manually or by using the [helm create](https://helm.sh/docs/helm/#helm-create){:target="\_blank"} command on your workstation. There are also several third-party tools that can create Helm packages for you such as [Draft](https://draft.sh/){:target="\_blank"}. + +Once your Helm chart is ready, commit it to a folder called `charts`, in the same Git repository that contains the source code of your application. Codefresh can also work with Helm charts that are in different Git repositories. We suggest however that you keep both the source code and the Helm chart of an application in the same Git repository to make chart management much easier. + + +### Step 2: Select Kubernetes cluster for deployment + +The Helm pipeline step requires the configuration of a `kube_context` variable that determines the Kubernetes cluster used for the deployment. + +1. Connect your Kubernetes cluster with Codefresh, as described [here]({{site.baseurl}}/docs/deploy-to-kubernetes/add-kubernetes-cluster/). + +1. Provide the cluster to the Helm step by adding the `KUBE_CONTEXT` variable, where the value is the connection *name* entered when you created the connection. +> The connection name also appears as the title of the cluster in Kubernetes integration settings (Account Settings >Integrations > Kubernetes). + +{% include image.html +lightbox="true" +file="/images/kubernetes-helm/k8s-name.png" +url="/images/kubernetes-helm/k8s-name.png" +alt="Name of Kubernetes cluster" +caption="Name of Kubernetes cluster" +max-width="70%" +%} + +1. Verify that your cluster is set up for Helm, from the sidebar, below DevOps Insights, select **Helm Releases**. + The [Helm releases]({{site.baseurl}}/docs/deployments/helm/helm-releases-management/) in your cluster are displayed. If you have just started using Helm, the release page may be empty. + +### Step 3: Define a Helm repository + +To push your chart to a Helm repository, configure the target repository to work with. +Always a good practice to save Helm charts in Helm repositories, Codefresh supports a variety of private, authenticated Helm repositories +in addition to public HTTP repositories. Codefresh also provides a free, managed Helm repository for every account. + +* Either [connect your repository with Codefresh]({{site.baseurl}}/docs/deployments/helm/add-helm-repository/) +OR +* Obtain your [managed Helm repository URL]({{site.baseurl}}/docs/deployments/helm/managed-helm-repository/#chart-repository-url) + + +### Step 4: (Optional) Import the Helm configuration into your pipeline definition + +Once you have a connected to a Helm repository, attach it to the pipeline. + +1. Frpm the Pipelines page, select the pipeline into which to import the Helm configuation. +1. In the Workflows tab, do one of the following: + * Click **Variables** on the right, and then click the Settings (gear) icon in the variables section on the right. + * Click the context menu next to the settings icon. +1. Click on **Import from/Add shared configuration**, and from the list, select `CF_HELM_DEFAULT`. See [shared configuration]({{site.baseurl}}/docs/pipelines/shared-configuration/). + +{% include image.html +lightbox="true" +file="/images/kubernetes-helm/import-helm-configuration.png" +url="/images/kubernetes-helm/import-helm-configuration.png" +alt="Connecting a Helm repository in the pipeline" +caption="Connecting a Helm repository in the pipeline" +max-width="50%" +%} + + +### Step 5: Use the Helm freestyle step in the pipeline + +You can now use the Helm freestyle step in the `codefresh.yml` file. This step is only needed in pipelines that actually upload/fetch Helm charts to/from Helm repositories. If your pipeline directly installs a Helm chart from the Git filesystem, there is no need to import a Helm configuration. + +>Currently, you can use only one Helm configuration in the same pipeline. We are aware +of this limitation and will soon improve the way Codefresh works with multiple Helm configurations. + + + +* Use the Helm typed step from the [Step Marketplace](https://codefresh.io/steps/step/helm){:target="\_blank"}. +* Configure the Helm step using environment variables, as described [here]({{site.baseurl}}/docs/codefresh-yaml/variables/#user-provided-variables). + +The example below illustrates how to provide variables as part of the Helm step definition: + +```yaml +deploy: + type: helm + arguments: + action: install + chart_name: test_chart + release_name: first + helm_version: 3.0.3 + kube_context: my-kubernetes-context + custom_values: + - 'pat.arr="{one,two,three}"' + - 'STR_WITH_COMAS="one\,two\,three"' +``` + + + +#### Helm step action modes + +The Helm step can operate in one of three modes, as defined by the `action` field: + +1. `install`: Installs the chart into a Kubernetes cluster. This is the default mode if not explicitly set. +2. `push`: Packages the chart and pushes it to the repository. +3. `auth`: Authenticate only. Only sets up authentication and adds the repo to the Helm. This mode is useful to write your own Helm commands using the freestyle step's `commands` property, but still allow the step to handle authentication. + + +#### Helm values + +* To supply a value file, add to the Helm step, `custom_values_file`, with the value pointing to an existing values file. +* To override specific values, add to the Helm step, `custom_values` followed by the path to the value to set. For example, `myservice_imageTag`. Note that `.` (dot) should be replaced with `_` (underscore). The value of the variable is used to override or set the templated property. + +Examples: +```yaml +... + custom_values: + - 'myimage_pullPolicy=Always' +... +``` +results in: +`--set myimage.pullPolicy=Always` + +```yaml +... + custom_value_files: + - 'values-prod.yaml' +... +``` +results in: +`--values values-prod.yaml` + +If a variable already contains a `_` (underscore) in its name, replace it with `__` (double underscore). + +## Helm usage examples + +The following sections illustrate all three modes of Helm usage. + +You can also look at the [GitHub repository](https://github.com/codefresh-contrib/helm-sample-app){:target="\_blank"} of [our Helm example]({{site.baseurl}}/docs/example-catalog/cd-examples/helm/) for full pipelines: + +* Pipeline YAML for [deploying a chart](https://github.com/codefresh-contrib/helm-sample-app/blob/master/codefresh-do-not-store.yml){:target="\_blank"} +* Pipeline YAML for [both storing and deploying a chart](https://github.com/codefresh-contrib/helm-sample-app/blob/master/codefresh.yml){:target="\_blank"} + +### Helm usage example: Installing a Helm Chart + +The following example includes the minimum configuration to install a Helm chart from a repository. For more configuration options, see the [Arguments reference](https://codefresh.io/steps/step/helm){:target="\_blank"}. + +```yaml +deploy: + type: helm + arguments: + action: install + chart_name: path/to/charts + release_name: first + helm_version: 3.0.3 + kube_context: my-kubernetes-context +``` + +### Helm usage example: Pushing a Helm Chart + +The following example illustrates how to package and push a Helm chart into a repository. + +```yaml +deploy: + type: helm + arguments: + action: push + chart_name: /codefresh/volume/repo/chart + chart_repo_url: 'cm://h.cfcr.io/useraccount/default' +``` + +> **Notes**: + - Assumes that a Git repository with the Helm chart files was cloned as a part of the pipeline. + - The Git repository contains the chart files in the `chart` directory. + - `chart_repo_url` is optional. If a [Helm repository configuration](#step-4-optional-import-the-helm-configuration-in-your-pipeline-definition) is attached to the pipeline, this setting is ignored. + +### Helm usage example: Authenticating only + +The following example illustrates the Helm mode for authentication only. + +```yaml +deploy: + type: helm + arguments: + action: auth + kube_context: my-kubernetes-context + commands: + - helm list +``` + +### Helm usage example: Custom Helm commands + +The following example illustrates executing custom Helm commands. + +`codefresh.yml` +{% highlight yaml %} +{% raw %} +my_custom_helm_command: + type: helm + arguments: + action: auth + kube_context: my-kubernetes-context + commands: + - source /opt/bin/release_chart + - helm repo add incubator https://kubernetes-charts-incubator.storage.googleapis.com/ + - helm repo add stable https://kubernetes-charts.storage.googleapis.com + - helm repo list + - helm repo update + - helm list +{% endraw %} +{% endhighlight %} + +> Notes: +- The directory that contains a chart MUST have the same name as the chart. Thus, a chart named `my-chart` MUST be created in a directory called `my-chart/`. This is a requirement of the [Helm Chart format](https://helm.sh/docs/chart_template_guide/). + +## Helm configuration fields + +Name|Required|Description +---|---|--- +action|Defaults to 'install'|Operation mode: `install`/`push`/`auth` +chart_name|required for install/push|Chart reference to use, adhering to Helm's lookup rules (path to chart folder, or name of packaged chart). There's no need to prefix with `/reponame` if referencing a chart in a repository, this is handled automatically. a.k.a `CHART_NAME` but `CHART_NAME` shouldn't be used anymore. +chart_repo_url|optional|Helm chart repository URL. If a [Helm repository configuration](#step-4-optional---import-the-helm-configuration-in-your-pipeline-definition) is attached to the pipeline, this setting is ignored. +chart_version|optional|Override or set the chart version. +cmd_ps|optional|When defined, Command Postscript is appended as is to the generated Helm command string. Can be used to set additional parameters supported by the command but not exposed as configuration options.| +commands|optional|Commands to execute in plugin after `auth` action. +custom_value_files|optional|Values file to provide to Helm as `--values` or `-f`.| +custom_values|optional|Values to provide to Helm as `--set` +helm_version|optional|Version of [cfstep-helm image](https://hub.docker.com/r/codefresh/cfstep-helm/tags){:target="\_blank"} +kube_context|required for install|Kubernetes context to use. The name of the cluster as [configured in Codefresh]({{site.baseurl}}/docs/deploy-to-kubernetes/add-kubernetes-cluster/). +namespace|optional|Target Kubernetes namespace to deploy to. +release_name|required for install|Helm release name. If the release exists, it is upgraded. +repos|optional|Array of custom repositories. + + +## Full Helm pipeline example + +The pipeline in this example builds a docker image, runs unit tests, stores the Helm chart in the Codefresh private Helm repository and finally deploys the Helm chart to a cluster. + +{% include image.html +lightbox="true" +file="/images/kubernetes-helm/full-helm-pipeline.png" +url="/images/kubernetes-helm/full-helm-pipeline.png" +alt="Helm pipeline" +caption="Helm pipeline" +max-width="90%" +%} + +This is the pipeline definition: + +`codefresh.yml` +{% highlight yaml %} +{% raw %} +version: '1.0' +stages: + - checkout + - build + - test +steps: + clone: + title: Cloning main repository... + stage: checkout + type: git-clone + arguments: + repo: 'codefresh-contrib/python-flask-sample-app' + revision: with-helm + git: github + MyAppDockerImage: + title: Building Docker Image + stage: build + type: build + working_directory: '${{clone}}' + arguments: + image_name: kostis-codefresh/python-flask-sample-app + tag: 'master' + dockerfile: Dockerfile + MyUnitTests: + title: Running Unit tests + stage: test + type: freestyle + working_directory: '${{clone}}' + arguments: + image: ${{MyAppDockerImage}} + commands: + - python setup.py test + StoreChart: + title: Storing Helm Chart + type: helm + stage: store + working_directory: ./python-flask-sample-app + arguments: + action: push + chart_name: charts/python + kube_context: kostis-demo@FirstKubernetes + DeployMyChart: + type: helm + stage: deploy + working_directory: ./python-flask-sample-app + arguments: + action: install + chart_name: charts/python + release_name: my-python-chart + helm_version: 3.0.2 + kube_context: kostis-demo@FirstKubernetes + custom_values: + - 'buildID=${{CF_BUILD_ID}}' + - 'image_pullPolicy=Always' + - 'image_tag=master' + - 'image_pullSecret=codefresh-generated-r.cfcr.io-cfcr-default' +{% endraw %} +{% endhighlight %} + +You can see the source code in our [example section]({{site.baseurl}}/docs/example-catalog/cd-examples/helm/). + + +## Related articles +[Helm Charts and repositories]({{site.baseurl}}/docs/deployments/helm/add-helm-repository/) +[Using managed Helm repositories]({{site.baseurl}}/docs/deployments/helm/managed-helm-repository/) +[Helm Promotion boards]({{site.baseurl}}/docs/deployments/helm/helm-environment-promotion) diff --git a/_docs/deployments/kubernetes/custom-kubectl-commands.md b/_docs/deployments/kubernetes/custom-kubectl-commands.md new file mode 100644 index 00000000..7c22b13b --- /dev/null +++ b/_docs/deployments/kubernetes/custom-kubectl-commands.md @@ -0,0 +1,184 @@ +--- +title: "Running custom kubectl commands" +description: "Use kubectl in your Codefresh pipelines" +group: deployments +sub_group: kubernetes +toc: true +--- + +As explained in [Kubernetes deployment options]({{site.baseurl}}/docs/deployments/kubernetes/deployment-options-to-kubernetes/), Codefresh has built-in functionality for deploying to Kubernetes clusters. + +For maximum flexibility with cluster deployments, you can run your own custom `kubectl` commands in a [freestyle step]({{site.baseurl}}/docs/pipelines/steps/freestyle/). +[Kubectl](https://kubernetes.io/docs/reference/kubectl/overview/){:target="\_blank"} is the command line interface for managing kubernetes clusters. + +Codefresh automatically sets up your [config context](https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/){:target="\_blank"} with your connected clusters. + +The config context is automatically placed for you at the path of the [variable]({{site.baseurl}}/docs/pipelines/variables/) `$CF_KUBECONFIG_PATH`. +In the current Codefresh implementation, this expands to `/codefresh/volume/sensitive/.kube/config`, within the [shared step volume]({{site.baseurl}}/docs/pipelines/introduction-to-codefresh-pipelines/#sharing-the-workspace-between-build-steps). + +When you use custom `kubectl` commands, it is your responsibility to template your manifests using any of the available options. To employ Codefresh for templating, it is better to use the dedicated [cf-deploy-kubernetes step]({{site.baseurl}}/docs/deployments/ci-cd-guides/kubernetes-templating/), which provides simple templating capabilities. + +## Using the Codefresh kubectl image + +Codefresh already offers a public Docker image with `kubectl` at [https://hub.docker.com/r/codefresh/kubectl/tags](https://hub.docker.com/r/codefresh/kubectl/tags){:target="\_blank"}. You can choose a specific version of `kubectl` with the appropriate tag or just select `latest` for the most up-to-date version. + +`YAML` +{% highlight yaml %} +{% raw %} +version: '1.0' +steps: + MyCustomKubectlCommands: + title: Running Kubectl + image: codefresh/kubectl:1.13.3 + commands: + - echo $CF_KUBECONFIG_PATH + - kubectl help +{% endraw %} +{% endhighlight %} + +If you run the pipeline, you can see the help options for `kubectl`. + +## Getting a config context + +The important thing to know when running custom `kubectl` commands is that Codefresh automatically sets up +your [kubeconfig files](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/){:target="\_blank"} for you with the cluster information present in [integrations]({{site.baseurl}}/docs/integrations/kubernetes/#connect-a-kubernetes-cluster). + +{% include image.html +lightbox="true" +file="/images/kubernetes/custom-kubectl/kube-context.png" +url="/images/kubernetes/custom-kubectl/kube-context.png" +alt="Codefresh cluster names" +caption="Codefresh cluster names" +max-width="50%" +%} + +If you run this pipeline, you will see the names of all your connected clusters: + +`YAML` +{% highlight yaml %} +{% raw %} +version: '1.0' +steps: + MyCustomKubectlCommands: + title: Running Kubectl + image: codefresh/kubectl + commands: + - kubectl config get-contexts +{% endraw %} +{% endhighlight %} + +With two sample clusters, the output of this pipeline is the following: + +``` +Running freestyle step: Running Kubectl +Pulling image codefresh/kubectl:latest +Status: Image is up to date for codefresh/kubectl:latest +NAME CLUSTER AUTHINFO NAMESPACE +gke-kostisdemo-codefresh-kostis gke-kostisdemo-codefresh-kostis gke-kostisdemo-codefresh-kostis default +kostis-demo@FirstKubernetes kostis-demo@FirstKubernetes kostis-demo@FirstKubernetes default + +``` + +You can modify the current config context and run any `kubectl` command you want applied to that context. The next pipeline will print all the nodes of the first cluster: + +`YAML` +{% highlight yaml %} +{% raw %} +version: '1.0' +steps: + MyCustomKubectlCommands: + title: Running Kubectl + image: codefresh/kubectl + commands: + - kubectl config get-contexts + - kubectl config use-context "gke-kostisdemo-codefresh-kostis" + - kubectl get nodes +{% endraw %} +{% endhighlight %} + +## Example of parallel deployment with kubectl + +Let's see a full example. In this pipeline, we will create two Docker images and deploy them on two separate clusters, using custom `kubectl` commands. We will also use the [parallel capability]({{site.baseurl}}/docs/pipelines/advanced-workflows/) of Codefresh pipelines. + +Here is the pipeline: + +{% include image.html +lightbox="true" +file="/images/kubernetes/custom-kubectl/parallel-kubectl.png" +url="/images/kubernetes/custom-kubectl/parallel-kubectl.png" +alt="Parallel kubectl deployment" +caption="Parallel kubectl deployment" +max-width="100%" +%} + +And here is the complete `codefresh.yml`: + +`YAML` +{% highlight yaml %} +{% raw %} +version: '1.0' + +stages: +- build +- deploy + +steps: + BuildingApps: + type: parallel + stage: 'build' + steps: + BuildingApp1: + title: Building App 1 + type: build + stage: build + image_name: nestjs-app + working_directory: ./my-nestjs-project/ + dockerfile: Dockerfile + BuildingApp2: + title: Building App 2 + type: build + stage: build + image_name: rails + working_directory: ./my-rails-project/ + dockerfile: Dockerfile + DeployingApps: + type: parallel + stage: 'deploy' + steps: + DeployApp1: + title: Deploying App 1 + stage: deploy + image: codefresh/kubectl + working_directory: ./my-nestjs-project/ + commands: + - kubectl config get-contexts + - kubectl config use-context "gke-kostisdemo-codefresh-kostis" + - kubectl apply -f service.yml deployment.yml + DeployApp2: + title: Deploying App 2 + stage: deploy + image: codefresh/kubectl + working_directory: ./my-rails-project/ + commands: + - kubectl config get-contexts + - kubectl config use-context "kostis-demo@FirstKubernetes" + - kubectl apply -f service.yml deployment.yml configmap.yml +{% endraw %} +{% endhighlight %} + +In the example above, we select one of the clusters in each deployment step, and then apply several Kubernetes manifests that constitute an application. + +## Related articles +[Managing your cluster]({{site.baseurl}}/docs/deployments/kubernetes/manage-kubernetes/) +[Accessing a Docker registry]({{site.baseurl}}/docs/ci-cd-guides/access-docker-registry-from-kubernetes/) + + + + + + + + + + + \ No newline at end of file diff --git a/_docs/deployments/kubernetes/deployment-options-to-kubernetes.md b/_docs/deployments/kubernetes/deployment-options-to-kubernetes.md new file mode 100644 index 00000000..c79d25a4 --- /dev/null +++ b/_docs/deployments/kubernetes/deployment-options-to-kubernetes.md @@ -0,0 +1,140 @@ +--- +title: "Deployment options for Kubernetes" +description: "Deploy to Kubernetes with the declarative deploy step" +group: deployments +sub_group: kubernetes +redirect_from: + - /docs/deploy-to-kubernetes/ + - /docs/deployment-to-kubernetes-quick-start-guide/ + - /docs/deploy-to-kubernetes/deployment-to-kubernetes-quick-start-guide/ + - /docs/deploy-to-kubernetes/get-ready-to-deploy/ +toc: true +--- + +Codefresh offers several options when it comes to Kubernetes deployments: + +1. Codefresh UI for on demand deployments + This is the easiest deployment option for Kubernetes. See our [Kubernetes quick start guide]({{site.baseurl}}/docs/getting-started/deployment-to-kubernetes-quick-start-guide/). +1. Through a dedicated [deploy step]({{site.baseurl}}/docs/pipelines/steps/deploy/) in a pipeline + Described in this article. +1. Through the [cf-deploy-kubernetes step]({{site.baseurl}}/docs/ci-cd-guides/kubernetes-templating/) in a pipeline + Use this to also perform simple templating on Kubernetes manifests. +1. Through a [freestyle]({{site.baseurl}}/docs/pipelines/steps/freestyle/) step with [Kustomize](https://kustomize.io){:target="\_blank"}. + See [Deployment with Kustomize]({{site.baseurl}}/docs/example-catalog/cd-examples/deploy-with-kustomize). +1. Using a [freestyle]({{site.baseurl}}/docs/codefresh-yaml/steps/freestyle/) step with your own `kubectl` commands + This deployment option gives you great flexibility, but assumes that you know how to work with `kubectl`. See [Custom kubectl commands]({{site.baseurl}}/docs/deployments/kubernetes/custom-kubectl-commands/). +1. Using Helm as a package manager + See our [Helm quick start guide]({{site.baseurl}}/docs/getting-started/helm-quick-start-guide/). + +## Prerequisites + +* A K8s cluster in Codefresh (see [Connecting a Kubernetes cluster]({{site.baseurl}}/docs/integrations/kubernetes/#connect-a-kubernetes-cluster/) +* Familiarity with the [Codefresh YAML]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/), basic [pipeline steps ]({{site.baseurl}}/docs/pipelines/steps/), and how to describe them +* [Integrate your Docker registry]({{site.baseurl}}/docs/integrations/docker-registries/) with Codefresh + +## Build and push your image +Here is a basic Codefresh pipeline scenario to build and push your image to Dockerhub registry. + + `YAML` +{% highlight yaml %} +{% raw %} +version: '1.0' +steps: + BuildImage: + type: build + image_name: ' / ' #specify your future image reference here + dockerfile: Dockerfile + tag: '${{CF_BRANCH_TAG_NORMALIZED}}' + + PushToDockerRegistry: + type: push + candidate: '${{BuildImage}}' + tag: '${{CF_BRANCH_TAG_NORMALIZED}}' + registry: 'dockerhub' #the name of the registry you added to Codefresh +{% endraw %} +{% endhighlight %} + +Using this YAML example, we'll add an additional step to deploy the image in Dockerhub to Kubernetes. + +## Describe your deployment +The following instructions describe how to create a new service in your Kubernetes cluster in order to deploy to it. +>If you're deploying to an existing service in your Kubernetes cluster, please skip to the [next step]({{site.baseurl}}/docs/getting-started/deployment-to-kubernetes-quick-start-guide/#add-a-deployment-step). + + + 1. Go to the **`Kubernetes` → `Services page`**. + 1. Click the button **“Add Service”**. + 1. Select the **cluster**. + 1. Select the **namespace**. + 1. Type an arbitrary **service name**. + 1. Specify the **number of replicas**. + 1. Type the name of your **pushed image**. + 1. In the **“Internal Ports”** field specify the port which your application listens to. + 1. In the **“Expose port”** field specify the port to be exposed to the Internet and check the checkbox. + 1. Click the button **“Deploy”** to deploy the application. + +Wait until the deployment is completed, and you can open the deployed application in your browser by clicking on the "endpoint" link. + +{% include image.html +lightbox="true" +file="/images/3f36367-Screenshot_from_2018-02-16_17-09-54.png" +url="/images/3f36367-Screenshot_from_2018-02-16_17-09-54.png" +alt="Screenshot from 2018-02-16 17-09-54.png" +max-width="60%" +%} + +## Add a Deployment step +So now you have deployed your image manually, which is great. But how to trigger the deployment within your pipeline? For that you will need to add a step of a “Deploy” type to the Codefresh YAML manifest file: + + `YAML` +{% highlight yaml %} +{% raw %} +RunningDeployScript: + title: Running Deploy Script + type: deploy + kind: kubernetes + cluster: ' ' #the name specified when you added the cluster + namespace: #the namespace you wish to deploy into + service: #the service you would like to update the deployment in + candidate: + image: '${{BuildImage}}' + registry: 'dockerhub' +{% endraw %} +{% endhighlight %} + +The full Codefresh YAML looks like this: + + `YAML` +{% highlight yaml %} +{% raw %} +version: '1.0' +steps: + BuildImage: + type: build + image_name: ' / ' + dockerfile: Dockerfile + tag: '${{CF_BRANCH_TAG_NORMALIZED}}' + + PushToDockerRegistry: + type: push + candidate: '${{BuildImage}}' + tag: '${{CF_BRANCH_TAG_NORMALIZED}}' + registry: 'dockerhub' #the name of the registry you added to Codefresh + + RunningDeployScript: + title: Running Deploy Script + type: deploy + kind: kubernetes + cluster: ' ' #the name specified when you added the cluster + namespace: #the namespace you wish to deploy into + service: #the service you would like to update the deployment in + candidate: + image: '${{BuildImage}}' + registry: 'dockerhub' +{% endraw %} +{% endhighlight %} + +You can now run the whole pipeline that builds your application from source to a docker image, pushes it to a docker registry and deploys it to your Kubernetes cluster. + +## Related articles +[Manage your Kubernetes cluster]({{site.baseurl}}/docs/deployments/kubernetes/manage-kubernetes/) +[Environment dashboard]({{site.baseurl}}/docs/deployments/kubernetes/environment-dashboard/) diff --git a/_docs/deployments/kubernetes/manage-kubernetes.md b/_docs/deployments/kubernetes/manage-kubernetes.md new file mode 100644 index 00000000..6990c6d0 --- /dev/null +++ b/_docs/deployments/kubernetes/manage-kubernetes.md @@ -0,0 +1,169 @@ +--- +title: "Manage your Kubernetes cluster" +description: "Use the graphical Kubernetes dashboard in Codefresh" +group: deployments +sub_group: kubernetes +redirect_from: + - /docs/deploy-to-kubernetes/codefresh-kubernetes-integration-beta/ + - /docs/codefresh-kubernetes-integration-beta/ +toc: true +--- + +Codefresh includes a built-in Kubernetes Dashboard that allows you to see the state of your clusters, and even make changes if you have the appropriate access privileges. + +## Accessing the Kubernetes Dashboard + +After [adding a cluster]({{site.baseurl}}/docs/integrations/kubernetes/#connect-a-kubernetes-cluster), you will be able to manage your Kubernetes assets via the *Kubernetes tab* on the left pane. Clicking on the Kubernetes icon will take you to your services dashboard. + +{% include image.html +lightbox="true" +file="/images/kubernetes/dashboard/kubernetes-dashboard.png" +url="/images/kubernetes/dashboard/kubernetes-dashboard.png" +alt="Codefresh Kubernetes Dashboard" +caption="Codefresh Kubernetes Dashboard" +max-width="80%" + %} + +With the graphical dashboard it is very easy to locate problematic services or deploy new ones quickly. If there are clusters that are not accessible to your user you can hide them by enabling the *Hide inaccessible clusters* option at the top right of the window in order to simplify the view. + +## Viewing your Kubernetes services + +If you have too many clusters you can choose the *add filter* button at the top of the window to hide specific clusters or namespaces. + +You will be able to see the following parameters for each service: +* Name +* Cluster +* Namespace +* Replica count +* Docker image +* Selector +* A status check + +You can also switch to a Grid view if you prefer that over the default List view: + + +{% include image.html +lightbox="true" +file="/images/kubernetes/dashboard/grid-view.png" +url="/images/kubernetes/dashboard/grid-view.png" +alt="Kubernetes Dashboard grid view" +caption="Kubernetes Dashboard grid view" +max-width="80%" + %} + + If there are clusters that are not accessible to your user you can hide them by enabling the *Hide inaccessible clusters* option at the top right of the window in order to simplify the view. + + +## Work with your services + +In this view, you will be able to perform the following actions: + +* Add new service +* Edit/Update existing services +* Remove service + + +## Deploying a new service + +The Kubernetes dashboard provides a GUI dialog to quickly deploy new services in your cluster. + +### Choose a Docker image + +To add a service, click the "Add Service" button on the top or the "plus" button on a specific namespace. Then fill in the details for your new service. + +You can add images built in Codefresh which were pushed to Codefresh registry or provide a name for Docker image that will be pulled from an [external Docker registry]({{site.baseurl}}/docs/integrations/docker-registries/). Notice that images which are not from Dockerhub must be mentioned with their full domain name. + +{% include image.html +lightbox="true" +file="/images/deployments/kubernetes/quick-ui-deploy.png" +url="/images/deployments/kubernetes/quick-ui-deploy.png" +alt="Deploying with the quick UI dialog" +caption="Deploying with the quick UI dialog" +max-width="60%" +%} + + +Use the following steps in order to add Image and pull secrets from the [connected Docker Registry]({{site.baseurl}}/docs/docker-registries/external-docker-registries/): +* Specify the image name in the format ` / / : ` +* Provide and image pull secret - this will be done for each namespace + +{% include image.html +lightbox="true" +file="/images/deployments/kubernetes/deploying-private-cf-registry.png" +url="/images/deployments/kubernetes/deploying-private-cf-registry.png" +alt="Deploying from the private Codefresh registry" +caption="Deploying from the private Codefresh registry" +max-width="60%" +%} + + +From this screen you can also [create Kubernetes image secrets]({{site.baseurl}}/docs/ci-cd-guides/access-docker-registry-from-kubernetes/) without actually deploying anything. + + +### Set environment variables and resources + +You can add extra environment variables that will passed to the deployment image. + +{% include image.html +lightbox="true" +file="/images/deployments/kubernetes/environment-variables-deployment.png" +url="/images/deployments/kubernetes/environment-variables-deployment.png" +alt="Environment variables for the deployment" +caption="Environment variables for the deployment" +max-width="60%" +%} + + + +You can also define resource limits for your pods. +It is a good practice to place maximum limits so that your services do not experience resource starvation. + + +### Adding a service with a manifest file + +If you are an advanced Kubernetes user, toggle the Deployment option button to the `YAML` position on the top right corner of the screen. +In this mode you can define exactly the contents for the service and deployment Kubernetes resources. + +{% include image.html +lightbox="true" +file="/images/deployments/kubernetes/define-k8s-service-resource.png" +url="/images/deployments/kubernetes/define-k8s-service-resource.png" +alt="Define a Kubernetes Service Resource" +caption="Define a Kubernetes Service Resource" +max-width="60%" +%} + +You can type directly in the browser window or paste content from a text editor. + +{% include image.html +lightbox="true" +file="/images/deployments/kubernetes/define-k8s-deployment-resource.png" +url="/images/deployments/kubernetes/define-k8s-deployment-resource.png" +alt="Define a Kubernetes Deployment Resource" +caption="Define a Kubernetes Deployment Resource" +max-width="60%" +%} + + +Congratulations! Your service is now deployed to your Kubernetes cluster. + +You can update an existing service in a similar manner from your Kubernetes services window - Just hit the "edit" icon and update your service using the same steps as in "Add new service" section. + +## Automate your deployment + +After your service is deployed to your Kubernetes cluster, you can automate image deployment using Codefresh pipelines. + +Some of the possible options are: + +1. The dedicated [deploy step]({{site.baseurl}}/docs/pipelines/steps/deploy/) in a pipeline. +1. The [cf-deploy-kubernetes step]({{site.baseurl}}/docs/ci-cd-guides/kubernetes-templating/) in a pipeline. This can also perform simple templating on Kubernetes manifests. + +See more choices in the [Deployment options page]({{site.baseurl}}/docs/deployments/kubernetes/deployment-options-to-kubernetes/). + +## Related articles +[Environment dashboard]({{site.baseurl}}/docs/deployments/kubernetes/environment-dashboard/) +[Add Config Maps]({{site.baseurl}}/docs/ci-cd-guides/add-config-maps-to-your-namespaces/) +[Kubernetes deployment quick start]({{site.baseurl}}/docs/getting-started/deployment-to-kubernetes-quick-start-guide/) + + + diff --git a/_docs/getting-started/architecture.md b/_docs/getting-started/architecture.md deleted file mode 100644 index 584fd507..00000000 --- a/_docs/getting-started/architecture.md +++ /dev/null @@ -1,199 +0,0 @@ ---- -title: "Architecture" -description: "" -group: getting-started -toc: true ---- - -Codefresh GitOps is built around an enterprise version of the Argo Ecosystem, fully compliant with the GitOps paradigm, with industry-standard security. -To cater to differing requirements and degrees of enterprise security, Codefresh supports hosted and hybrid installation environments for Codefresh runtimes. - -The sections that follow illustrate the architecture of the different installation environments, starting with a high-level overview of the Codefresh Platform. - -### Codefresh architecture - -The diagram shows a high-level view of the Codefresh Platform and its core components, the Codefresh Control Plane, the Codefresh Runtime, and the Codefresh Clients. - -{% include - image.html - lightbox="true" - file="/images/getting-started/architecture/arch-codefresh-simple.png" - url="/images/getting-started/architecture/arch-codefresh-simple.png" - alt="Codefresh Platform architecture" - caption="Codefresh Platform architecture" - max-width="100%" -%} - -{::nomarkdown} -
-{:/} - -#### Codefresh Control Plane -The Codefresh Control Plane is the SaaS component in the platform. External to the enterprise firewall, it does not have direct communication with the Codefresh Runtime, Codefresh Clients, or the customer's organizational systems. The Codefresh Runtime and the Codefresh Clients communicate with the Codefresh Control Plane to retrieve the required information. - - -{::nomarkdown} -
-{:/} - -#### Codefresh Runtime -The Codefresh Runtime is installed on a Kubernetes cluster, and houses the enterprise distribution of the Codefresh Application Proxy and the Argo Project. -Depending on the type of installation environment, the Codefresh Runtime is installed either in the Codefresh platform (hosted), or in the customer environment (hybrid). Read more in [Codefresh runtime architecture](#codefresh-runtime-architecture). - - -{::nomarkdown} -
-{:/} - -#### Codefresh Clients - -Codefresh Clients include the Codefresh UI and the Codefresh CLI. -The Codefresh UI provides a unified, enterprise-wide view of deployments (runtimes and clusters), and CI/CD operations (Delivery Pipelines, workflows, and deployments) in the same location. -The Codefresh CLI includes commands to install hybrid runtimes, add external clusters, and manage runtimes and clusters. - -### Codefresh runtime architecture -The sections that follow show detailed views of runtime architecture in the different installation environments, and descriptions of the Codefresh Runtime components. - -* [Hosted GitOps runtime architecture](#hosted-gitops-runtime-architecture) - In this installation environment, the Codefresh Runtime is installed on a _Codefresh-managed cluster_ in the Codefresh platform. -* Hybrid runtime architecture: - In this installation environment, the Codefresh Runtime is installed on a _customer-managed cluster_ in the customer environment. The Codefresh Runtime with or without ingress controllers: - * [Ingress controller](#ingress-controller-hybrid-runtime-architecture) - * [Ingress-less](#ingress-less-hybrid-runtime-architecture) -* Runtime components - * [Codefresh Application Proxy](#codefresh-application-proxy) - * [Argo Project](#argo-project) - * [Request Routing Service](#request-routing-service) - * [Tunnel Server](#codefresh-tunnel-server) - * [Tunnel Client](#codefresh-tunnel-client) - - -#### Hosted GitOps runtime architecture -In the hosted environment, the Codefresh Runtime is installed on a K8s cluster managed by Codefresh. - -{% include - image.html - lightbox="true" - file="/images/getting-started/architecture/arch-hosted.png" - url="/images/getting-started/architecture/arch-hosted.png" - alt="Hosted runtime architecture" - caption="Hosted runtime architecture" - max-width="100%" -%} - -#### Ingress controller hybrid runtime architecture -Runtimes with ingress use an ingress controller to control communication between the Codefresh Runtime in the customer cluster and the Codefresh Platform. Ingress controllers are optimal when the cluster with the Codefresh Runtime is exposed to the internet. - - - -{% include - image.html - lightbox="true" - file="/images/getting-started/architecture/arch-hybrid-ingress.png" - url="/images/getting-started/architecture/arch-hybrid-ingress.png" - alt="Ingress-based hybrid runtime architecture" - caption="Ingress-based hybrid runtime architecture" - max-width="100%" -%} - -#### Ingress-less hybrid runtime architecture -Ingress-less runtimes uses tunneling to control communication between the Codefresh Runtime in the customer cluster and the Codefresh Platform. Ingress-less runtimes are optimal when the cluster with the Codefresh Runtime is not exposed to the internet. - -{% include - image.html - lightbox="true" - file="/images/getting-started/architecture/arch-hybrid-ingressless.png" - url="/images/getting-started/architecture/arch-hybrid-ingressless.png" - alt="Ingress-less hybrid runtime architecture" - caption="Ingress-less hybrid runtime architecture" - max-width="100%" -%} - - - -#### Codefresh Application Proxy -The Codefresh Application Proxy (App-Proxy) functions as the Codefresh agent, and is deployed as a service in the Codefresh Runtime. -For hybrid runtimes with ingress, the App-Proxy is the single point-of-contact between the Codefresh Runtime, and the Codefresh Clients, the Codefresh Platform, and any organizational systems in the customer environment. -For ingress-less hybrid runtimes, the Tunnel Client forwards the incoming traffic from the Tunnel Server using internal reverse proxy to the App-Proxy. - -The App-Proxy: -* Accepts and serves requests from Codefresh Clients either via the Codefresh UI or CLI -* Retrieves a list of Git repositories for visualization in Codefresh Clients -* Retrieves permissions from the Codefresh Control Plane to authenticate and authorize users for the required operations. -* Implements commits for GitOps-controlled entities, such as Delivery Pipelines and other CI resources -* Implements state-change operations for non-GitOps controlled entities, such as terminating Argo Workflows - -{::nomarkdown} -
-{:/} - -#### Argo Project - -The Argo Project includes: -* Argo CD for declarative continuous deployment -* Argo Rollouts for progressive delivery -* Argo Workflows as the workflow engine -* Argo Events for event-driven workflow automation framework - - -{::nomarkdown} -
-{:/} - -#### Request Routing Service -The Request Routing Service is installed on the same cluster as the Codefresh Runtime in the customer environment. -It receives requests from the ingress controller (ingress) or the Tunnel Client (ingress-less), and forwards the request URLs to the Application Proxy, and webhooks directly to the Event Sources. - ->Important: - The Request Routing Service is available from runtime version 0.0.543 and higher. - Older runtime versions are not affected as there is complete backward compatibility, and the ingress controller continues to route incoming requests. - -#### Tunnel Server -Applies only to _ingress-less_ runtimes in hybrid installation environments. -The Codefresh Tunnel Server is installed in the Codefresh platform. It communicates with the enterprise cluster located behind a NAT or firewall. - -The Tunnel Server: -* Forwards traffic from Codefresh Clients to the client (customer) cluster. -* Manages the lifecycle of the Codefresh Tunnel Client. -* Authenticates requests from the Codefresh Tunnel Client to open tunneling connections. - -{::nomarkdown} -
-{:/} - -#### Tunnel Client -Applies only to _ingress-less_ runtimes in hybrid installation environments. - -Installed on the same cluster as the Codefresh Runtime, the Codefresh Tunnel Client establishes the tunneling connection to the Codefresh Tunnel Server via the WebSocket Secure (WSS) protocol. -A single Codefresh Runtime can have a single Tunnel Client. - -The Codefresh Tunnel Client: -* Initiates the connection with the Codefresh Tunnel Server. -* Forwards the incoming traffic from the Tunnel Server through the Request Routing Service to App-Proxy, and other services. - -{::nomarkdown} -
-{:/} - - -### Customer environment -The customer environment that communicates with the Codefresh Runtime and the Codefresh Platform, generally includes: -* Ingress controller for ingress hybrid runtimes - The ingress controller is configured on the same Kubernetes cluster as the Codefresh Runtime, and implements the ingress traffic rules for the Codefresh Runtime. - See [Ingress controller requirements]({{site.baseurl}}/docs/runtime/requirements/#ingress-controller). -* Managed clusters - Managed clusters are external clusters registered to provisioned hosted or hybrid runtimes for application deployment. - Hosted runtimes requires you to connect at least one external K8s cluster as part of setting up the Hosted GitOps environment. - Hybrid runtimes allow you to add external clusters after provisioning the runtimes. - See [Add external clusters to runtimes]({{site.baseurl}}/docs/runtime/managed-cluster/). -* Organizational systems - Organizational Systems include the customer's tracking, monitoring, notification, container registries, Git providers, and other systems. They can be entirely on-premises or in the public cloud. - Either the ingress controller (ingress hybrid environments), or the Tunnel Client (ingress-less hybrid environments), forwards incoming events to the Codefresh Application Proxy. - -### Related articles -[Set up a hosted runtime environment]({{site.baseurl}}/docs/runtime/hosted-runtime/) -[Install a hybrid runtime]({{site.baseurl}}/docs/runtime/installation/) - - - - diff --git a/_docs/getting-started/csdp-introduction.md b/_docs/getting-started/csdp-introduction.md deleted file mode 100644 index 6d48105f..00000000 --- a/_docs/getting-started/csdp-introduction.md +++ /dev/null @@ -1,208 +0,0 @@ ---- -title: "Introducing Codefresh" -description: "" -group: getting-started -toc: true ---- - -Codefresh is a full-featured, turn-key solution for application deployments and releases. Powered by Argo, Codefresh uses Argo CD, Argo Workflows, Argo Events, and Argo Rollouts, extended with unique functionality and features essential for enterprise deployments. - -Codefresh offers security, maintainability, traceability, and most importantly, a single control plane for all stakeholders, be they developers, operators, product owners or project managers. - -With Codefresh, you can: - -* Deliver software at scale by managing hundreds or thousands of deployment targets and applications -* Get a secure, enterprise-ready distribution of Argo with built-in identity, RBAC (role-based access control), and secrets -* Gain clear visibility across all deployments and trace changes and regressions from code to cloud in seconds -* Get enterprise-level dedicated support for Argo deployments -* Get insights into every aspect of your CI/CD with smart dashboards -* Manage multiple runtimes and multiple clusters in a single pane of glass - - -### Codefresh deployment models - -Codefresh supports hosted and hybrid deployments: - -* **Hosted** deployment or Hosted GitOps, a hosted and managed version of Argo CD. The SaaS version of Codefresh, the runtime is hosted on a Codefresh cluster (easy setup) and managed by Codefresh (zero maintenance overhead). -Click once to provision the hosted runtime, and start deploying applications to clusters without having to install and maintain Argo CD. - - -* **Hybrid** deployment, with the runtime hosted on the customer cluster and managed by the customer. -The hybrid offering retains runtimes within the customer infrastructure while giving you the power of Argo CD with Codefresh's CI and CD tools, to help achieve continuous integration and continuous delivery goals. - -For details, see [Codefresh architecture]({{site.baseurl}}/docs/getting-started/architecture). - - -### Codefresh and open source Argo -Codefresh brings the power of the Argo project to your Kubernetes deployments: - -* Argo CD for declarative continuous deployment -* Argo Rollouts for progressive delivery -* Argo Workflows as the workflow engine -* Argo Events for event-driven workflow automation framework - -Codefresh creates a conformed fork of the Argo project, providing an enterprise-supported version of the same, enhanced with unique functionality. - - - -### Codefresh and GitOps -Codefresh is GitOps-centric, and supports GitOps from the ground up. Codefresh leverages Argo components to have the entire desired state applied from Git to your Kubernetes cluster, and then reported back to Codefresh. -In addition: - -* Every state change operation in Codefresh is made via Git -* Codefresh audit log is derived from the Git changelog -* Codefresh access control is derived from Git permissions - -For details, see [entity model]({{site.baseurl}}/docs/getting-started/entity-model) and [access control]({{site.baseurl}}/docs/administration/access-control). - - -### Insights in Codefresh -Codefresh makes it easy to both access and visualize critical information for any CI/CD resource at any stage, at any level, and for anyone, from managers to DevOps engineers. - -{::nomarkdown} -
- {:/} - -#### Global deployment analytics - -The Home dashboard presents system-wide highlights in real-time, making it an ideal tool for management. -Get insights into important KPIs for entities across runtimes and clusters, in the same location. View status of runtimes and managed clusters, deployments, failed deployments with rollbacks, most active applications, and Delivery Pipelines. - -{% include - image.html - lightbox="true" - file="/images/incubation/home-dashboard.png" - url="/images/incubation/home-dashboard.png" - alt="Global deployment analytics" - caption="Global deployment analytics" - max-width="70%" -%} - -{::nomarkdown} -
- {:/} - -#### DORA metrics - -DORA metrics has become integral to enterprises wanting to quantify DevOps performance, and Codefresh has out-of-the-box support for it. - - -Apart from the metrics themselves, the DORA dashboard in Codefresh has several features such as the Totals bar with key metrics, filters that allow you to pinpoint just which applications or runtimes are contributing to problematic metrics, and the ability to set a different view granularity for each DORA metric. - -See [DORA metrics]({{site.baseurl}}/docs/reporting/dora-metrics/). - -{% include - image.html - lightbox="true" - file="/images/incubation/intro-dora-metrics.png" - url="/images/incubation/intro-dora-metrics.png" - alt="DORA metrics" - caption="DORA metrics" - max-width="60%" -%} - -{::nomarkdown} -
- {:/} - -#### Application analytics and analysis - -The Applications dashboard displays a unified view of applications across runtimes and clusters. No matter what the volume and frequency of your deployments, the Applications dashboard makes it easy to track them. Search for Jira issues, commit messages, committers, and see exactly when and if the change was applied to a specific application. - -See [Monitoring applications]({{site.baseurl}}/docs/deployment/applications-dashboard/). - -{::nomarkdown} -
- {:/} - -#### Delivery Pipelines -The Delivery Pipelines dashboard displays aggregated performance analytics based on the pipeline’s workflows, including step analytics across all the workflows in the pipeline. - -{::nomarkdown} -
- {:/} - -#### 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. Drill down to any workflow for further analysis. -{::nomarkdown} -
- {:/} - -### CI/CD resources in Codefresh -Wizards make it easy to create delivery pipelines and applications. Smart views and options make it easier to monitor and manage them. -{::nomarkdown} -
- {:/} - -#### Delivery Pipelines - -Delivery Pipelines are where the CI magic happens in Codefresh. Our pipeline creation wizard removes the complexity from creating, validating, and maintaining pipelines. Every stage has multi-layered views of all the related Git change information for the pipeline. -See [Create delivery pipelines]({{site.baseurl}}/docs/pipelines/create-pipeline/). - -{::nomarkdown} -
- {:/} - -#### Workflows -Drill down into a workflow to visualize the connections between the steps in the workflow. -A unique feature is the incorporation of Argo Events into the workflow visualization. You get a unified view of Argo Events and Argo Workflows in the same location, the events that triggered the workflow combined with the workflow itself. - -{::nomarkdown} -
- {:/} - -#### Workflow Templates -Select from ready-to-use Workflow Templates in the Codefresh Hub for Argo or create your own custom template. The **Run** option allows you to test a new Workflow Template, or changes to an existing template, without needing to first commit the changes. - - {% include - image.html - lightbox="true" - file="/images/whats-new/wrkflow-template-main.png" - url="/images/whats-new/wrkflow-template-main.png" - alt="Workflow Templates" - caption="Workflow Templates" - max-width="70%" - %} - -{::nomarkdown} -
- {:/} - -#### Applications -Create GitOps-compliant applications, and manage the application lifecycle in the Codefresh UI. - -Define all application settings in a single location through the intuitive Form mode or directly in YAML, and commit all changes to Git. -For easy access, after commit, the configuration settings are available in the Applications dashboard along with the deployment and resource information. - -See [Applications]({{site.baseurl}}/docs/deployment/create-application/). - -{% include - image.html - lightbox="true" - file="/images/applications/add-app-general-settings.png" - url="/images/applications/add-app-general-settings.png" - alt="Application creation in Codefresh" - caption="Application creation in Codefresh" - max-width="60%" -%} - -### GitOps CI integrations - -If you have Hosted GitOps, and your own CI tools for pipelines and workflows, enrich your deployments with CI information without disrupting existing processes. -Simply connect your CI tools to Codefresh, and our new report image template retrieves the information. For example, add the report image step in your GitHub Actions pipeline and reference the different integrations for Codefresh to retrieve and enrich the image with Jira ticket information. - -See [Image enrichment with integrations]({{site.baseurl}}/docs/integrations/image-enrichment-overview/). - -{% include - image.html - lightbox="true" - file="/images/incubation/github-action-int-settings.png" - url="/images/incubation/github-action-int-settings.png" - alt="Image enrichment with GitHub Actions integration" - caption="Image enrichment with GitHub Actions integration" - max-width="60%" -%} - - -### What to read next -[Quick start tutorials]({{site.baseurl}}/docs/getting-started/quick-start) \ No newline at end of file diff --git a/_docs/getting-started/entity-model.md b/_docs/getting-started/entity-model.md deleted file mode 100644 index 302940c1..00000000 --- a/_docs/getting-started/entity-model.md +++ /dev/null @@ -1,84 +0,0 @@ ---- -title: "Entity model" -description: "" -group: getting-started -toc: true ---- - -The Codefresh entity model is derived from these entity types: -* Codefresh account/user management entities -* Argo ecosystem entities -* Workflow, runtime, and Git Source entities -* Codefresh-specific entities such as pipelines, images, and applications - - - -### Codefresh account/user management entities -The account/user management entity types includes entities that do not share a direct relationship to the Codefresh domain. These are enterprise-specific entities in standard SAAS solutions. - -#### Account -Every user who signs in to Codefresh gets a private administrator user account. - -If you received an invitation to Codefresh, instead of a private user account, you are added as a collaborator to the main account. Your permissions are based on those explicitly assigned to you. - -The number of collaborators in an account is defined by the current plan associated with it. - -#### User -A user in Codefresh is one who has completed the sign-up process, and can log in using authorized third-party systems such as: -* GitHub -* Bitbucket -* GitLab -* Azure -* Google - -> If you configure SSO (Single Sign-On) for the account, the user can log in using only the configured SSO. - -#### Billing -For details, please contact [Sales](mailto:sales@codefresh.io?subject=[Codefresh] Codefresh billing inquiry). - -#### Single Sign-On (SSO) -Enterprise accounts can configure SSO. For details, see [Federated Single Sign-On (SSO) overview]({{site.baseurl}}/docs/administration/single-sign-on/). - -#### Security configuration -Security settings include: -* Inactivity timeout per collaborator account -* Domain restriction for invitations - -### Argo ecosystem entities -Codefresh is built on top of the successful open source Argo project, and as such, supports all the native Argo project-entities. -You can apply every supported entity that exists in the open source projects to your Codefresh account. - -### Workflow -Codefresh shows all the workflows executed with Argo Workflows. -Workflows with pipelines display links to the pipelines. Users can terminate or retry a workflow, and view its logs. - -### Runtime -A runtime represents an installation of Codefresh on the customer's K8s cluster, and contains all the components required to perform all tasks on the cluster. - -Review [Codefresh architecture]({{site.baseurl}}/docs/getting-started/architecture/), and [runtime installation ]({{site.baseurl}}/docs/runtime/installation/). - -### Git Source -A Git Source is a link to a Git repository that stores GitOps-controlled entities. You can create as many as Git Sources as you require. - -To understand how to control Git Sources using GitOps, see [access control]({{site.baseurl}}/docs/administration/access-control/). - -### Codefresh high-level entities -Codefresh creates high-level views that better represents, abstracts, and connects all the different entities in the Argo ecosystem. - -#### CI/CD pipeline -A pipeline is a Codefresh-representation of Argo Events, comprising an Argo Events Sensor and Argo Events Triggers. Every trigger in a sensor becomes a different pipeline in Codefresh. The same sensor can be associated with multiple pipelines, if it has different trigger conditions. - -A pipeline links to the following Argo Events entities: -* Sensor -* Event Source -* Workflow Template (or a cluster-level Workflow Template) - -A pipeline also shows all the workflows created from the triggered event associated with that pipeline. - -#### Image -An image represents a built artifact of a Docker image, reported to Codefresh using a dedicated interface. - -Users can use a predefined [Argo Workflow Template](https://codefresh.io/argohub/workflow-template/codefresh-csdp) to help with transferring the image information to Codefresh. - -#### Application -A holistic view of all your Argo CD and Argo Rollouts deployments that link to the underlying artifacts and workflows. diff --git a/_docs/getting-started/faq.md b/_docs/getting-started/faq.md deleted file mode 100644 index bd189aab..00000000 --- a/_docs/getting-started/faq.md +++ /dev/null @@ -1,52 +0,0 @@ ---- -title: "Frequently asked questions" -description: "" -group: getting-started ---- -We have collected a few of the common questions on the Codefresh solution. - -For questions on Codefresh Classic, navigate to our [FAQs for Codefresh Classic](https://codefresh.io/docs/docs/getting-started/faq/){:target="\_blank"}. - - -**Q. What is the Codefresh platform?** - -A. The Codefresh platform is a full-featured, turn-key solution for application deployments and releases. Powered by the Argo Project, Codefresh uses Argo CD, Argo Workflows, Argo Events, and Argo Rollouts, extended with unique functionality and features essential for enterprise deployments. - -**Q. Which deployment environments does Codefresh support?** - -A. The current release of Codefresh supports hosted and hybrid deployment environments. Stay tuned for our announcement on support for on-premises deployments. - -**Q. How does Codefresh relate to Open Source Argo?** - -A. Codefresh creates a conformed fork of the Argo Project. You get an enterprise-supported version of the Argo Project comprising Argo Workflows, Argo Events, Argo CD, and Argo Rollouts. You can take advantage of the Argo Project offering, with the extended functionality that Codefresh brings to it. - -**Q. I already have a Kubernetes cluster with Argo CD. Can I install Codefresh on the same cluster?** - -A. Hybrid runtimes must be installed on a clean Kubernetes cluster without any Argo Project components. Because we create a conformed fork of the Argo Project in Codefresh, installing it on a cluster with Argo components creates a conflict that will cause the installation to fail. - -**Q. I have resources on my Kubernetes cluster that I want to use in Codefresh. What should I do?** - -A. We will be giving detailed instructions on migrating resources from Kubernetes clusters to Codefresh-based Kubernetes clusters. - -**Q. Does Codefresh support all Git providers?** -A. At the time of writing, Codefresh supports GitHub. We are working to quickly extend support to GitLab and Bitbucket. Stay tuned. - -**Q. What are the browser requirements for the Codefresh UI?** - -A. Officially, we support the latest version of the Chrome browser. Any browser released in the last couple of years should work without major issues. -The following browser versions are **NOT** supported: - -{: .table .table-bordered .table-hover} -| Browser | Version | Date released | -| -------------- | ---------------------------- |-------------------------| -| Chrome | < 51 | May 2016 | -| Firefox | < 54 | Jun 2017 | -| Edge | < 14 | Aug 2016 | -| Safari | < 10 | Sep 2016 | - - -## Migration from Codefresh Classic - -**Q. I have Codefresh Classic. Can I migrate to Codefresh?** -A. At the time of writing, we are working on making the migration from Codefresh Classic to Codefresh as seamless as possible. Stay tuned for the migration announcement. - diff --git a/_docs/getting-started/gitops.md b/_docs/getting-started/gitops.md deleted file mode 100644 index d7542fbb..00000000 --- a/_docs/getting-started/gitops.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: "GitOps approach" -description: "" -group: getting-started -toc: true ---- - -> In the documentation, Kubernetes and K8s are used interchangeably. - -### GitOps - -The Codefresh platform is built entirely around the concept of GitOps, a set of best practices where the entire code delivery process is controlled via Git, including infrastructure and application definition, and automation to complete updates and rollbacks. - -To fully understand the benefits of Codefresh, let's briefly recap GitOps, and how it can help: - -#### Infrastructure as code, the entire system described declaratively - Infrastructure as code is a modern approach that "declaratively" describes the state of a system as code, while having that single source of truth applied to an end-system. The end-systems in most cases are modern cloud native tools. - - Declarative means that configuration is guaranteed by a set of facts, instead of by a set of instructions. With your end system's declarations versioned in Git, you have a single source of truth. You can then both easily deploy and roll back your end system according to the state changes in Git. And more important, if and when disaster strikes, you can also reproduce your cluster’s infrastructure reliably and quickly. - - GitOps is just a specific case of infrastructure as code where the end system is a Kubernetes cluster. - -#### Desired system state versioned in Git - With the declaration of your system stored in a version control system, and serving as your canonical source of truth, you have a single place from which everything is derived and driven. Now not only your application code is in Git, but also all the information required to install and manage your application, including service definition, deployment information, and more. - - Developers can continue with the familiar and convenient approaches they are already using for their applicative code. In addition, Git makes complicated tasks like collaboration (via pull requests), security (via signed commits), permissions (repository permissions), and rollback, as trivial as they can get. - - -#### Use dedicated tools to implement transfer of desired state into the end system - Once the state of your end-system is declared and kept under version control, you need a tool and process to apply the updated desired state into the end system. - - One of the tools for implementing infrastructure as code in the realm of DevOps is [Terraform](https://www.terraform.io/), for example. - - While you can implement GitOps (infrastructure as code for Kubernetes), using a battle-ready tool like Terraform which has a plugin system that also supports Kubernetes, K8s has many nuances that differ from a traditional sync process to a cloud system or some other standard REST API end system. - - To address the specific use cases of Kubernetes, there are new tools dedicated to implementing GitOps (infrastructure as code for k8s), such as [ArgoCD](https://github.com/argoproj/argo-cd). - - diff --git a/_docs/getting-started/main-concepts.md b/_docs/getting-started/main-concepts.md deleted file mode 100644 index c2d4f418..00000000 --- a/_docs/getting-started/main-concepts.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: "Main concepts" -description: "" -group: getting-started -toc: true ---- - -### Built on top of the open source Argo -Codefresh maintains a [conformed](https://github.com/argoproj/argo-conformance-program) fork of the following Argo components, providing an enterprise-supported version of them: -* [Argo CD](https://github.com/argoproj/argo-cd): Declarative continuous deployment for Kubernetes. -* [Argo Rollouts](https://argoproj.github.io/argo-rollouts/): Progressive Delivery for Kubernetes. -* [Argo Workflows](https://github.com/argoproj/argo-workflows): Workflow engine for Kubernetes. -* [Argo Events](https://github.com/argoproj/argo-events): Event-driven workflow automation framework. - -For details, see [Codefresh architecture]({{site.baseurl}}/docs/getting-started/architecture/). - -### Hybrid behind firewall model -Codefresh performs an installation, called a Runtime, on the user's K8s cluster. The Runtime contains all required components for the Codefresh experience. - -For details, see [Codefresh architecture]({{site.baseurl}}/docs/getting-started/architecture/). - -### GitOps native approach -Codefresh is built entirely on the heavily-adopted concept of GitOps. Read the detailed explanation on our [GitOps approach]({{site.baseurl}}/docs/getting-started/gitops/).
-Codefresh leverages Argo components (Argo CD and Argo Events), to have the entire desired state applied from Git to the user's K8s cluster, and also reported back to Codefresh platform. - -### Every state change operation in Codefresh is made via Git -Codefresh has taken the GitOps approach a step forward by making our entire entity model fully controlled by GitOps via Codefresh, meaning that the entire state of your account is maintained in Git. For details, see [entity model]({{site.baseurl}}/docs/getting-started/entity-model/). - -Codefresh provides a full front-end experience powered by a strong API layer (GraphQL), and every state change (via GraphQL mutation) actually performs a commit on behalf of the user to Git. - -### Audit log derived from Git changelog -Codefresh has built its sophisticated but simple audit log on all operations to the system, for both the Git change and the log of API calls that have been made to the system. -For details, see [audit]({{site.baseurl}}/docs/administration/audit/). - -### Access control derived from Git permissions -Codefresh has built its sophisticated but simple access control model on top of the existing Git operations that are defined externally to the system.
-For details, see [access control]({{site.baseurl}}/docs/administration/access-control/). diff --git a/_docs/getting-started/quick-start.md b/_docs/getting-started/quick-start.md deleted file mode 100644 index 203c03d0..00000000 --- a/_docs/getting-started/quick-start.md +++ /dev/null @@ -1,55 +0,0 @@ ---- -title: "Quick start" -description: "" -group: getting-started -toc: true ---- - -Check out our quick start tutorial to get up and running in the Codefresh platform with hosted or hybrid runtimes. - -The tutorial is divided into these sections: -* Provisioning runtimes -* Creating and deploying an application -* Triggering and creating a Delivery Pipeline - -Each section indicates the runtime environment it is relevant to. - -### Provision runtimes -Based on your deployment model, start by provisioning the hosted or hybrid runtime. Hosted and hybrid runtimes can co-exist with each other. - - -#### Hosted -Hosted runtimes are hosted on a Codefresh cluster and managed by Codefresh. You need to provision your hosted runtime once for your account. - -1. [Provision a hosted runtime]({{site.baseurl}}/docs/getting-started/quick-start/install-hosted) - Provision the hosted runtime with a single click, and complete the setup for your hosted environment. - -{::nomarkdown} -
-{:/} - -#### Hybrid -Hybrid runtimes: Hosted on a customer cluster and managed by the customer. You can provision multiple hybrid runtimes in the same account. - -1. [Prepare for hosted runtime installation]({{site.baseurl}}/docs/getting-started/quick-start/verify-requirements) - Verify your environment matches the requirements for installing Codefresh runtime. -1. [Install hybrid runtime]({{site.baseurl}}/docs/getting-started/quick-start/runtime) - Install the Codefresh runtime by downloading the CLI, installing the runtime, and validate successful installation in the UI - -### Deploy an application - -1. [Create an application]({{site.baseurl}}/docs/getting-started/quick-start/create-app-ui) - Create the `codefresh-guestbook` application in the Codefresh UI. -1. [Create and commit resources for application]({{site.baseurl}}/docs/getting-started/quick-start/create-app-specs) - Create rollout and service resources, and commit these resources to deploy the `codefresh-guestbook` application. -1. [Update the image tag for application]({{site.baseurl}}/docs/getting-started/quick-start/create-rollout) - Update the image for the `codefresh-guestbook` application to trigger a rollout. - -### Trigger/create a Delivery Pipeline -> Available for hybrid deployments. - -1. [Trigger the Hello World example pipeline]({{site.baseurl}}/docs/getting-started/quick-start/hello-world) - Configure the Git event to trigger the demo pipeline. -1. [Create a basic CI delivery pipeline]({{site.baseurl}}/docs/getting-started/quick-start/create-ci-pipeline) - Create a new CI delivery pipeline in Codefresh. - diff --git a/_docs/getting-started/quick-start/create-app-specs.md b/_docs/getting-started/quick-start/create-app-specs.md deleted file mode 100644 index 1c44be1f..00000000 --- a/_docs/getting-started/quick-start/create-app-specs.md +++ /dev/null @@ -1,131 +0,0 @@ ---- -title: "Create and commit resources for application" -description: "" -group: getting-started -sub-group: quick-start -toc: true ---- - -Now that you have created an application, you need to deploy the application. Let's deploy the `codefresh-guestbook` application by creating and commiting resources. -You will create and commit the following resources: -1. A folder in Git to save resources for the application -1. `Rollout` resource defining the deployment strategy -1. `Service` resource to expose the application to external traffic - -### Before you begin -* [Create an application]({{site.baseurl}}/docs/getting-started/quick-start/create-app-ui) -* Make sure [Argo Rollouts is installed]({{site.baseurl}}/docs/deployment/install-argo-rollouts) on the target cluster - -### Create folder in Git for application resources -Create a folder in the Git repo in which to save all the resources for the `codefresh-guestbook` application. - -* In your Git repo, create a folder to store the resources needed to deploy the application. - For example, `/quick-start/` - -### Create rollout.yaml - -Create a rollout resource for the application you want to deploy. - - -To leverage Argo Rollouts' deployment capabilities, we are using the Argo's `rollout` resource instead of the native Kubernetes Deployment object. -For detailed information on the fields you can define, see [Argo Rollout specification](https://argoproj.github.io/argo-rollouts/features/specification/){:target="\_blank"}. - - -* In the Git repository create the `rollout.yaml` file, as in the example below. - - -```yaml -apiVersion: argoproj.io/v1alpha1 -kind: Rollout -metadata: - name: codefresh-guestbook-rollout -spec: - replicas: 4 - revisionHistoryLimit: 2 - selector: - matchLabels: - app: codefresh-guestbook - template: - metadata: - labels: - app: codefresh-guestbook - spec: - containers: - - image: gcr.io/heptio-images/ks-guestbook-demo:0.1 - name: codefresh-guestbook - ports: - - name: http - containerPort: 80 - protocol: TCP - minReadySeconds: 30 - strategy: - canary: - steps: - - setWeight: 25 - - pause: {duration: 20s} - - setWeight: 75 - - pause: {duration: 15s} -``` - -#### Fields in `rollout.yaml` - -{: .table .table-bordered .table-hover} -| Rollout Field | Notes | -| -------------- | -------------| -| `replicas` | When deployed, the rollout creates four replicas of the `codefresh-guestbook` application.| -| `revisionHistoryLimit` | The number of replica sets to retain. | -| `matchLabels` | The pods to select for this rollout. In our example, all pods with the label `codefresh-guestbook` are selected.| -| `image` | The container image for the application with the version tag, `gcr.io/heptio-images/ks-guestbook-demo:0.1` in our example.| -| `name` | The name of the application, `codefresh-guestbook` in our example. | -| `canary` | The deployment strategy, `canary` meaning that the traffic is gradually routed to the new application. Starting with `setWeight` of `25%` followed by a `pause` of 20 seconds, and the remaining `75%` after verification.| -| `templateName` | The analysis template used to validate the application metrics. Our example has the `background-analysis` template, and interfaces with Prometheus to monitor and validate metric thresholds.| - - -### Create a service resource -Create a service resource to expose your application to external traffic. - -* Create a `service.yaml` resource for the application you want to deploy, as in the example below. - > Create it in the same folder in which you saved `rollout.yaml`. - -```yaml -apiVersion: v1 -kind: Service -metadata: - name: codefresh-guestbook-svc -spec: - ports: - - port: 8080 - targetPort: 80 - selector: - app: codefresh-guestbook # must be the same as the selector defined in rollouts.yaml - type: LoadBalancer -``` - -#### Fields in `service.yaml` - -{: .table .table-bordered .table-hover} -| Service field | Notes | -| -------------- | -------------- | -| `spec.ports` | The internal `port`, 8080 in our example, and external `targetPort`, 80 in our example.| -| `selector.app` | The pods to select, and MUST be identical to that defined in `rollouts.yaml`, `codefresh-guestbook` in our example.| - -### View application resources in Codefresh -Once you create and commit the `rollout` and `service` resources, return to the Applications dashboard. The Current State to see these resources. - -1. In the Codefresh UI, go to the [Applications dashboard](https://g.codefresh.io/2.0/applications-dashboard?sort=desc-lastUpdated){:target="\_blank"}. -1. Select the application. - The Current State tab is now populated with the `rollout` and `service` resources you added. - - {% include - image.html - lightbox="true" - file="/images/getting-started/quick-start/cdops-app-current-state.png" - url="/images/getting-started/quick-start/cdops-app-current-state.png" - alt="Current State with resources for application" - caption="Current State with resources for application" - max-width="70%" - %} - -### What to do next - -[(Optional) Update image tag for application]({{site.baseurl}}/docs/getting-started/quick-start/create-rollout) \ No newline at end of file diff --git a/_docs/getting-started/quick-start/create-app-ui.md b/_docs/getting-started/quick-start/create-app-ui.md deleted file mode 100644 index b2fdff6b..00000000 --- a/_docs/getting-started/quick-start/create-app-ui.md +++ /dev/null @@ -1,110 +0,0 @@ ---- -title: "Create an application" -description: "" -group: getting-started -sub-group: quick-start -toc: true ---- - -Let's start by creating a simple application, the `codefresh-guestbook` application in the Codefresh UI. -We'll create the application without resources and then define/add resources in the next step. - - -For detailed information, see [Create an application]({{site.baseurl}}/docs/deployment/create-application). - - -**How to** - - -1. In the Codefresh UI, go to the [Applications](https://g.codefresh.io/2.0/applications-dashboard?sort=desc-lastUpdated){:target="\_blank"} dashboard. -1. Select **Add Application** on the top-right. -1. In the Add Application panel, add definitions for the application: - * **Application name**: `codefresh-guestbook` for the quick start. - * **Runtime**: The runtime to associate with the application, `hosted-runtime` for the quick start. - * **Name for YAML file**: The name of the application's configuration manifest, assigned on commit to Git. By default, the manifest is assigned the application name. - You can click the Edit icon and change the name, if needed. - - >You cannot change the application definitions once you continue to the Configuration settings. - -{% include - image.html - lightbox="true" - file="/images/getting-started/quick-start/cdops-add-app-settings.png" - url="/images/getting-started/quick-start/cdops-add-app-settings.png" - alt="Add Application panel" - caption="Add Application panel" - max-width="50%" - %} - -{:start="4"} -1. Select **Next** to go to the Configuration tab. - By default you are in Form mode. You can toggle between the Form and YAML modes as you define the application's configuration settings. -1. Define the **General** settings for the application: - * **Repository URL**: The URL to the repo in Git where you created the YAML resource files for the application. - * **Revision**: The branch in Git with the resource files. - * **Path**: The folder in Git with the resource files. - * **Namespace**: Optional. For the quick start, we'll create a namespace for the application, entitled `quick-start`. - * **Sync Policy**: Change to **Automatic**, and select **Prune resources** to automatically remove unused resources. - * **Sync Options**: If you defined a namespace, select **Auto-create namespace** to ensure that the namespace is created if it doesn't exist. - -{% include - image.html - lightbox="true" - file="/images/getting-started/quick-start/cdops-add-app-configuration.png" - url="/images/getting-started/quick-start/cdops-add-app-configuration.png" - alt="Add Application Quick Start: General settings" - caption="Add Application Quick Start: General settings" - max-width="70%" - %} - - -{:start="6"} -1. Retain the default **Advanced Settings**. -1. To commit all your changes, select **Commit**. - The Commit form is displayed with the application's definitions on the left, and the read-only version of the manifest with the configuration settings you defined on the right. -1. Select the **Git Source** to which to commit. - -{% include - image.html - lightbox="true" - file="/images/getting-started/quick-start/cdops-add-app-commit.png" - url="/images/getting-started/quick-start/cdops-add-app-commit.png" - alt="Add Application Quick Start: Commit to Git" - caption="Add Application Quick Start: Commit to Git" - max-width="70%" - %} - -{:start="9"} -1. Add a commit message and then select **Commit** at the bottom-right of the panel. - You are directed to the [Applications dashboard](https://g.codefresh.io/2.0/applications-dashboard?sort=desc-lastUpdated){:target="\_blank"}. - You may have to wait for a few seconds until the application is synced to the cluster. - - {% include - image.html - lightbox="true" - file="/images/getting-started/quick-start/cdops-add-app-dashboard.png" - url="/images/getting-started/quick-start/cdops-add-app-dashboard.png" - alt="Application dashboard with new application" - caption="Application dashboard with new application" - max-width="70%" - %} - -{:start="10"} -1. Select the application. The Current State tab does not display any resources as we have not created any resources for the application. - - {% include - image.html - lightbox="true" - file="/images/getting-started/quick-start/cdops-app-empty-current-state.png" - url="/images/getting-started/quick-start/cdops-app-empty-current-state.png" - alt="Empty Current State for new application" - caption="Empty Current State for new application" - max-width="70%" - %} - - -In the next task, you will create and commit resources for the `codefresh-guestbook` application and deploy the application. - - -### What to do next -[Create and commit resources for application]({{site.baseurl}}/docs/getting-started/quick-start/create-app-specs/) diff --git a/_docs/getting-started/quick-start/create-ci-pipeline.md b/_docs/getting-started/quick-start/create-ci-pipeline.md deleted file mode 100644 index 5a297b78..00000000 --- a/_docs/getting-started/quick-start/create-ci-pipeline.md +++ /dev/null @@ -1,186 +0,0 @@ ---- -title: "Create a basic CI delivery pipeline" -description: "" -group: getting-started -sub-group: quick-start -toc: true ---- - -Now that you have configured and run the Hello World demo pipeline, let's create a more advanced pipeline. - -For the quick start, you'll create a basic CI Delivery Pipeline in Codefresh. - -The Delivery Pipeline: -* Clones a Git repository -* Builds a docker image using `kaniko` -* Pushes the built image to a Docker Registry -* Runs an example testing step -* Sends the image information to Codefresh - -Our CI pipeline interacts with third-party services such as GitHub and a Docker Registry. You need to first add secrets to the cluster to store the credentials required. - - -### Create a Personal Access Token (PAT) -You must have a PAT to clone the repository. - - -1. Create your PAT (Personal Access Token) with a valid `expiration` date and `scope`. - Scopes: `repo` and `admin-repo.hook` - - {% 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="GitHub PAT permissions for CI pipeline" - caption="GitHub PAT permissions for CI pipeline" - max-width="30%" - %} - -{:start="2"} -1. Define your PAT and namespace by replacing the values in these commands: - -``` - export GIT_TOKEN=[PAT token] - export NAMESPACE=[Codefresh runtime namespace] -``` - -1. Create a generic Kubernetes secret with your PAT token: - -``` -kubectl create secret generic github-token \ - --from-literal=token=$GIT_TOKEN --dry-run=client \ - --save-config -o yaml | kubectl apply -f - -n $NAMESPACE -``` - -### Create Docker-registry secret -To push the image to a Docker registry, we'll need the credentials on our cluster. - -> The Docker registry secret is different from the general registry secret. - -1. Export the values for the Docker registry's `server`, `username`, `password`, `email`, and `namespace`: - -``` -export DOCKER_REGISTRY_SERVER=[Server] -export DOCKER_USER=[Username] -export DOCKER_PASSWORD=[Password] -export DOCKER_EMAIL=[Email] -export NAMESPACE=[Codefresh runtime namespace] -``` - -{:start="2"} -1. Create the secret: - -``` -kubectl create secret docker-registry\ - --docker-server=$DOCKER_REGISTRY_SERVER \ - --docker-username=$DOCKER_USER \ - --docker-password=$DOCKER_PASSWORD \ - --docker-email=$DOCKER_EMAIL -n $NAMESPACE -``` - - > In the Workflow Template, the Docker registry name defaults to `docker-config`. - - -### Create general registry secret -Create a general registry secret to send the image information to Codefresh. - -1. Export the values for your registry's `username`, `password`, `domain`, and `namespace`: - -``` -export USER=[Username] -export PASSWORD=[Password] -export DOMAIN=[Domain] -export NAMESPACE=[Codefresh runtime namespace] -``` - -{:start="2"} -1. Create the secret: - -``` -kubectl create secret generic registry-creds \ - --from-literal=username=$USER \ - --from-literal=password=$PASSWORD \ - --from-literal=domain=$DOMAIN \ - --dry-run=client --save-config -o yaml | kubectl apply -f - -n $NAMESPACE -``` - -### Create the CI delivery pipeline -Now that you have defined the secrets, create the CI delivery pipeline in Codefresh. - -1. In the 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/getting-started/quick-start/quick-start-new-pipeline.png" - url="/images/getting-started/quick-start/quick-start-new-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 event for the delivery pipeline. - * **Sensor Name**: The name of the sensor resource, for example, `sensor-cf-ci`. - * **Trigger Name**: The event configured in the sensor to trigger the Workflow Template, for example, `push-cf-ci`. -1. From the list of **Git Sources**, select the Git Source to which to commit the resources for this delivery pipeline. - > Do not select the marketplace Git Source as you cannot commit to it. - If you have multiple runtimes installed, the Git Source you select also determines the runtime that executes the pipeline. -1. Select **Next**. - In the **Configuration** tab, **Workflow Templates** is selected. This is our CI Starter Workflow Template, that builds a Docker image using Kaniko, reports image metadata to Codefresh, and tests the image. -1. Select **Trigger Conditions**. -1. From the **Add** dropdown, select **Git Events**. -1. In the **Git Repository URLs** field, select one or more GitHub repositories to listen to for the selected event. -1. From the **Event** dropdown, select the event, in our case, **Commit pushed**. - Codefresh displays all the **Arguments** available for the selected event. - You can map each argument to a single or combination of predefined variables, which Codefresh automatically maps to the correct path when you commit the changes. 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 arguments" - caption="Predefined variables for arguments" - max-width="30%" - %} - - In each field, type `$` and from the list of predefined variables, select each of these in turn: - - * **REPO**: Required. The repository to clone during the build step. Select `Repository name`. - * **IMAGE_NAME**: Required. The name for the built image. Enter the name in the format `([docker_url]/[account]/[image_name]`. - * **TAG**: Optional. The tag for the built image. If not defined, uses the default tag `latest`. Enter `1.0`. - * **GIT_REVISION**: Optional. The Git revision to report to Codefresh. Select `Git revision`. - * **GIT_BRANCH**: Optional. The Git branch to report to Codefresh. Select `Git branch`. - * **GIT_COMMIT_URL**: Optional. The Git commit URL to report to Codefresh. Select `Commit url`. - * **GIT_COMMIT_MESSAGE**: Optional. The Git commit message to report to Codefresh. Select `Commit message`. - - You are now ready to commit the delivery pipeline to the Git Source. - -{:start="10"} -1. Select **Apply**, and then **Commit** on the top-right. - The Commit Changes panel shows the files to be committed. -1. Enter the commit message and then select **Commit**. -1. In the **Delivery Pipelines** page to which you are redirected, verify that your pipeline is displayed. - - Behind the scenes, we committed the pipeline to your Git repository and synced the resources to your cluster. - It may take a few seconds for the Git-to-cluster sync to complete, and then your pipeline should be displayed. - -### Trigger the pipeline with a Git commit event -Make a change to a file in the Git repository to trigger the pipeline. - -1. Go to the Git repository selected for the trigger condition. -1. Make a change to any file to get a commit event. -1. In the UI, go back to [Delivery Pipelines](https://g.codefresh.io/2.0/pipelines){:target="\_blank"} to see the new workflow for the pipeline. - -Continue to tweak the pipeline and enhance its capabilities. - - -### What to do next -If you have not created an application in Codefresh, continue with: - -[Create resources for codefresh-guestbook application]({{site.baseurl}}/docs/getting-started/quick-start/create-app-specs) - diff --git a/_docs/getting-started/quick-start/create-github-action-ci.md b/_docs/getting-started/quick-start/create-github-action-ci.md deleted file mode 100644 index b95544b6..00000000 --- a/_docs/getting-started/quick-start/create-github-action-ci.md +++ /dev/null @@ -1,7 +0,0 @@ ---- -title: "Connect a GitHub Action CI to enrich image" -description: "" -group: getting-started -sub-group: quick-start -toc: true ---- \ No newline at end of file diff --git a/_docs/getting-started/quick-start/create-rollout.md b/_docs/getting-started/quick-start/create-rollout.md deleted file mode 100644 index 763df47a..00000000 --- a/_docs/getting-started/quick-start/create-rollout.md +++ /dev/null @@ -1,76 +0,0 @@ ---- -title: "Update image tag for application" -description: "" -group: getting-started -sub-group: quick-start -toc: true ---- - -You will now make a change in the application manifest, and update the image tag. Because we selected auto-sync in the application settings, Argo CD detects that the live state in the cluster is out of sync with the desired state in Git, and triggers the new rollout. - -### Before you begin - -* [Create resources for application]({{site.baseurl}}/docs/getting-started/quick-start/create-app-specs/) - - -### Update image tag in rollout.yaml -Update the image tag in the `codefresh-guestbook` application. - -1. Go to the Git repo with `rollout.yaml`. -1. Update the image tag from `0.1` to `0.2` as in the example below. - -```yaml -... -template: - metadata: - labels: - app: codefresh-guestbook - spec: - containers: - - image: gcr.io/heptio-images/ks-guestbook-demo:0.2 - name: codefresh-guestbook - ports: - - name: http - containerPort: 80 - protocol: TCP -... -``` -{:start="3"} -1. Commit the change. - -### View the rollout in the Applications dashboard -When the image tag is updated, the auto-sync initiates the rollout. - -1. Go back to the [Applications dashboard](https://g.codefresh.io/2.0/applications-dashboard?sort=desc-lastUpdated){:target="\_blank"}. -1. Select the application you created. - The deployment entry for the application is displayed as progressing. - - {% include - image.html - lightbox="true" - file="/images/getting-started/quick-start/cdops-app-rollout-in-dashboard.png" - url="/images/getting-started/quick-start/cdops-app-rollout-in-dashboard.png" - alt="Application dashboard with rollout in progress" - caption="Application dashboard with rollout in progress" - max-width="60%" - %} - -{:start="3"} -1. To visualize the rollout analysis, click the rollout name. - - {% include - image.html - lightbox="true" - file="/images/getting-started/quick-start/cdops-app-rollout-panel.png" - url="/images/getting-started/quick-start/cdops-app-rollout-panel.png" - alt="Rollout analysis in progress" - caption="Rollout analysis in progress" - max-width="60%" - %} - -{:start="4"} -1. To view metric validation details, expand **Background Analysis** in the panel. - -You have created and deployed an application in Codefresh. - - \ No newline at end of file diff --git a/_docs/getting-started/quick-start/hello-world.md b/_docs/getting-started/quick-start/hello-world.md deleted file mode 100644 index 02011074..00000000 --- a/_docs/getting-started/quick-start/hello-world.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -title: "Trigger the Hello World example pipeline" -description: "" -group: getting-started -sub-group: quick-start -toc: true ---- - -Now that you have successfully installed the hybrid runtime, you can trigger one of the Hello World demo pipelines included in the runtime package. -The two Hello World example pipelines are triggered by different event conditions: -* Git (GitHub) event -* Calendar (cron) event - -For the quick start, let's focus on the `github/hello-world` pipeline. - -### Create a PAT token -To commit resources for the `github/hello-world` pipeline, you need to add a PAT to Codefresh. - -1. Create your personal token with a valid `expiration` date and `scope` with `base64` encoding. - For the pipeline, you need `repo` and `admin-repo.hook` scopes: - - {% 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="GitHub PAT permissions for Hello World pipeline" - caption="GitHub PAT permissions for Hello World pipeline" - max-width="30%" - %} - -{:start="2"} -1. In the Codefresh UI, go to [User Settings](https://g.codefresh.io/2.0/user-settings){:target="\_blank"}, add your token. - -### View pipelines -View the pipelines in Codefresh. - -1. In the Codefresh UI, go to [Delivery Pipelines](https://g.codefresh.io/2.0/pipelines){:target="\_blank"}. - - {% include - image.html - lightbox="true" - file="/images/getting-started/quick-start/quick-start-pipelines.png" - url="/images/getting-started/quick-start/quick-start-pipelines.png" - alt="Demo pipelines in the Pipelines page" - caption="Demo pipelines in the Pipelines page" - max-width="30%" - %} - - * The `github/hello-world` pipeline has not been triggered as it requires a Git event to trigger it. - * The `cron/hello-world` pipeline shows statistics as it has already been triggered based on the `cron` interval. - -### View and update manifest -As we don't have a workflow for this pipeline, you will configure the Git Source resource in the pipeline's **Manifest** tab. -1. In the **Pipelines** page, to drill down, select the pipeline name. -1. Select the **Manifest** tab, and click the arrowhead to expand the resource view. - - {% include - image.html - lightbox="true" - file="/images/getting-started/quick-start/quick-start-manifest-expand.png" - url="/images/getting-started/quick-start/quick-start-manifest-expand.png" - alt="Expand resource view in Mainfests tab" - caption="Expand resource view in Mainfests tab" - max-width="30%" - %} - - You can see these resources: - - * Event Source (`event-source.git-source.yaml`). - * Sensor (`sensor.git-source.yaml`) - * Workflow Template (`workflow-template.hellow-world.yaml`) - - - > The pipeline is configured to run on a `PUSH` event in the Git repository. - - -Codefresh does the following: -* Commits the changes to your Git repository. -* Synchronizes the changes in Git back to your cluster, and updates the `event-source.git-source` resource. -* Triggers this pipeline after the `PUSH` event to your repository. -* Creates a workflow. View it in the UI, in the [Workflows](https://g.codefresh.io/2.0/workflows){:target="\_blank"} dashboard. - Select view workflow details to see the workflow log. - -### What to do next -[Create a basic CI pipeline]({{site.baseurl}}/docs/getting-started/quick-start/create-ci-pipeline) diff --git a/_docs/getting-started/quick-start/install-hosted.md b/_docs/getting-started/quick-start/install-hosted.md deleted file mode 100644 index 8d3c6fbf..00000000 --- a/_docs/getting-started/quick-start/install-hosted.md +++ /dev/null @@ -1,109 +0,0 @@ ---- -title: "Provision a hosted runtime" -description: "" -group: getting-started -sub-group: quick-start -toc: true ---- - -If you have Hosted GitOps, set up your hosted runtime environment: - -1. Provision the hosted runtime with a single click -1. Authorize access through your OAuth token to the organization where Codefresh creates the Git runtime repo and the shared configuration repo -1. Connect to an external K8s cluster with access to the internet, to which you can deploy applications -1. Install Argo Rollouts on the cluster - -Read our [blog on Hosted GitOps](https://codefresh.io/blog/codefresh-upends-continuous-delivery-with-hosted-gitops-platform-featuring-dora-dashboards-and-first-class-integrations-for-ci/). -For detailed information on each of the steps below, see [Set up a hosted runtime environment]({{site.baseurl}}/docs/runtime/hosted-runtime/). - -**Before you begin** - -Verify the following: -* If you have hybrid runtimes installed, make sure you have latest version of the CLI - * Check version: - `cf version` - To compare with the latest version from Codefresh, [click here](https://github.com/codefresh-io/cli-v2/releases){:target="\_blank"}. - * [Download the CLI]({{site.baseurl}}/docs/clients/csdp-cli/). -* Kubernetes cluster with access to the internet -* OAuth token - -**How to** -1. In the Codefresh UI, go to Codefresh [Home](https://g.codefresh.io/2.0/?time=LAST_7_DAYS){:target="\_blank"}. - -{% include -image.html -lightbox="true" -file="/images/runtime/hosted-initial-view.png" -url="/images/runtime/hosted-initial-view.png" -alt="Hosted GitOps setup" -caption="Hosted GitOps setup" -max-width="80%" -%} - -{:start="2"} -1. Provision the hosted runtime: - * Click **Install**, and wait for Codefresh to complete provisioning your hosted runtime (may take up to ten minutes). - -{% include -image.html -lightbox="true" -file="/images/runtime/hosted-installing.png" -url="/images/runtime/hosted-installing.png" -alt="Installing hosted runtime" -caption="Installing hosted runtime" -max-width="80%" -%} - -{:start="3"} -1. Select the Git organization for the runtime installation and shared configuration repos: - * Click **Connect**. - * Click **Authorize Access** and enter your OAuth token. - * Select the **Git Organization for which to create the repos**. - * Click **Create**. - Codefresh creates the two Git repositories in the paths shown. - - {% include -image.html -lightbox="true" -file="/images/runtime/hosted-connect-git.png" -url="/images/runtime/hosted-connect-git.png" -alt="Connect to Git provider" -caption="Connect to Git provider" -max-width="80%" -%} - -{:start="4"} -1. Connect a K8s cluster: - * Click **Connect**. - * In the Add Managed Cluster panel, copy the command `cf cluster add`, and run it in the terminal. - * When prompted to select the `kube-context`, select from the list of available clusters as defined in `kubeconfig`. - * Verify that you have configured access to the required IP addresses required. See [Codefresh IP addresses]({{site.baseurl}}/docs/administration/platform-ip-addresses/). - -{% include -image.html -lightbox="true" -file="/images/runtime/hosted-connect-cluster-step.png" -url="/images/runtime/hosted-connect-cluster-step.png" -alt="Connect a K8s cluster for hosted runtime" -caption="Connect a K8s cluster for hosted runtime" -max-width="70%" -%} - -1. Install Argo Rollouts on the cluster you added. You'll need this to apply the `rollout` resource we will create for the application in the next task. - * Go to [Runtimes](https://g.codefresh.io/2.0/account-settings/runtimes){:target="\_blank"}. - * Select **Topology View**. - * Select the target cluster, and then select **+ Install Argo Rollouts**. - -{% include - image.html - lightbox="true" - file="/images/getting-started/quick-start/cdops-app-install-rollout.png" - url="/images/getting-started/quick-start/cdops-app-install-rollout.png" - alt="Install Argo Rollouts on managed cluster" - caption="Install Argo Rollouts on managed cluster" - max-width="50%" - %} - -### What to do next -[Create resources for codefresh-guestbook application]({{site.baseurl}}/docs/getting-started/quick-start/create-app-specs) - diff --git a/_docs/getting-started/quick-start/runtime.md b/_docs/getting-started/quick-start/runtime.md deleted file mode 100644 index 9ac99d86..00000000 --- a/_docs/getting-started/quick-start/runtime.md +++ /dev/null @@ -1,112 +0,0 @@ ---- -title: "Install a hybrid runtime" -description: "" -group: getting-started -sub-group: quick-start -toc: true ---- - - -Install the hybrid runtime on your K8s cluster. Installing the hybrid runtime installs Argo-project and Codefresh-specific components. The Argo Project is an enterprise-supported version of the Argo CD components, derived from a conformed fork of the Argo ecosystem. - -### About hybrid runtime installation -Installing a hybrid runtime includes installing the: -1. Codefresh CLI. -2. Codefresh hybrid runtime from the CLI in a specific namespace on your cluster. - Every hybrid runtime installation makes commits to two Git repos: - * Runtime installation repo: The installation repo that manages the runtime itself with Argo CD. If the repo URL you provide does not exist, the runtime creates it automatically. - * Git Source repo: Created automatically during runtime installation. The repo with the demo resources required for the sample `Hello World` pipelines we provide. - * Shared configuration repo: A repository that stores configuration manifests shared across runtimes. - -### Before you begin -A hybrid runtime requires a Git token for authentication to the Git installation repository. -Have your GitHub Personal Authentication Token (PAT) ready with a valid expiration date and access permissions: -* Expiration: Either the default of 30 days or any duration you consider logical. -* Access scopes: Set to `repo` and `admin-repo.hook` - - {% 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="GitHub PAT permissions" - caption="GitHub PAT permissions" - max-width="30%" - %} - - If you need detailed information on GitHub tokens, see the [GitHub article](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token). - -### Download the Codefresh CLI -Downloading the Codefresh CLI requires you to select the download mode and OS, generate an API key, and authentication context, as instructed in the UI. -1. In the Welcome page, select **+ Install Runtime**. -1. Download the Codefresh CLI: - * Select one of the methods. - * Generate the API key and create the authentication context. - - {% include - image.html - lightbox="true" - file="/images/getting-started/quick-start/quick-start-download-cli.png" - url="/images/getting-started/quick-start/quick-start-download-cli.png" - alt="Download Codefresh CLI to install runtime" - caption="Download Codefresh CLI to install runtime" - max-width="30%" - %} -### Install hybrid runtime -For the quick start, install the hybrid runtime through the Codefresh CLI that you downloaded previously. - -1. To start runtime installation, run `cf runtime install`. - >If you don't have a valid SSL certificate for the Ingress controller, and want to continue with the installation, add the `--insecure` flag to the runtime command. -1. Follow the prompts in the CLI wizard to complete the installation: - * **Runtime name**: The name of your runtime, starting with a lower-case character, and including up to 63 characters and numbers. Example: `codefreshproduction` - * **Select Kube context**: Your current context is highlighted. Press Enter to select it, or use the arrow keys to select a different context. - * **Ingress class**: Select the ingress class for runtime installation from the list displayed. - * **Ingress host**: Displays the NGINX host, either from the cluster or the NGINX ingress controller associated with the **Ingress class**. - * **Repository URL**: The GitHub repo for the installation definitions, in the format `https://github.com/[user-or-org-name]/[repo_name]`. Example: `https//:github.com/codefresh/cf_production_install` - * **Git runtime token**: The GitHub PAT for access to the installation repo. - * **Install Codefresh demo resources?** Press Enter to confirm. Demo resources are saved in a new Git Source repo, created by Codefresh. They include resources for two Hello World pipelines, one with a Cron trigger condition, and the other with a Git event trigger condition. - * **Do you wish to continue with runtime install?** Press Enter to confirm and start runtime installation. -1. Wait for the runtime installed successfully message. - -### Validate successful installation -The **Runtimes** dashboard shows the hybrid runtime you just installed. You can drill down into the runtime to see its components and Git Sources. - -1. In the Codefresh UI, go to the [**Runtimes**](https://g.codefresh.io/2.0/account-settings/runtimes){:target="\_blank"} dashboard. - - {% include - image.html - lightbox="true" - file="/images/getting-started/quick-start/quick-start-runtime-dashboard.png" - url="/images/getting-started/quick-start/quick-start-runtime-dashboard.png" - alt="Runtime dashboard after successful installation" - caption="Runtime dashboard after successful installation" - max-width="30%" - %} - -{:start="2"} -1. Select the runtime name to drill down, and then select the tabs to view the runtime components and Git Sources. - - {% include - image.html - lightbox="true" - file="/images/getting-started/quick-start/quick-start-runtime-components.png" - url="/images/getting-started/quick-start/quick-start-runtime-components.png" - alt="Runtime components tab" - caption="Runtime Components tab" - max-width="30%" - %} - - {% include - image.html - lightbox="true" - file="/images/getting-started/quick-start/quick-start-git-source.png" - url="/images/getting-started/quick-start/quick-start-git-source.png" - alt="Git Source tab" - caption="Git Source tab" - max-width="30%" - %} - -### What to do next -[Create resources for codefresh-guestbook application]({{site.baseurl}}/docs/getting-started/quick-start/create-app-specs) -OR -[Trigger the Hello World example pipeline]({{site.baseurl}}/docs/getting-started/quick-start/hello-world) diff --git a/_docs/getting-started/quick-start/verify-requirements.md b/_docs/getting-started/quick-start/verify-requirements.md deleted file mode 100644 index 3fc48c3e..00000000 --- a/_docs/getting-started/quick-start/verify-requirements.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: "Prepare for hybrid runtime installation" -description: "" -group: getting-started -sub-group: quick-start -toc: true ---- - - -**New installation** -If this is your first time installing Codefresh, review and confirm that your deployment environment conforms to the minimum requirements for hybrid runtime installation. Check the [system requirements]({{site.baseurl}}/docs/runtime/requirements). - -**Existing installation** -If you already have a hybrid runtime installation on your cluster, you have two options: -1. To install on the same cluster, first uninstall the existing hybrid runtime. Currently, you can install a single hybrid runtime per cluster. -1. Install on a different cluster, verifying that you meet the minimum requirements. - -**Uninstallation tips for existing runtimes** -* Before you run uninstall an existing hybrid runtime from the Codefresh UI, or run `cf runtime uninstall` from the CLI, _delete_ all Codefresh-related namespaces. -* If a namespace is frozen in the `Terminating` status, it could be because the namespace has resources with finalizers that are preventing deletion. - Here's how you can remove finalizers using `k9s`: - * In the `applications` view, do the following for each application: - * Hit `e` to edit the YAML. - * Scroll down to the section entitled `finalizers`. - * Move cursor to the line with the finalizer definition, and then hit `dd` to delete the line. - * Delete also the `finalizers` key. - * To save and exit, hit `escape` `wq:` `enter`. - * Try deleting the namespace again. - -### What to do next -[Install a hybrid runtime]({{site.baseurl}}/docs/getting-started/quick-start/runtime) diff --git a/_docs/incubation/intro-hosted-runtime.md b/_docs/incubation/intro-hosted-runtime.md deleted file mode 100644 index c2a66b69..00000000 --- a/_docs/incubation/intro-hosted-runtime.md +++ /dev/null @@ -1,146 +0,0 @@ ---- -title: "Hosted GitOps" -description: "" -group: incubation -toc: true ---- - - -Codefresh has enhanced our solution offering with Hosted GitOps, the SaaS version of Codefresh. - -What do you get with Hosted GitOps? -In a nutshell, a hosted and managed version of Argo CD. From application analytics, to application creation, rollout, and deployment, you get the best of both worlds: Argo CD with unique features and functionality from Codefresh to help achieve your CD goals. -What it also means is easy set up and zero maintenance overhead. - -Read on for more details. And check out our [blog](https://codefresh.io/blog/codefresh-upends-continuous-delivery-with-hosted-gitops-platform-featuring-dora-dashboards-and-first-class-integrations-for-ci/). - -### Hosted runtimes - -Setting up your hosted environment takes just a few clicks. All you need is a Codefresh account, a Git account, and a Kubernetes cluster to which to deploy your applications. -Codefresh guides you through the simple three-step process of provisioning your hosted runtime. From that point, Codefresh handles administration and maintenance of the hosted runtime, including version and security updates. - -See [Set up a hosted (Hosted GitOps) environment]({{site.baseurl}}/docs/runtime/hosted-runtime/). - -{% include - image.html - lightbox="true" - file="/images/runtime/intro-hosted-hosted-initial-view.png" - url="/images/runtime/intro-hosted-hosted-initial-view.png" - alt="Hosted runtime setup" - caption="Hosted runtime setup" - max-width="80%" -%} - -### Global deployment analytics - -The Home dashboard presents enterprise-wide deployment highlights, making it a useful management tool. - -Get insights into important KPIs and deployments, across runtimes and clusters, all in the same location. View status of runtimes and managed clusters, deployments, failed deployments with rollbacks, most active applications. Use filters to narrow the scope to focus on anything specific. - -{% include - image.html - lightbox="true" - file="/images/incubation/home-dashboard.png" - url="/images/incubation/home-dashboard.png" - alt="Global deployment analytics" - caption="Global deployment analytics" - max-width="80%" -%} - -### Application analytics and analysis - -The Applications dashboard displays applications across runtimes and clusters, from which you can select and analyze individual applications. Individual application information is grouped by current and historical deployments, enriched with Argo, Jira, and Git details, including rollout visualizations for ongoing deployments (Timeline tab), and an interactive tree view of application resources (Current State tab). - -See [Monitoring applications]({{site.baseurl}}/docs/deployment/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="Applications dashboard" - max-width="80%" -%} - -### DORA metrics - -DORA metrics has become integral to enterprises wanting to quantify DevOps performance, and Codefresh has out-of-the-box support for it. - -Apart from the metrics themselves, the DORA dashboard in Codefresh has several features such as the Totals bar with key metrics, filters that allow you to pinpoint just which applications or runtimes are contributing to problematic metrics, and the ability to set a different view granularity for each DORA metric. - -See [DORA metrics]({{site.baseurl}}/docs/reporting/dora-metrics/). - -{% include - image.html - lightbox="true" - file="/images/incubation/intro-dora-metrics.png" - url="/images/incubation/intro-dora-metrics.png" - alt="DORA metrics" - caption="DORA metrics" - max-width="60%" -%} - -### Application management - -Manage the application lifecycle in the Codefresh UI, from creating, editing, and deleting them. - -Define all application settings in a single location through the intuitive Form mode or directly in YAML, and commit all changes to Git. -For easy access, the configuration settings are available for editing in the Applications dashboard. - -See [Applications]({{site.baseurl}}/docs/deployment/create-application/). - -{% include - image.html - lightbox="true" - file="/images/applications/add-app-general-settings.png" - url="/images/applications/add-app-general-settings.png" - alt="Application creation in Codefresh" - caption="Application creation in Codefresh" - max-width="60%" -%} - -### Third-party CI integrations - -If you have your own tools for CI pipelines and workflows, Hosted GitOps gives you the option to connect them to Codefresh and enrich deployment information with our new report image template. For example, you can add the report image step in your GitHub Actions pipeline and reference the different integrations for Codefresh to retrieve and enrich the image information. - -* Git PRs (Pull Requests), Commits, and Committer information directly from the code repositories -* Jira ticket information for correlation with deployed features -* Docker Hub or Quay for image information - -See [Image enrichment with integrations]({{site.baseurl}}/docs/integrations/image-enrichment-overview/). - -{% include - image.html - lightbox="true" - file="/images/incubation/github-action-int-settings.png" - url="/images/incubation/github-action-int-settings.png" - alt="Image enrichment with GitHub Actions integration" - caption="Image enrichment with GitHub Actions integration" - max-width="60%" -%} - -### Hosted vs. hybrid environments - -The table below highlights the main differences between hosted and hybrid environments. - -{: .table .table-bordered .table-hover} -| Functionality |Feature | Hosted | Hybrid | -| -------------- | --------------|--------------- | --------------- | -| Runtime | Installation | Provisioned by Codefresh | Provisioned by customer | -| | Runtime cluster |Managed by Codefresh | Managed by customer | -| | Number per account | Only one runtime | Multiple runtimes | -| | Upgrade | Managed by Codefresh | Managed by customer | -| | External cluster | Managed by customer | Managed by customer | -| | Uninstall | Managed by customer | Managed by customer | -| Argo CD | | Codefresh cluster | Customer cluster | -| CI Ops | Delivery Pipelines |Not supported | Supported | -| |Workflows | Not supported | Supported | -| |Workflow Templates | Not supported | Supported | -| CD Ops |Applications | Supported | Supported | -| |Image enrichment | Supported | Supported | -| | Rollouts | Supported | Supported | -|Integrations | | Supported | Supported | -|Dashboards |Home Analytics | Hosted runtime and deployments|Runtimes, deployments, Delivery Pipelines | -| |DORA metrics | Supported |Supported | -| |Applications | Supported |Supported | diff --git a/_docs/integrations/ci-integrations.md b/_docs/integrations/ci-integrations.md deleted file mode 100644 index f43ad8e4..00000000 --- a/_docs/integrations/ci-integrations.md +++ /dev/null @@ -1,107 +0,0 @@ ---- -title: "CI integrations" -description: "" -group: integrations -toc: true ---- - -Use Codefresh's Hosted GitOps with any popular Continuous Integration (CI) solution, not just with Codefresh CI. - -You can connect a third-party CI solution to Codefresh, such as GitHub Actions for example, to take care of common CI tasks such as building/testing/scanning source code, and have Codefresh Hosted GitOps still responsible for the deployment, including image enrichment and reporting. -The integration brings in all the CI information to your images which you can see in the Images dashboard. - -See [Image enrichment with integrations]({{site.baseurl}}/docs/integrations/image-enrichment-overview/). - -### Codefresh image reporting and enrichment action -To support the integration between Codefresh and third-party CI platforms and tools, we have created dedicated actions for supported CI tools in the Codefresh Marketplace. These actions combine image enrichment and reporting through integrations with issue tracking and container registry tools. - ->You can also configure the integration directly in the Codefresh UI, as described in [Connect a third-party CI platform/tool to Codefresh](#connect-a-third-party-ci-platformtool-to-codefresh). - - -Use the action as follows: - -1. Create your pipeline with your CI platform/tool as you usually do. -1. Use existing CI actions for compiling code, running unit tests, security scanning etc. -1. Place the final action in the pipeline as the "report image" action provided by Codefresh. - See: - [GitHub Action Codefresh report image](https://github.com/marketplace/actions/codefresh-report-image){:target="\_blank"} - [Codefresh Classic Codefresh report image](https://codefresh.io/steps/step/codefresh-report-image){:target="\_blank"} -1. When the pipeline completes execution, Codefresh retrieves the information on the image that was built and its metadata through the integration names specified (essentially the same data that Codefresh CI would send automatically). -1. View the image in Codefresh's [Images dashboard]({{site.baseurl}}/docs/deployment/images/), and in any [application]({{site.baseurl}}/docs/deployment/applications-dashboard/) in which it is used. - -### Connect a third-party CI platform/tool to Codefresh -Connecting the CI platform/tool to Codefresh from the UI includes configuring the required arguments, and then generating and copying the YAML manifest for the report image to your pipeline. - -1. In the Codefresh UI, go to [Integrations](https://g.codefresh.io/2.0/account-settings/integrations){:target="\_blank"}. -1. Filter by **CI tools**, then select the CI tool and click **Add**. -1. Define the arguments for the CI tool: - [Codefresh Classic]({{site.baseurl}}/docs/integrations/ci-integrations/codefresh-classic/) - [GitHub Action]({{site.baseurl}}/docs/integrations/ci-integrations/github-actions/) - [Jenkins]({{site.baseurl}}/docs/integrations/ci-integrations/jenkins/) - - For the complete list of arguments you can use, see [CI integration argument reference](#ci-integration-argument-reference) in this article. - -1. To generate a YAML snippet with the arguments, on the top-right, click **Generate Manifest**. - Codefresh validates the generated manifest, and alerts you to undefined arguments that are required, and other errors. - - {% include image.html -lightbox="true" -file="/images/integrations/generated-manifest-with-error.png" -url="/images/integrations/generated-manifest-with-error.png" -alt="Example of manifest generated for Codefresh Classic with validation errors" -caption="Example of manifest generated for Codefresh Classic with validation errors" -max-width="50%" -%} - -{:start="5"} -1. If required, click **Close**, update as needed and generate the manifest again. -1. If there are no validation errors, click **Copy**. - -{% include image.html -lightbox="true" -file="/images/integrations/classic/classic-manifest.png" -url="/images/integrationsclassic/classic-manifest.png" -alt="Example of manifest generated for Codefresh Classic" -caption="Example of manifest generated for Codefresh Classic" -max-width="50%" -%} - -{:start="6"} -1. Paste the copied manifest as the last step in your CI pipeline. - -### CI integration argument reference -The table describes _all_ the arguments required for CI integrations in general. The actual arguments required, differs according to the CI integration tool. - -{: .table .table-bordered .table-hover} -| Argument | Description | Required/Optional/Default | -| ---------- | -------- | ------------------------- | -| `CF_HOST` | _Deprecated from v 0.0.460 and higher._ Recommend using `CF_RUNTIME_NAME` instead. {::nomarkdown}
CF_HOST has been deprecated because the URL is not static, and any change can fail the enrichment.
The URL to the cluster with the Codefresh runtime to integrate with. If you have more than one runtime, select the runtime from the list. Codefresh displays the URL of the selected runtime cluster.{:/} | _Deprecated_ | -| `CF_RUNTIME_NAME` | The runtime to use for the integration. If you have more than one runtime, select the runtime from the list. | Required | -| `CF_PLATFORM_URL` | The root URL of the Codefresh application. The default value is `https://g.codefresh.io`. | Optional | -| `CF_API_KEY` | The API key for authentication. Generate the key for the integration. | Required | -| `CF_CONTAINER_REGISTRY_INTEGRATION` | The name of the container registry integration created in Codefresh where the image is stored. See [Container registry integrations]({{site.baseurl}}/docs/integrations/container-registries/). | Optional | -| `CF_JIRA_INTEGRATION` | _Deprecated from version 0.0.565 and higher._ Replaced by `CF_ISSUE_TRACKING_INTEGRATION`. | _Deprecated_ -| `CF_ISSUE_TRACKING_INTEGRATION` | The name of the issue tracking integration created in Codefresh to use for image enrichment. Relevant only if Jira enrichment is required for the image. If you don't have a Jira integration, click **Create Atlassian Jira Integration** and configure settings. See [Jira integration]({{site.baseurl}}/docs/integrations/issue-tracking/jira/). | Optional | -| `CF_IMAGE` | The image to be enriched and reported in Codefresh. Pass the `[account-name]/[image-name]:[tag]` built in your CI. | Required | -| `CF_WORKFLOW_NAME` | The name assigned to the workflow that builds the image. When defined, the name is displayed in the Codefresh platform. Example, `Staging step` | Optional | -| `CF_GIT_BRANCH` | The Git branch with the commit and PR (pull request) data to add to the image. Pass the Branch from the event payload used to trigger your action. | Required | -| `CF_GIT_REPO` | The Git repository with the configuration and code used to build the image. {::nomarkdown}- Optional for GitHub Actions.
- Required for Classic and Jenkins.
- Optional when you don't define other related Git provider arguments. When not defined, Codefresh retrieves the required information from the runtime selected for the integration.
- Required when you define at least one of the Git provider arguments. For example, when you define CF_GITLAB_TOKEN, then you must define all Git provider arguments, in this case, CF_GIT_PROVIDER as gitlab, and CF_GITLAB_HOST_URL.
- Optional when you don't define any GitLab-specific arguments. When not defined, Codefresh retrieves the required information from the runtime selected for the integration.
- Required when you define at least one of the GitLab-specific arguments, such as CF_GIT_PROVIDER as gitlab, or CF_GITLAB_HOST_URL.
- Optional when you don't define other related GitLab-specific arguments. When not defined, Codefresh retrieves the required information from the runtime selected for the integration.
- Required when you define at least one of the GitLab-specific arguments, such as CF_GIT_PROVIDER as gitlab, or CF_GITLAB_TOKEN.
- Optional when you don't define other related Bitbucket-specific arguments. When not defined, Codefresh retrieves the required information from the runtime selected for the integration.
- Required when you define at least one of the Bitbucket-specific arguments, such as CF_GIT_PROVIDER as bitbucket, CF_BITBUCKET_PASSWORD or CF_BITBUCKET_HOST_URL.
- Optional when you don't define other related Bitbucket-specific arguments. When not defined, Codefresh retrieves the required information from the runtime selected for the integration.
- Required when you define at least one of the Bitbucket-specific arguments, such as CF_GIT_PROVIDER as bitbucket, CF_BITBUCKET_USERNAME, or CF_BITBUCKET_HOST_URL.
- Optional when you don't define other related Bitbucket Server-specific arguments. When not defined, Codefresh retrieves the required information from the runtime selected for the integration.
- Required when you define at least one of the Bitbucket Server-specific arguments, such as CF_GIT_PROVIDER as bitbucket, CF_BITBUCKET_USERNAME or CF_BITBUCKET_PASSWORD.
- Optional when you don't define other related Git provider arguments. When not defined, Codefresh retrieves the required information from the runtime selected for the integration.
- Required when you define at least one of the Git provider arguments. For example, when you define CF_GITLAB_TOKEN, then you must define all Git provider arguments, in this case, CF_GIT_PROVIDER as gitlab, and CF_GITLAB_HOST_URL.
- Optional when you don't define any GitLab-specific arguments. When not defined, Codefresh retrieves the required information from the runtime selected for the integration.
- Required when you define at least one of the GitLab-specific arguments, such as CF_GIT_PROVIDER as gitlab, or CF_GITLAB_HOST_URL.
- Optional when you don't define other related GitLab-specific arguments. When not defined, Codefresh retrieves the required information from the runtime selected for the integration.
- Required when you define at least one of the GitLab-specific arguments, such as CF_GIT_PROVIDER as gitlab, or CF_GITLAB_TOKEN.
- Optional when you don't define other related Bitbucket-specific arguments. When not defined, Codefresh retrieves the required information from the runtime selected for the integration.
- Required when you define at least one of the Bitbucket-specific arguments, such as CF_GIT_PROVIDER as bitbucket, CF_BITBUCKET_PASSWORD or CF_BITBUCKET_HOST_URL.
- Optional when you don't define other related Bitbucket-specific arguments. When not defined, Codefresh retrieves the required information from the runtime selected for the integration.
- Required when you define at least one of the Bitbucket-specific arguments, such as CF_GIT_PROVIDER as bitbucket, CF_BITBUCKET_USERNAME, or CF_BITBUCKET_HOST_URL.
- Optional when you don't define other related Bitbucket Server-specific arguments. When not defined, Codefresh retrieves the required information from the runtime selected for the integration.
- Required when you define at least one of the Bitbucket Server-specific arguments, such as CF_GIT_PROVIDER as bitbucket, CF_BITBUCKET_USERNAME or CF_BITBUCKET_PASSWORD.
- For a GitHub Container registry, select GHCR_GITHUB_TOKEN_AUTHENTICATION even if you have not created an integration in Codefresh.
Codefresh retrieves and provides the explicit credentials for the container registry on generating the integration manifest. - To create a container registry integration if you don't have one, click Create Container Registry Integration, and then configure the settings.
See Container registry integrations. - Optional when you don't define other related Git provider arguments. When not defined, Codefresh retrieves the required information from the runtime selected for the integration.
- Required when you define at least one of the Git provider arguments. For example, when you define CF_GITLAB_TOKEN, then you _must_ define all Git provider arguments, in this case, CF_GIT_PROVIDER as gitlab, and CF_GITLAB_HOST_URL.
- Optional when you don't define any GitLab-specific arguments. When not defined, Codefresh retrieves the required information from the runtime selected for the integration.
- Required when you define at least one of the GitLab-specific arguments, such as CF_GIT_PROVIDER as gitlab, or CF_GITLAB_HOST_URL.
- Optional when you don't define other related GitLab-specific arguments. When not defined, Codefresh retrieves the required information from the runtime selected for the integration.
- Required if you define at least one of the GitLab-specific arguments, such as CF_GIT_PROVIDER as gitlab, or CF_GITLAB_TOKEN.
- Optional when you don't define other related Bitbucket-specific arguments. When not defined, Codefresh retrieves the required information from the runtime selected for the integration.
- Required when you define at least one of the Bitbucket-specific arguments, such as CF_GIT_PROVIDER as bitbucket, CF_BITBUCKET_PASSWORD or CF_BITBUCKET_HOST_URL.
- Optional when you don't define other related Bitbucket-specific arguments. When not defined, Codefresh retrieves the required information from the runtime selected for the integration.
- Required when you define at least one of the Bitbucket-specific arguments, such as CF_GIT_PROVIDER as bitbucket, CF_BITBUCKET_USERNAME, or CF_BITBUCKET_HOST_URL.
- Optional when you don't define other related Bitbucket Server-specific arguments. When not defined, Codefresh retrieves the required information from the runtime selected for the integration.
- Required when you define at least one of the Bitbucket Server-specific arguments, such as CF_GIT_PROVIDER as bitbucket, CF_BITBUCKET_USERNAME or CF_BITBUCKET_PASSWORD.
- All runtimes: Created in resources/all-runtimes-all-clusters/
- Selected runtimes: Created in resources/runtimes/
/ - All runtimes: Created in resources/all-runtimes-all-clusters/
- Selected runtimes: Created in resources/runtimes/
/ - All runtimes: Created in resources/all-runtimes-all-clusters/
- Selected runtimes: Created in resources/runtimes/
/ - All runtimes: Created in resources/all-runtimes-all-clusters/
- Selected runtimes: Created in resources/runtimes/
/ - All runtimes: Created in resources/all-runtimes-all-clusters/
- Selected runtimes: Created in resources/runtimes/
/ - All runtimes: Created in resources/all-runtimes-all-clusters/
- Selected runtimes: Created in resources/runtimes/
/ - Status: One of the following:
- Connected: Argo CD is able to connect and successfully deploy resources to the cluster.
- Failed: Argo CD is unable to connect to the cluster because of authentication, networking, or other issues.
- Unknown: Argo CD has no information on the cluster as there are no resources deployed to the managed cluster.
- View: Click to go to the Runtimes page.
To see the runtime's managed clusters, select the runtime. - Healthy (green): The application is running on the cluster.
- Degraded (red): The application failed to run.
- Rollback (yellow): There was a rollback to the previously deployed version.
- Status:
- 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.
- 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.
- {:/} | Required |
-| `CF_GIT_PROVIDER` | The Git provider for the integration, and can be either `github`, `gitlab`, or `bitbucket`. {::nomarkdown}
- {:/}| Optional |
-| `CF_GITLAB_TOKEN` | The token to authenticate the GitLab account. {::nomarkdown}
- {:/} | Optional |
-| `CF_GITLAB_HOST_URL` | The URL address of your GitLab Cloud/Server instance. {::nomarkdown}
- {:/} | Optional |
-| `CF_BITBUCKET_USERNAME` | The username for the Bitbucket or the Bitbucket Server (on-prem) account. {::nomarkdown}
- {:/}| Optional |
-| `CF_BITBUCKET_PASSWORD` | The password for the Bitbucket or the BitBucket Server (on-prem) account. {::nomarkdown}
- {:/}| Optional |
-| `CF_BITBUCKET_HOST_URL` | Relevant for Bitbucket Server accounts only. The URL address of your Bitbucket Server instance. Example, `https://bitbucket-server:7990`. {::nomarkdown}
- {:/}| Optional |
-| `CF_GITLAB_TOKEN` | The token to authenticate the GitLab account. {::nomarkdown}
- {:/} | Optional |
-| `CF_GITLAB_HOST_URL` | The URL address of your GitLab Cloud/Server instance. {::nomarkdown}
- {:/} | Optional |
-| `CF_BITBUCKET_USERNAME` | The username for the Bitbucket or the Bitbucket Server (on-prem) account. {::nomarkdown}
- {:/}| Optional |
-| `CF_BITBUCKET_PASSWORD` | The password for the Bitbucket or the Bitbucket Server (on-prem) account. {::nomarkdown}
- {:/}| Optional |
-| `CF_BITBUCKET_HOST_URL` | Relevant for Bitbucket Server accounts only. The URL address of your Bitbucket Server instance. Example, `https://bitbucket-server:7990`. {::nomarkdown}
-{:/} - -#### CF_IMAGE examples -**Example: Report full repo and branch information** -This example illustrates how to define the value for `CF_IMAGE` to report the repo owner, name, and branch, with the Git hash. - - Value: - {% raw %}`${{CF_REPO_OWNER}}/${{CF_REPO_NAME}}:${{CF_BRANCH_TAG_NORMALIZED}}-${{CF_SHORT_REVISION}}`{% endraw %} - - where: - * {% raw %}`${{CF_REPO_OWNER}}`{% endraw %} reports the owner of the repository. For example, `nr-codefresh`. - * {% raw %}`${{CF_REPO_NAME}}`{% endraw %} reports the name of the repository. For example, `codefresh-production`. - * {% raw %}`${{CF_BRANCH_TAG_NORMALIZED}}`{% endraw %} reports the normalized version of the branch name, without invalid characters in case the branch name is the Docker image tag name. For example, `pr-2345`, `new-auth-strategy` (branch names without normalization required), and `gcr.io/codefresh-inc/codefresh-io/argo-platform-audit.1.1909.0` (normalized version of original branch name `gcr.io/codefresh-inc/codefresh-io/argo-platform-audit:1.1909.0`). - * {% raw %}`${{CF_SHORT_REVISION}}`{% endraw %} reports the abbreviated 7-character revision hash, as used in Git. For example, `40659e7`. - -**Example: Report a specific image tag** -This example illustrates how to define the value for `CF_IMAGE` value when you know the specific image version you want to report. - - Value: - {% raw %}`{{CF_REPO_OWNER}}/${{CF_REPO_NAME}}:` {% endraw %} - - where: - * {% raw %}`${{CF_REPO_OWNER}}`{% endraw %} and {% raw %}`${{CF_REPO_NAME}}`{% endraw %} report the names of the repository owner and the repository, respectively. For example, `nr-codefresh` and `codefresh-production`, respectively. - * {% raw %}` `{% endraw %} reports the hard-coded tag `v1.0`. - -**Example: Report the latest Git tag available on repository** -This example illustrates how to define the value for `CF_IMAGE` value to report the latest Git tag on the repository. - -Value: -{% raw %}`codefresh/${{CF_REPO_NAME}}:latest`{% endraw %} - -where: -* {% raw %}`codefresh`{% endraw %} is the hard-coded owner of the image. -* {% raw %}`${{CF_REPO_NAME}}`{% endraw %} reports the name of the repository that triggered the pipeline. For example, `codefresh-production`. -* {% raw %}`latest`{% endraw %} reports the latest Git tag available for the repository defined by {% raw %}`${{CF_REPO_NAME}}`{% endraw %}. For example, `v1.0.4-14-g2414721`. - -{::nomarkdown} -
-{:/} - -#### CF_GIT_BRANCH examples - -**Example: Report Git branch or tag with committer and commit message** - -This example illustrates how to report the name or tag of the Git branch with committer and commit message. - - Value: - {% raw %}`${{CF_REPO_NAME}}/${{CF_BRANCH}}:${{CF_COMMIT_AUTHOR}}/${{CF_COMMIT_MESSAGE}}`{% endraw %} - - where: - * {% raw %}`${{CF_REPO_NAME}}`{% endraw %} reports the name of the repository. For example, `codefresh-production`. - * {% raw %}`${{CF_BRANCH}}`{% endraw %} reports the branch name or tag based on the JSON payload of the Git repository that triggered the pipeline. For example, `new-auth-strategy`. - * {% raw %}`${{CF_COMMIT_AUTHOR}}`{% endraw %} reports the name of the user who made the commit. For example, `cf-support`. - * {% raw %}`${{CF_COMMIT_MESSAGE}}`{% endraw %} reports the commit message of the repository. For example, `support oauth authentication for ci integrations`. - - -**Example: Report normalized Git branch or tag with committer and commit message** - -This example illustrates how to report the normalized name or tag of the Git branch with committer and commit message. -Normalizing the branch name removes any invalid characters in the name if the branch name is also used as the Docker image tag name. - - Value: - - {% raw %}`${{CF_REPO_NAME}}/${{CF_BRANCH_TAG_NORMALIZED}}:${{CF_COMMIT_AUTHOR}}/${{CF_COMMIT_MESSAGE}}`{% endraw %} - - where: - * {% raw %}`${{CF_REPO_NAME}}`{% endraw %} reports the name of the repository. For example, `codefresh-production`. - * {% raw %}`${{CF_BRANCH_TAG_NORMALIZED}}`{% endraw %} reports the normalized version of the branch name or tag based on the JSON payload of the Git repository that triggered the pipeline. - * {% raw %}`${{CF_COMMIT_AUTHOR}}`{% endraw %} reports the name of the user who made the commit. For example, `nr-codefresh`. - * {% raw %}`${{CF_COMMIT_MESSAGE}}`{% endraw %}reports the commit message of the repository. For example, `support oauth authentication for ci integrations`. - -**Example: Report normalized Git branch or tag in lowercase with PR information** - -This example illustrates how to report the normalized name or tag of the Git branch in lowercase, with PR (pull request) information. -Normalizing the branch name removes any invalid characters in the name if the branch name is also used as the Docker image tag name. - -Value: - {% raw %}`${{CF_REPO_NAME}}/${{CF_BRANCH_TAG_NORMALIZED}}:${{CF_PULL_REQUEST_TARGET}}/${{CF_PULL_REQUEST_NUMBER}}`{% endraw %} - - where: - * {% raw %}`${{CF_REPO_NAME}}`{% endraw %} reports the name of the repository. For example, `production`. - * {% raw %}`${{CF_BRANCH_TAG_NORMALIZED}}`{% endraw %} reports the normalized version of the branch name or tag based on the JSON payload of the Git repository that triggered the pipeline. For example, `pr-2345`, `new-auth-strategy` (branch names without normalization required), and `gcr.io/codefresh-inc/codefresh-io/argo-platform-audit.1.1909.0` (normalized version of original branch name `gcr.io/codefresh-inc/codefresh-io/argo-platform-audit:1.1909.0`). - * {% raw %}`${{CF_PULL_REQUEST_TARGET}}`{% endraw %} reports the target branch of the PR. For example, `new-auth-strategy`. - * {% raw %}`${{CF_PULL_REQUEST_NUMBER}}`{% endraw %} reports the number of the PR. For example, `#323`. - -{::nomarkdown} -
-{:/} - -#### CF_JIRA_MESSAGE examples -The Jira message represents an existing Jira issue, and must be a literal string. - - Value: - `CR-1246` - -### Codefresh Classic integration logs -View and analyze logs for Codefresh Classic workflows through the Logs tab. When a Codefresh Classic pipeline is run, it is added to the Logs tab. -You can: -* Filter by status or by date range to view a subset of actions -* Navigate to the build file in Codefresh Classic, and view the Codefresh report image step - -{% include image.html -lightbox="true" -file="/images/integrations/classic/classic-logs-tab.png" -url="/images/integrations/classic/classic-logs-tab.png" -alt="Codefresh Classic: Logs tab" -caption="Codefresh Classic: Logs tab" -max-width="50%" -%} - -**Build in Codefresh Classic** - -The Run column includes the link to the pipeline in Codefresh Classic. - -Here is an example of the pipeline build in Codefresh Classic with the Enrich image for CSDP step (top) and the log (down). - -{% include image.html -lightbox="true" -file="/images/integrations/classic/classic-pipeline-enrich-step.png" -url="/images/integrations/classic/classic-pipeline-enrich-step.png" -alt="Codefresh Classic pipeline with Codefresh enrich image step" -caption="Codefresh Classic pipeline with Codefresh enrich image step" -max-width="50%" -%} - -{% include image.html -lightbox="true" -file="/images/integrations/classic/classic-logs.png" -url="/images/integrations/classic/classic-logs.png" -alt="Logs for Codefresh report image step in Codefresh Classic build" -caption="Logs for Codefresh report image step in Codefresh Classic build" -max-width="50%" -%} - -### Related articles -[Shared configuration repo]({{site.baseurl}}/docs/reference/shared-configuration/) -[Image enrichment with integrations]({{site.baseurl}}/docs/integrations/image-enrichment-overview/) -[Container registry integrations]({{site.baseurl}}/docs/integrations/container-registries/) -[Issue-tracking integrations]({{site.baseurl}}/docs/integrations/issue-tracking/) \ No newline at end of file diff --git a/_docs/integrations/ci-integrations/github-actions.md b/_docs/integrations/ci-integrations/github-actions.md deleted file mode 100644 index fa6dd1c8..00000000 --- a/_docs/integrations/ci-integrations/github-actions.md +++ /dev/null @@ -1,258 +0,0 @@ ---- -title: "GitHub Actions" -description: "" -group: integrations -sub_group: ci-integrations -toc: true ---- - -Use Codefresh Hosted GitOps with any popular Continuous Integration (CI) solution, not just with Codefresh CI. -GitHub Actions is one of the third-party CI solutions that you can connect to Codefresh for deployment with image reporting and enrichment. - - Connecting a GitHub Action, adds the CI information to images which are displayed in the Images dashboard, as in the example below. - - {% include - image.html - lightbox="true" - file="/images/integrations/images-dashboard.png" - url="/images/integrations/images-dashboard.png" - alt="Images dashboard with enriched image information" - caption="Images dashboard with enriched image information" - max-width="70%" - %} - -For information on how to use the image reporting action in your GitHub Action pipeline and how to configure the integration, see [CI Integrations]({{site.baseurl}}/docs/integrations/ci-integrations/). - - -### Example of GitHub Actions pipeline with Codefresh report image action - - -Here is an example pipeline that uses GitHub Actions to build a container image, and the Codefresh action to enrich and report the resulting image to Codefresh. - -Because a Jira integration account is configured in Codefresh, the step needs only the name for `CF_JIRA_INTEGRATION`, instead of explicit credentials `CF_JIRA_API_TOKEN`, `CF_JIRA_HOST_URL`, and `CF_JIRA_EMAIL`. - - -{% highlight yaml %} -{% raw %} - -name: Docker Image CI - -on: - push: - branches: [ main ] - pull_request: - branches: [ main ] -jobs: - build: - environment: - name: test - runs-on: ubuntu-latest - steps: - - name: Checkout - uses: actions/checkout@v3 - - name: Login to DockerHub - uses: docker/login-action@v2 - with: - username: ${{ secrets.DOCKERHUB_USERNAME }} - password: ${{ secrets.DOCKERHUB_TOKEN }} - - name: Build & push the Docker image - env: - CF_IMAGE: ${{ secrets.DOCKERHUB_USERNAME }}/build-by-github-action:0.0.1 - run: | - docker build . --file Dockerfile --tag $CF_IMAGE && docker push $CF_IMAGE - echo "Image should be accessible to your local machine (after docker login) by:" - echo "docker pull $CF_IMAGE" - docker pull $CF_IMAGE - echo "On the next step, the report image would use the integration to pull information on the reported image, using the specified enrichers." - - name: report image by action - with: - # Name of runtime to implement the enrichment - CF_RUNTIME_NAME: 'codefresh-hosted' - - # Codefresh API key !! Committing a plain text token is a security risk. We highly recommend using encrypted secrets. !! - # Documentation - https://docs.github.com/en/actions/security-guides/encrypted-secrets - CF_API_KEY: ${{ secrets.USER_TOKEN }} - - # Name of Container registry integration - CF_CONTAINER_REGISTRY_INTEGRATION: 'docker' - - # The git branch which is related for the commit - CF_GIT_BRANCH: 'main' - - # Image path to enrich - CF_IMAGE: ${{ secrets.DOCKERHUB_USERNAME }}/build-by-github-action:0.0.1 - - # GitHub Access token !! Committing a plain text token is a security risk. We highly recommend using encrypted secrets. !! - # Documentation - https://docs.github.com/en/actions/security-guides/encrypted-secrets - CF_GITHUB_TOKEN: ${{ secrets.CF_GITHUB_TOKEN }} - - # Name of Jira integration - CF_ISSUE_TRACKING_INTEGRATION: 'jira' - - # String starting with the issue ID to associate with image - CF_JIRA_MESSAGE: 'CR-11027' - - # Jira project filter - CF_JIRA_PROJECT_PREFIX: "CR" - uses: codefresh-io/codefresh-report-image@latest - - -{% endraw %} -{% endhighlight yaml %} - -### GitHub Action-Codefresh integration arguments -The table describes the arguments required to connect a GitHub Action to Codefresh. - - - {: .table .table-bordered .table-hover} -| Argument | Description | Required/Optional/Default | -| ---------- | -------- | ------------------------- | -| `CF_HOST` | _Deprecated from v 0.0.460 and higher._ Recommend using `CF_RUNTIME_NAME` instead. {::nomarkdown}
CF_HOST has been deprecated because the URL is not static, and any change can fail the enrichment.
The URL to the cluster with the Codefresh runtime to integrate with. If you have more than one runtime, select the runtime from the list. Codefresh displays the URL of the selected runtime cluster.{:/} | Required | -| `CF_RUNTIME_NAME` | The runtime to use for the integration. If you have more than one runtime, select the runtime from the list. | Required | -| `CF_PLATFORM_URL` | The root URL of the Codefresh application. The default value is `https://g.codefresh.io`. | Optional | -| `CF_API_KEY` | The API key to authenticate the GitHub Actions user to Codefresh. Generate the key for the GitHub Action. {::nomarkdown}
Enter this token in GitHub Actions as a secret with the name CF_API_KEY. You can then reference it in all GitHub pipelines as you would any other secret.{:/}| Required | -| `CF_CONTAINER_REGISTRY_INTEGRATION` | The name of the container registry integration created in Codefresh where the image is stored. {::nomarkdown}
-{:/} - -#### CF_IMAGE - -**Example: Report full repo and branch information** -This example illustrates how to define the value for `CF_IMAGE` to report the repo owner, name, and short branch, with the Git hash. - - Value: - {% raw %}`${{ github.repository }}/${{ github.ref_name }}/${{ github.sha }}`{% endraw %} - - where: - * {% raw %}`${{ github.repository }}`{% endraw %} reports the owner of the repository and the name of the repository. For example, `nr-codefresh/codefresh-production`. - * {% raw %}`${{ github.ref_name }}`{% endraw %} reports the short reference to the branch that triggered the workflow. For example, `auth-feature-branch`. - * {% raw %}`${{ github.sha }}`{% endraw %} reports the complete commit SHA that triggered the workflow. For example, `fa53bfa91df14c4c9f46e628a65ee21dd574490a`. - - - -**Example: Report a specific image tag** -This example illustrates how to define the value for `CF_IMAGE` when you know the specific image version you want to report. - -Value: -{% raw %}`${{ github.repository }}:`{% endraw %} - -where: -* {% raw %}`${{ github.repository }}`{% endraw %} reports the owner of the repository and the name of the repository. For example, `nr-codefresh/codefresh-production`. -* ` ` reports the hard-coded tag `v1.0`. - - -**Example: Report the latest Git tag available on repository** -This example illustrates how to define the value for `CF_IMAGE` to report the latest Git tag on the repository. - -Value: -{% raw %}`codefresh/${{ github.repository }}/latest`{% endraw %} - -where: -* {% raw %}`codefresh`{% endraw %} is the hard-coded owner of the image. -* {% raw %}`${{ github.repository }}`{% endraw %} reports the owner of the repository and the name of the repository. For example, `nr-codefresh/codefresh-production`. -* {% raw %}`latest`{% endraw %} reports the latest Git tag available for the repository defined by {% raw %}`${{ github.repository }}`{% endraw %}. For example, `v1.0.4-14-g2414721`. - -{::nomarkdown} -
-{:/} - -#### CF_GIT_BRANCH - -**Example: Report fully-formed reference of the branch or tag** -This example illustrates how to define the value for `CF_GIT_BRANCH` to report the fully-formed reference of the branch or tag that triggered the workflow run. -For workflows triggered by push events, this is the branch or tag ref that was pushed. -For workflows triggered by pull_requests, this is the pull request merge branch. - -Value: -{% raw %}`${{ github.ref }}`{% endraw %} - -where: -* {% raw %}`${{ github.ref }}`{% endraw %} is the reference to the branch or tag. For example, `refs/heads/auth-feature-branch` (branch), and `refs/pull/#843/merge` (pull request). - -**Example: Report short reference name of the branch or tag** -This example illustrates how to define the value for `CF_GIT_BRANCH` to report only the name of the branch or tag that triggered the workflow run. - - -Value: -{% raw %}`${{ github.ref-name }}`{% endraw %} - -where: -* {% raw %}`${{ github.ref-name }}`{% endraw %} is the name of the target branch or tag. For example, `auth-feature-branch`. - -{::nomarkdown} -
-{:/} - -#### CF_JIRA_MESSAGE -The Jira message represents an existing Jira issue, and must be a literal string. - - Value: - `CR-1246` - -### GitHub Action logs -View and analyze logs for GitHub Action workflows through the Logs tab. When a GitHub Action is run, it is added to the Logs tab. -You can: -* Filter by status or by date range to view a subset of actions -* Navigate to the build file in GitHub Actions, and view the Codefresh report image step - -{% include image.html -lightbox="true" -file="/images/integrations/github-actions/github-actions-logs.png" -url="/images/integrations/github-actions/github-actions-logs.png" -alt="GitHub Action: Logs tab" -caption="GitHub Action: Logs tab" -max-width="50%" -%} - -**Build YAML in GitHub Action** - -The Run column includes the link to the build files for the actions. - -Here are examples of the build file for the GitHub Action (top) and of the Codefresh report image step in the action (down). - -{% include image.html -lightbox="true" -file="/images/integrations/github-actions/action-build-yaml.png" -url="/images/integrations/github-actions/action-build-yaml.png" -alt="Build file in GitHub Action" -caption="Build file in GitHub Action" -max-width="50%" -%} - -{% include image.html -lightbox="true" -file="/images/integrations/github-actions/actiosn-cf-report-image-step.png" -url="/images/integrations/github-actions/actiosn-cf-report-image-step.png" -alt="Codefresh report image step in GitHub Action build file" -caption="Codefresh report image step in GitHub Action build file" -max-width="50%" -%} - - -### Related articles -[Shared configuration repo]({{site.baseurl}}/docs/reference/shared-configuration/) -[Image enrichment with integrations]({{site.baseurl}}/docs/integrations/image-enrichment-overview/) -[Container registry integrations]({{site.baseurl}}/docs/integrations/container-registries/) -[Issue-tracking integrations]({{site.baseurl}}/docs/integrations/issue-tracking/) - - diff --git a/_docs/integrations/ci-integrations/jenkins.md b/_docs/integrations/ci-integrations/jenkins.md deleted file mode 100644 index ddfa1eba..00000000 --- a/_docs/integrations/ci-integrations/jenkins.md +++ /dev/null @@ -1,250 +0,0 @@ ---- -title: "Jenkins" -description: "" -group: integrations -sub_group: ci-integrations -toc: true ---- - - Use Hosted GitOps with any popular Continuous Integration (CI) solution, not just with Codefresh CI. Jenkins is one of the third-party CI platform/tools that you can connect to Codefresh for deployment with image enrichment and reporting. - - Connecting a Jenkins pipeline, adds the CI information to images which are displayed in the Images dashboard, as in the example below. - - {% include - image.html - lightbox="true" - file="/images/integrations/images-dashboard.png" - url="/images/integrations/images-dashboard.png" - alt="Images dashboard with enriched image information" - caption="Images dashboard with enriched image information" - max-width="70%" - %} - - -For information on how to use the image reporting action in your Jenkins pipeline and how to configure the integration, see [CI Integrations]({{site.baseurl}}/docs/integrations/ci-integrations/). - -### Example of Jenkins pipeline with report image step - -{% highlight yaml %} -{% raw %} - -pipeline { - - agent any - stages { - stage('Clone repository') { - steps { - checkout scm - } - } - stage ('Build & Push ') { - environment { - CF_IMAGE= credentials('CF_IMAGE') - } - steps { - sh 'echo "Building $CF_IMAGE"' - script { - def app - app = docker.build("${env.CF_IMAGE}") - // require credentials to be stored under DOCKERHUB - docker.withRegistry('https://registry.hub.docker.com', 'DOCKERHUB') { - app.push("latest") - } - } - sh ''' - # test we have image in repository. - docker pull $CF_IMAGE - ''' - } - } - - stage('report image') { - environment { - // Name of runtime to implement the enrichment - CF_RUNTIME_NAME= 'codefresh-hosted' - - // Image path to enrich - CF_IMAGE= credentials('CF_IMAGE') - - // Codefresh API key !! Committing a plain text token is a security risk. We highly recommend using encrypted secrets. !! - // Documentation - https://www.jenkins.io/doc/book/using/using-credentials - CF_API_KEY= credentials('CF_API_KEY') - - // Name of Container registry integration - CF_CONTAINER_REGISTRY_INTEGRATION= 'docker' - - // Name of Jira integration - CF_ISSUE_TRACKING_INTEGRATION= 'jira' - - // String starting with the issue ID to associate with image - CF_JIRA_MESSAGE= 'CR-11027' - - // Jira project filter - CF_JIRA_PROJECT_PREFIX= 'CR' - - // GitHub Access token !! Committing a plain text token is a security risk. We highly recommend using encrypted secrets. !! - // Documentation - https://www.jenkins.io/doc/book/using/using-credentials - CF_GITHUB_TOKEN= credentials('CF_GITHUB_TOKEN') - } - steps { - sh ''' - export CF_CI_TYPE="jenkins" - # add workflow details - export CF_WORKFLOW_NAME="${CF_WORKFLOW_NAME:-$JOB_NAME}" - export CF_WORKFLOW_URL="${CF_WORKFLOW_URL:-$BUILD_URL}" - # add git branch - export CF_GIT_PROVIDER="${CF_GIT_PROVIDER:-github}" - WITHOUT_POSTFIX="${GIT_URL%.*}" - export CF_GIT_REPO="${CF_GIT_REPO:-${WITHOUT_POSTFIX#*//*/}}" - # slice branch name from repo/branch - export CF_GIT_BRANCH="${CF_GIT_BRANCH:-${GIT_BRANCH#*/}}" - env | cut -f 1 -d "=" | grep -E "^CF_" > cf_env - docker run --env-file=cf_env "quay.io/codefresh/codefresh-report-image:latest" - ''' - } - } - - } -} - -{% endraw %} -{% endhighlight yaml %} - -### Jenkins-Codefresh integration arguments -The table describes the arguments to connect Codefresh Classic to Codefresh. - -{: .table .table-bordered .table-hover} -| Argument | Description | Required/Optional/Default | -| ---------- | -------- | ------------------------- | -| `CF_RUNTIME_NAME` | The runtime to use for the integration. If you have more than one runtime, select the runtime from the list. | Required | -| `CF_PLATFORM_URL` | The root URL of the Codefresh application. The default value is `https://g.codefresh.io`. | Optional | -| `CF_API_KEY` | The API key to authenticate the Codefresh Classic user to Codefresh. Generate the key for the integration. | Required | -| `CF_CONTAINER_REGISTRY_INTEGRATION` | The name of the container registry integration created in Codefresh where the image is stored. To create a container registry integration if you don't have one, click **Create Container Registry Integration**, and then configure the settings. See [Container registry integrations]({{site.baseurl}}/docs/integrations/container-registries/). | Optional | -| `CF_JIRA_INTEGRATION` | Deprecated from version 0.0.565. Replaced by `CF_ISSUE_TRACKING_INTEGRATION`. | _Deprecated_ -| `CF_ISSUE_TRACKING_INTEGRATION` | The name of the issue tracking integration created in Codefresh to use to enrich the image. Relevant only if Jira enrichment is required for the image. If you don't have a Jira integration, click **Create Atlassian Jira Integration** and configure settings. See [Jira integration]({{site.baseurl}}/docs/integrations/issue-tracking/jira/). | Optional | -| `CF_IMAGE` | The image to be enriched and reported in Codefresh. Pass the `[account-name]/[image-name]:[tag]` built in your CI. | Required | -| `CF_GIT_BRANCH` | The Git branch with the commit and PR (pull request) data to add to the image. Pass the Branch from the event payload used to trigger your action. | Required | -| `CF_GIT_REPO` | The Git repository with the configuration and code used to build the image. | Required | -| `CF_GIT_PROVIDER` | The Git provider for the integration, and can be either `github`, `gitlab`, or `bitbucket`. {::nomarkdown}- {:/}| Optional |
-| `CF_GITLAB_TOKEN` | The token to authenticate the GitLab account. {::nomarkdown}
- {:/} | Optional |
-| `CF_GITLAB_HOST_URL` | The URL address of your GitLab Cloud/Server instance. {::nomarkdown}
- {:/} | Optional |
-| `CF_BITBUCKET_USERNAME` | The username for the Bitbucket or the Bitbucket Server (on-prem) account. {::nomarkdown}
- {:/}| Optional |
-| `CF_BITBUCKET_PASSWORD` | The password for the Bitbucket or the Bitbucket Server (on-prem) account. {::nomarkdown}
- {:/}| Optional |
-| `CF_BITBUCKET_HOST_URL` | Relevant for Bitbucket Server accounts only. The URL address of your Bitbucket Server instance. Example, `https://bitbucket-server:7990`. {::nomarkdown}
-{:/} - -#### CF_IMAGE -**Example: Report repo, branch with Git hash** -This example illustrates how to define the value for `CF_IMAGE` to report Git repo, branch, committer, and Git hash information. - - Value: - {% raw %}`${env.GIT_COMMITTER_NAME}/${env.GIT_URL}/${env.GIT_BRANCH}/${env.GIT_REVISION}`{% endraw %} - - where: - * {% raw %}`${env.GIT_COMMITTER_NAME}`{% endraw %} reports the name of the user who made the commit. For example, `nr-codefresh`. - * {% raw %}`${env.GIT_URL}`{% endraw %} reports the name of the Git repository. For example, `codefresh-production`. - * {% raw %}`${env.GIT_BRANCH}`{% endraw %} reports the name of the Git branch. For example, `pr-2345`, `new-auth-strategy`. - * {% raw %}`${env.GIT_REVISION}`{% endraw %} reports the Git SHA1 commit ID pointing to the commit that was built. For example, `fa53bfa91df14c4c9f46e628a65ee21dd574490a`. - - -**Example: Report a specific image tag** -This example illustrates how to define the value for `CF_IMAGE` when you know the specific image version you want to report. - - Value: - {% raw %}`${env.GIT_COMMITTER_NAME}/${env.GIT_URL}/`{% endraw %} - - where: - * {% raw %}`${env.GIT_COMMITTER_NAME}`{% endraw %} and {% raw %}`${env.GIT_URL}`{% endraw %} report the names of the user hwo made the commit and the repository, respectively. For example, `nr-codefresh` and `codefresh-production`, respectively. - * {% raw %}` `{% endraw %} reports the hard-coded tag `v1.0`. - - -**Example: Report the latest Git tag available on repository** -This example illustrates how to define the value for `CF_IMAGE` value to report the latest Git tag on the repository. - - Value: - {% raw %}`codefresh/${env.GIT_URL}/latest`{% endraw %} - - where: - * {% raw %}`codefresh`{% endraw %} is the hard-coded re - * {% raw %}`${env.GIT_URL}`{% endraw %} reports the name of the repository that triggered the integration. - * {% raw %}`latest`{% endraw %} reports the latest Git tag available for the repository defined by {% raw %}`${env.GIT_URL}`{% endraw %}. For example, `v1.0.4-14-g2414721`. - -{::nomarkdown} -
-{:/} - -#### CF_GIT_BRANCH - -**Example: Report the fully-formed Git branch** -This example illustrates how to define the value for `CF_GIT_BRANCH` value to report the fully-formed Git branch. - - Value: - {% raw %}`${env.GIT_URL}/${env.GIT_BRANCH}`{% endraw %} - - where: - * {% raw %}`${env.GIT_URL}`{% endraw %} is the name of the repository that triggered the pipeline. For example, `codefresh-production`. - * {% raw %}`${env.GIT_BRANCH}`{% endraw %} is the fully-formed name of the Git branch. For example, `origin/auth-feature-branch`. - - -**Example: Report the local Git branch** -This example illustrates how to define the value for `CF_GIT_BRANCH` value to report only the branch in the repository that triggerred the pipeline. - - Value: - {% raw %}`${env.GIT_URL}/${env.GIT_LOCAL_BRANCH}`{% endraw %} - - where: - * {% raw %}`${env.GIT_URL}`{% endraw %} is the name of the repository that triggered the piepline. - * {% raw %}`${env.GIT_LOCAL_BRANCH}`{% endraw %} is the name of the Git branch. For example, `auth-feature-branch`. - -{::nomarkdown} -
-{:/} - -#### CF_JIRA_MESSAGE -The Jira message represents an existing Jira issue, and must be a literal string. - - Value: - `CR-1246` - -### Jenkins integration logs -View and analyze logs for Jenkins through the Logs tab. When a Jenkins pipeline is run, it is added to the Logs tab. -You can: -* Filter by status or by date range to view a subset of actions -* Navigate to the build file in Jenkins, and view the Codefresh report image step. - - -**Build in Jenkins** - -The Run column includes the link to the pipeline in Jenkins. - -Here is an example of the Jenkins log for the pipeline with the report image step. - -{% include image.html -lightbox="true" -file="/images/integrations/jenkins/jenkins-integration-log.png" -url="/images/integrations/jenkins/jenkins-integration-log.png" -alt="Logs for Codefresh report image step in Jenkins build" -caption="Logs for Codefresh report image step in Jenkins build" -max-width="50%" -%} - -### Related articles -[Shared configuration repo]({{site.baseurl}}/docs/reference/shared-configuration/) -[Image enrichment with integrations]({{site.baseurl}}/docs/integrations/image-enrichment-overview/) -[Container registry integrations]({{site.baseurl}}/docs/integrations/container-registries/) -[Issue-tracking integrations]({{site.baseurl}}/docs/integrations/issue-tracking/) \ No newline at end of file diff --git a/_docs/integrations/container-registries.md b/_docs/integrations/container-registries.md deleted file mode 100644 index 2aef4ac1..00000000 --- a/_docs/integrations/container-registries.md +++ /dev/null @@ -1,91 +0,0 @@ ---- -title: "Container registry integrations" -description: "" -group: integrations -toc: true ---- - -Codefresh can integrate with popular container registries such as Docker Hub, JFrog Artifactory, and more. - -Adding a container registry integration in Codefresh allows you to reference the integration in third-party CI platforms/tools such as GitHub Actions and Codefresh Classic by the name of the registry integration, instead of explicit credentials. See [Image enrichment with integrations]({{site.baseurl}}/docs/integrations/image-enrichment-overview/) and [CI integrations]({{site.baseurl}}/docs/integrations/ci-integrations/). - -You add a container registry integration in Codefresh by: -* Defining the integration name -* Selecting the runtime or runtimes it is shared with -* Defining the arguments -* Testing the connection -* Committing the changes - -You can add more than one integration for the same registry. Once added, Codefresh displays the list of existing integrations with their sync status. You can edit or delete any registry integration. - - - - -### Configure container registry integrations in Codefresh -Configure the settings for a container registry integration in Codefresh. - -1. In the Codefresh UI, go to [Integrations](https://g.codefresh.io/2.0/account-settings/integrations){:target="\_blank"}. -1. Filter by **Container Registry**, select the container registry, and click **Configure**. -1. If you already have integrations, click **Add**. -1. Define the arguments for the container registry: - [Amazon ECR]({{site.baseurl}}/docs/integrations/container-registries/amazon-ecr/) - [Docker Hub]({{site.baseurl}}/docs/integrations/container-registries/dockerhub/) - [GitHub Container Registry]({{site.baseurl}}/docs/integrations/container-registries/github-cr/) - [JFrog Artifactory]({{site.baseurl}}/docs/integrations/container-registries/jfrog/) - [Quay]({{site.baseurl}}/docs/integrations/container-registries/quay/) -1. To test the connection to the container registry before committing the changes, click **Test Connection**. -1. To confirm, click **Commit**. - It may take a few moments for the new integration to be synced to the cluster before it appears in the list. - -### Integration resource in shared configuration repo -The integration resource for the container registry is created in the Git repository with the shared configuration, within `resources`. -The exact location depends on whether the integration is shared with all or specific runtimes: -* All runtimes: Created in `resources/all-runtimes-all-clusters/` -* Selected runtimes: Created in `resources/runtimes//` - -### View container registry integrations -Selecting a container registry integration displays the existing integrations for that registry in Codefresh. -The example below shows integrations for JFrog Artifactory. - -{% include image.html -lightbox="true" -file="/images/integrations/jfrog/jfrog-int-list.png" -url="/images/integrations/jfrog/jfrog-int-list.png" -alt="JFrog integrations in Codefresh" -caption="JFrog integrations in Codefresh" -max-width="70%" -%} - -Every container registry integration displays the following information: -* Name of the integration -* Runtime or runtimes it is shared with -* Sync status - -### Edit/delete container registry integrations -If you have existing integrations, you can change the connection details, or delete an integration. ->Deleting an integration deletes the integration resource from the shared configuration Git repo, its secrets, the CI workflows that -use it. - -1. In the Codefresh UI, go to [Integrations](https://g.codefresh.io/2.0/account-settings/integrations){:target="\_blank"}. -1. Filter by **Container Registry**, and select the specific container registry integration. -1. In the row with the integration to edit or delete, click the three dots and select **Edit** or **Delete**. -1. To edit, update the **Username** and **Password** fields, and click **Test Connection** to verify the account credentials. -1. To delete, type **DELETE** in the text box as instructed. - - {% include - image.html - lightbox="true" - file="/images/integrations/jfrog/delete-jfrog.png" - url="/images/integrations/jfrog/delete-jfrog.png" - alt="Delete container registry integration" - caption="Delete container registry integration" - max-width="50%" - %} - -### Related articles -[CI integrations]({{site.baseurl}}/docs/integrations/ci-integrations/) -[Issue-tracking integrations]({{site.baseurl}}/docs/integrations/issue-tracking/) -[Shared configuration repo]({{site.baseurl}}/docs/reference/shared-configuration/) -[Images]({{site.baseurl}}/docs/deployment/images/) -[Monitoring applications]({{site.baseurl}}/docs/deployment/applications-dashboard/) -[Add Git sources to runtimes]({{site.baseurl}}/docs/runtime/git-sources/) diff --git a/_docs/integrations/container-registries/amazon-ecr.md b/_docs/integrations/container-registries/amazon-ecr.md deleted file mode 100644 index 17aee861..00000000 --- a/_docs/integrations/container-registries/amazon-ecr.md +++ /dev/null @@ -1,61 +0,0 @@ ---- -title: "Amazon ECR" -description: "" -group: integrations -sub_group: container-registries -toc: true ---- - -Codefresh has native support for interacting with Amazon ECR (Elastic Container Registry), to push, pull, and deploy images. -For information on adding an Amazon ECR integration in Codefresh, see [Container registry integrations]({{site.baseurl}}/docs/integrations/container-registries/). - ->Amazon ECR integration is supported only in hybrid runtimes. - -### Prerequisites -Before you configure settings in Codefresh to integrate Amazon ECR: -* [Create an IAM (Identity and Access Management) role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html){:target="\_blank"} - -Define the role in trusted relationships with `Effect: Allow` and `Action: sts:AssumeRole` on the EKS cluster. -For example: -```yaml -{ - "Effect": "Allow", - "Principal": { - "AWS": "arn:aws:iam::XXXXX:role/eksctl-awscluster-ServiceRole-XXXXXX" - }, - "Action": "sts:AssumeRole", - "Condition": {} - }, -``` -For detailed information, see [How Amazon Elastic Container Registry Works with IAM](https://docs.aws.amazon.com/AmazonECR/latest/userguide/security_iam_service-with-iam.html){:target="\_blank"} and the [AWS security blog](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/){:target="\_blank"}. - -### Amazon ECR integration settings in Codefresh -The table describes the arguments required to integrate Amazon ECR in Codefresh. - -{: .table .table-bordered .table-hover} -| Setting | Description | -| ---------- | -------- | -| **Integration name** | A friendly name for the integration. This is the name you will reference in the third-party CI platform/tool. | -| **All Runtimes/Selected Runtimes** | {::nomarkdown} The runtimes in the account with which to share the integration resource.
The integration resource is created in the Git repository with the shared configuration, within resources. The exact location depends on whether the integration is shared with all or specific runtimes:
The integration resource is created in the Git repository with the shared configuration, within resources. The exact location depends on whether the integration is shared with all or specific runtimes:
The integration resource is created in the Git repository with the shared configuration, within resources. The exact location depends on whether the integration is shared with all or specific runtimes:
The integration resource is created in the Git repository with the shared configuration, within resources. The exact location depends on whether the integration is shared with all or specific runtimes:
The integration resource is created in the Git repository with the shared configuration, within resources. The exact location depends on whether the integration is shared with all or specific runtimes:/` - -### View issue-tracking integrations -Selecting an issue tracking tool displays the existing integrations in Codefresh. - - -Every issue tracking integration displays the following information: -* Name of the integration -* Runtime or runtimes it is shared with -* Sync status - -### Edit/delete issue-tracking integrations in Codefresh -If you have existing integrations, you can change the credentials, or delete an integration. ->Deleting an integration deletes the integration resource from the shared configuration Git repo, its secrets, the CI workflows that -use it. - -1. In the Codefresh UI, go to [Integrations](https://g.codefresh.io/2.0/account-settings/integrations){:target="\_blank"}. -1. Filter by **Issue Tracking**, and select the specific integration. -1. In the row with the integration to edit or delete, click the three dots and select **Edit** or **Delete**. -1. To edit, update the **Username** and **Password** fields, and click **Test Connection** to verify the account credentials. -1. To delete, type **DELETE** in the text box as instructed. - - {% include - image.html - lightbox="true" - file="/images/integrations/jira/jira-delete.png" - url="/images/integrations/jira/jira-delete.png" - alt="Delete issue-tracking integration" - caption="Delete issue-tracking integration" - max-width="50%" - %} - -### Related articles -[Shared configuration repo]({{site.baseurl}}/docs/reference/shared-configuration/) -[CI integrations]({{site.baseurl}}/docs/integrations/ci-integrations/) -[Container registry integrations]({{site.baseurl}}/docs/integrations/container-registries/) - diff --git a/_docs/integrations/issue-tracking/jira.md b/_docs/integrations/issue-tracking/jira.md deleted file mode 100644 index fd223281..00000000 --- a/_docs/integrations/issue-tracking/jira.md +++ /dev/null @@ -1,58 +0,0 @@ ---- -title: "Jira" -description: " " -group: integrations -sub_group: issue-tracking -toc: true ---- - - -Codefresh has native integration for Atlassian Jira, to enrich images with information from Jira. Codefresh can monitor a feature all the way from the ticket creation phase, up to when it is implemented and deployed to an environment. - -For information on adding a Jira integration in Codefresh, see [Issue-tracking integrations]({{site.baseurl}}/docs/integrations/issue-tracking/). - - -### Prerequisites - -1. Get your Jira instance credentials by following the [Atlassian documentation](https://support.atlassian.com/atlassian-account/docs/manage-api-tokens-for-your-atlassian-account/){:target="\_blank"}. -1. Note down the following as you will need them to complete the integration with Codefresh: - * Jira URL - * Jira username/email to be used for the integration - * Jira password/token created for this user - - -### Jira integration settings in Codefresh - -The table describes the arguments required to integrate Jira in Codefresh. - -{: .table .table-bordered .table-hover} -| Setting | Description | -| ---------- | -------- | -| **Integration name** | A friendly name for the integration. This is the name you will reference in the third-party CI platform/tool. | -| **All Runtimes/Selected Runtimes** | {::nomarkdown} The runtimes in the account with which to share the integration resource.
The integration resource is created in the Git repository with the shared configuration, within resources. The exact location depends on whether the integration is shared with all or specific runtimes:.atlassian.net`| -|**API Token**| The Jira password/token you noted down when you created the Jira instance.| -|**API Email**| The email for the API token.| - - - {% include - image.html - lightbox="true" - file="/images/integrations/jira/jira-int-settings.png" - url="/images/integrations/jira/jira-int-settings.png" - alt="JIRA integration in Codefresh" - caption="JIRA integration in Codefresh" - max-width="60%" -%} - -For information on adding a Jira integration in Codefresh, see [Issue-tracking integrations]({{site.baseurl}}/docs/integrations/issue-tracking/). - -### Using Jira integration in pipelines -For pipelines based on GitHub Actions, configure the Jira integration in Codefresh, and then connect your GitHub Action to Codefresh, referencing the Jira integration by name. -Codefresh uses the Secret Key stored in the runtime cluster to securely access Jira and retrieve the information. - -### Related articles -[Shared configuration repo]({{site.baseurl}}/docs/reference/shared-configuration/) -[Image enrichment with integrations]({{site.baseurl}}/docs/integrations/image-enrichment-overview/) -[CI integrations]({{site.baseurl}}/docs/integrations/ci-integrations/) -[Container registry integrations]({{site.baseurl}}/docs/integrations/container-registries/) diff --git a/_docs/migration/gitops-dashboard.md b/_docs/migration/gitops-dashboard.md deleted file mode 100644 index 17429bac..00000000 --- a/_docs/migration/gitops-dashboard.md +++ /dev/null @@ -1,8 +0,0 @@ ---- -title: "GitOps dashboard" -description: "" -group: migration -toc: true ---- - -Coming soon diff --git a/_docs/migration/pipelines.md b/_docs/migration/pipelines.md deleted file mode 100644 index 176f096c..00000000 --- a/_docs/migration/pipelines.md +++ /dev/null @@ -1,8 +0,0 @@ ---- -title: "Pipelines" -description: "" -group: migration -toc: true ---- - -Coming soon diff --git a/_docs/reference/git-tokens.md b/_docs/reference/git-tokens.md deleted file mode 100644 index 25a8994a..00000000 --- a/_docs/reference/git-tokens.md +++ /dev/null @@ -1,109 +0,0 @@ ---- -title: "Git tokens" -description: "" -group: reference -redirect_from: - - /docs/administration/git-tokens/ -toc: true ---- - - - -Codefresh requires two types of Git tokens for authentication: -* Git runtime token for runtime installation - Used by: - * Argo CD clone repositories and pull changes to sync the desired state in Git to the live state on the cluster. - * Argo Events to create webhooks in Git repositories for Event Sources in Delivery Pipelines - - The Git runtime token is runtime-specific but not user-specific. - - -* Git user token, a user-specific personal access token for each runtime, unique to every user - Unique to every user, the Git user token is used to authenticate the user for client-based actions, such as Git clone and push operations on specific repositories. - Git user token requirements translate to permission scopes which differ for the different Git providers. - - After installation, you need to authorize Git access for every provisioned runtime either through OAuth2 or through a personal access token from your Git provider. - Every user can view the list of runtimes and tokens assigned to each runtime in [User Settings](https://g.codefresh.io/2.0/user-settings){:target="\_blank"}. Codefresh flags and notifies you of invalid, revoked, or expired tokens. - - - - -### Git runtime token scopes -The Git runtime token is mandatory for runtime installation. - -{::nomarkdown} - -{:/} - -#### GitHub and GitHub Enterprise runtime token scopes - -* `repo` -* `admin:repo_hook` - -{::nomarkdown} - -{:/} - -#### GitLab Cloud and GitLab Server runtime token scopes - -* `api` -* `read_repository` - -{::nomarkdown} - -{:/} - -#### Bitbucket Cloud and Bitbucket Server runtime token scopes - -* **Account**: `Read` -* **Workspace membership**: `Read` -* **Webhooks**: `Read and write` -* **Repositories**: `Write`, `Admin` - -{::nomarkdown} - -{:/} - -### Git personal tokens -The Git personal token is a user-specific personal access token per provisioned runtime. Unique to each user, it may be required after to authenticate Git-based actions per runtime in Codefresh, based on how your admin has set up authentication for Git providers. - -> If you have access to multiple runtimes, you can use the same personal access token for all the runtimes. - You must configure the token for each runtime. - -{::nomarkdown} - -{:/} - -#### GitHub and GitHub Enterprise personal user token scopes -* `repo` - - -{::nomarkdown} - -{:/} - -#### GitLab Cloud and GitLab Server personal user token scopes - -* `write_repository` (includes `read-repository`) -* `api-read` - -{::nomarkdown} - -{:/} - -#### Bitbucket Cloud and Server personal user token scopes - -* **Account**: `Read` -* **Workspace membership**: `Read` -* **Repositories**: `Write`, `Admin` - -### Related articles -[User settings]({{site.baseurl}}/docs/administration/user-settings/) \ No newline at end of file diff --git a/_docs/reference/secrets.md b/_docs/reference/secrets.md deleted file mode 100644 index b306c751..00000000 --- a/_docs/reference/secrets.md +++ /dev/null @@ -1,47 +0,0 @@ ---- -title: "Secrets" -description: "Learn how Codefresh stores secrets" -group: reference -toc: true ---- - - -Codefresh provides out-of-the-box management for secrets, generally to store secrets for third-party integrations. - -For secure secret storage, every Codefresh runtime uses the [Bitnami Sealed Secrets controller](https://github.com/bitnami-labs/sealed-secrets){:target="_blank"} behind the scenes. -This controller is installed as part of the runtime and automatically managed by Codefresh. - -### How Sealed Secrets work - -Sealed Secrets are based on [public/private key encryption](https://en.wikipedia.org/wiki/Public-key_cryptography){:target="_blank"}. When the controller is installed, it gets a public and private key. The private key stays within the cluster. The public key can be given anywhere to encrypt secrets. - -Any kind of secret can be encrypted with the public key (also via the `kubeseal` executable), and then passed to the cluster for decryption when needed. - -For GitOps applications, encryption for secrets is critical, as it means that you can commit any kind of secret in Git as long as it is encrypted. - -Here's the event flow for Sealed Secrets: - -1. A secret is encrypted by an operator and/or developer with the `kubeseal` executable. -1. A custom Kubernetes resource called SealedSecret is created. -1. The secret is committed in Git. -1. During application deployment, the Codefresh runtime applies this secret to the cluster. -1. The Sealed Secret controller identifies the Sealed Secret object and decrypts it using the private key of the cluster. -1. The Sealed Secret is converted to a [standard Kubernetes secret](https://kubernetes.io/docs/concepts/configuration/secret/) {:target="_blank"} inside the cluster. -1. It is then passed to the application like any other secret, as a mounted file or environment variable. -1. The application uses the secret in its decrypted form. - -For more details, you can read our [blog post for sealed secrets](https://codefresh.io/blog/handle-secrets-like-pro-using-gitops/){:target="_blank"}. - -### Configuring the Sealed Secrets controller - -The Sealed Secret controller is fully managed by the Codefresh runtime, and secret encryption and decryption are fully automated. - -> **Warning!** DO NOT tamper with the controller or its private/public keys in any way. - -The applications you deploy with Codefresh should also have no knowledge of the controller. All secrets that you need in your own applications should be accessed using the standard Kubernetes methods. - -### What to read next -[Set up a hosted (Hosted GitOps environment]({{site.baseurl}}/docs/runtime/hosted-runtime) -[Install hybrid runtimes]({{site.baseurl}}/docs/runtime/installation) -[Image enrichment with integrations]({{site.baseurl}}/docs/integrations/image-enrichment-overview) - diff --git a/_docs/reference/shared-configuration.md b/_docs/reference/shared-configuration.md deleted file mode 100644 index 5153b962..00000000 --- a/_docs/reference/shared-configuration.md +++ /dev/null @@ -1,124 +0,0 @@ ---- -title: "Shared configuration repo" -description: "" -group: reference -toc: true ---- - - -A Codefresh account with a hosted or a hybrid runtime can store configuration manifests for account-level resources in a Git repository. This repository can be shared with other runtimes in the same account, avoiding the need to create and maintain configuration manifests for every runtime. - -* Hosted runtimes - As part of the setup for a hosted runtime, Codefresh creates the shared configuration repository in the selected organization, together with the default Git Source repo. See [Connect Git provider]({{site.baseurl}}/docs/runtime/hosted-runtime/#2-connect-git-provider) in Hosted GitOps setup. - -* Hybrid runtimes - When you install the first hybrid runtime for an account, you can manually define the shared configuration repo through the `--shared-config-repo` flag. Or, you can allow Codefresh to automatically create the shared configuration repo in the runtime installation repo, in `shared-config` root. See [Installing hybrid runtimes]({{site.baseurl}}/docs/runtime/installation/). - - For older versions of hybrid runtimes, upgrade the runtime to create the shared configuration repo, as described in [Upgrading hybrid runtimes](#upgrading-hybrid-runtimes) later in this article. - -> Currently, Codefresh supports a single shared configuration repo per account. - - -### Shared configuration repo structure -Below is a representation of the structure of the repository with the shared configuration. -See a [sample repo](https://github.dev/noam-codefresh/shared-gs){:target="\_blank"}. - -``` -. -├── resources <───────────────────┐ -│ ├── all-runtimes-all-clusters │ -│ │ ├── cm-all.yaml │ -│ │ └── subfolder │ -│ │ └── manifest2.yaml │ -│ ├── control-planes │ -│ │ └── manifest3.yaml │ -│ ├── runtimes │ -│ │ ├── runtime1 │ -│ │ │ └── manifest4.yaml │ -│ │ └── runtime2 │ -│ │ └── manifest5.yaml │ -│ └── manifest6.yaml │ -└── runtimes │ - ├── production │ # referenced by /apps/runtime1/config_dir.json - │ ├── in-cluster.yaml ─┤ # manage `include` field to decide which dirs/files to sync to cluster - │ └── remote-cluster.yaml ─┤ # manage `include` field to decide which dirs/files to sync to cluster - └── staging │ # referenced by /apps/runtime2/config_dir.json - └── in-cluster.yaml ─┘ # manage `include` field to decide which dirs/files to sync to cluster -``` -{::nomarkdown} -
-{:/} - -#### `resources` directory - -The `resources` directory holds the resources shared by all clusters managed by the runtime: - - * `all-runtimes-all-clusters`: Every resource manifest in this directory is applied to all the runtimes in the account, and to all the clusters managed by those runtimes. - * `control-planes`: Optional. Valid for hosted runtimes only. When defined, every resource manifest in this directory is applied to each hosted runtime’s `in-cluster`. - * `runtimes/`: Optional. Runtime-specific subdirectory. Every resource manifest in a runtime-specific subdirectory is applied to only that runtime. `manifest4.yaml` in the above example is applied only to `runtime1`. - -{::nomarkdown} -
-{:/} - -#### `runtimes` directory -Includes subdirectories specific to each runtime installed in the cluster, always with `in-cluster.yaml`, and optionally, application manifests for other clusters. - -**Example application manifest for in-cluster.yaml** - -```yaml -apiVersion: argoproj.io/v1alpha1 -kind: Application -metadata: - labels: - codefresh.io/entity: internal-config - codefresh.io/internal: 'true' - name: in-cluster -spec: - project: default - source: - repoURL:/*.yaml,runtimes/ /**/*.yaml,control-planes/*.yaml,control-planes/**/*.yaml}' - recurse: true - destination: - namespace: - server: https://kubernetes.default.svc - syncPolicy: - automated: - allowEmpty: true - prune: true - selfHeal: true - syncOptions: - - allowEmpty=true -``` - - -### Git Source application per runtime -In addition to the application manifests for the runtimes in the shared configuration repository, every runtime has a Git Source application that references `runtimes/ `. - -This Git Source application creates an application manifest with the ` ` for every cluster managed by the runtime. The `include` field in the ` ` application manifest determines which subdirectories in the `resources` directory are synced to the target cluster. - - -### Adding resources -When creating a new resource, such as a new integration for example in the Codefresh UI, you can define the runtimes and clusters to which to apply that resource. The app-proxy saves the resource in the correct location and updates the relevant Argo CD Applications to include it. - -### Upgrading hybrid runtimes -Older hybrid runtimes that do not have the shared configuration repository must be upgraded to the latest version. -You have two options to define the shared configuration repository during upgrade: -* Upgrade the hybrid runtime, and let the Codefresh app-proxy automatically create the shared configuration repo automatically. -* Manually define the shared configuration repository, by adding the `--shared-config-repo` flag in the runtime upgrade command. - ->If the shared configuration repo is not created for an account, Codefresh creates it in the installation repo, in `shared-config` root. - -If the hybrid runtime being upgraded has managed clusters, once the shared configuration repo is created for the account either automatically or manually on upgrade, all clusters are migrated to the same repo when app-proxy is initialized. An Argoproj application manifest is committed to the repo for each cluster managed by the runtime. - -See [(Hybrid) Upgrade provisioned runtimes]({{site.baseurl}}/docs/runtime/monitor-manage-runtimes/#hybrid-upgrade-provisioned-runtimes). - - - - - - - diff --git a/_docs/reporting/dora-metrics.md b/_docs/reporting/dora-metrics.md deleted file mode 100644 index 229b2d7b..00000000 --- a/_docs/reporting/dora-metrics.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -title: "DORA metrics" -description: "Get insights into your deployments" -group: reporting -toc: true ---- - -DevOps is a collaboration paradigm that is sometimes mistaken for being too abstract or too generic. In an effort to quantify the benefits of adopting DevOps, [Dora Research](https://www.devops-research.com/research.html#capabilities){:target="\_blank"} (acquired by Google in 2018), has introduced four key metrics that define specific goals for improving the software lifecycle in companies interested in adopting DevOps. - -DORA measures these metrics: - -* Deployment Frequency: How often an organization successfully releases to production -* Lead Time for Changes: The length of time for a commit to be deployed into production -* Change Failure Rate: The percentage of deployments causing a failure in production -* Time to Restore Service: The length of time for an organization to recover from a failure in production - -[Read more on DORA](https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performance){:target="\_blank"}. - -### DORA metrics in Codefresh - -Monitoring DORA metrics can help identify delivery issues in your organization by detecting bottlenecks among teams, and help to optimize your workflows, at technical or organizational levels. -Codefresh offers support for DORA metrics out of the box. - -* In the Codefresh UI, go to [DORA metrics](https://g.codefresh.io/2.0/dora-dashboard/dora){:target="\_blank"}. - -{% include -image.html -lightbox="true" -file="/images/reporting/dora-metrics.png" -url="/images/reporting/dora-metrics.png" -alt="DORA metrics report" -caption="DORA metrics report" -max-width="100%" -%} - -### Filters - -Use filters to define the exact subset of applications you are interested in. All filters support auto-complete and multi-select. -More than one option within the same filter type has an OR relationship. More than one filter type when defined share an AND relationship. - -* Runtimes: Show metrics for applications from selected runtimes -* Clusters: Show metrics for applications deployed to selected clusters -* Applications: Show metrics for selected applications. -* Time: Show metrics from application for a specific time period - -> When no filters are defined, all metrics are shown for the last 90 days. - -### Metrics for favorite applications -If you have [starred applications as favorites]({{site.baseurl}}/docs/deployment/applications-dashboard/#applications-dashboard-information) in the Applications dashboard, clicking {::nomarkdown} 
{:/} in DORA metrics, displays metrics only for those applications.
-
-
-### Metric totals
-As the title indicates, the Totals bar shows the total numbers, based on the filters defined, or for the last 90 days, if there are no filters:
-
-* Deployments
-* Rollbacks
-* Commits/Pull Requests
-* Failure Rate: The number of failed deployments divided by the total number of deployments
-
-### Metric graphs
-The metric graphs show performance for the DORA metrics, again based on the filters defined, or for the last 90 days, if there are no filters.
-
-In addition, you can select the granularity for each graph:
-
-* Daily
-* Weekly
-* Monthly
-
-
-
-**Deployment Frequency**
- The frequency of deployments of any kind, successful or failed. Deployment is considered an Argo CD sync where there was a change. The X-axis charts the time based on the granularity, and the Y-axis charts the number of deployments. The number shown on the top right is the average deployment frequency based on granularity.
-
-**Change failure rate**
- The failure or rollback rate in percentage for deployments. Derived by dividing the failed/rollback deployments by the total number of deployments. Failed deployments are those Argo CD deployments that lead to a sync state of Degraded. The X-axis charts the time based on the granularity, and the Y-axis charts the failure rate. The number shown on the top right is the average failure rate based on granularity, and therefore may not be equal to the Total Failure Rate.
-
-**Lead Time for Changes**
- The average number of days from the first commit for a pull request until the deployment date for the same pull request. The X-axis charts the time based on the granularity, and the Y-axis charts the time in minutes until the deployment. The number shown on the top right is the average number of days for a commit to reach production.
-
-**Time to Restore Service**
- The average number of hours taken for the status to return to Healthy after changing to Degraded or Unhealthy. The X-axis charts the time based on the granularity, and the Y-axis charts the time in hours. The number shown on the top right is the average number of hours between the previous deployment and rollback for the same application.
-
-## What to read next
-[Codefresh architecture]({{site.baseurl}}/docs/getting-started/architecture/)
-[Monitoring applications]({{site.baseurl}}/docs/deployment/applications-dashboard/)
-
diff --git a/_docs/reporting/home-dashboard.md b/_docs/reporting/home-dashboard.md
deleted file mode 100644
index c3a402c0..00000000
--- a/_docs/reporting/home-dashboard.md
+++ /dev/null
@@ -1,142 +0,0 @@
----
-title: "Home dashboard"
-description: ""
-group: reporting
-toc: true
----
-
-Get a global picture of runtimes, managed clusters, deployments, and pipelines in the Home dashboard. The Home dashboard is displayed when you log in to Codefresh, providing system-wide visualization in real-time.
-
-Global filters allow you to narrow the scope of the data, and drill down into specific entities for more details.
-
- {% include
- image.html
- lightbox="true"
- file="/images/reporting/home-dashboard.png"
- url="/images/reporting/home-dashboard.png"
- alt="Home dashboard: Global enterprise analytics"
- caption="Home dashboard: Global enterprise analytics"
- max-width="70%"
- %}
-
-### Global filters
-Filter the view in the Home dashboard by runtimes and date range.
-
-{% include
- image.html
- lightbox="true"
- file="/images/reporting/global-filters.png"
- url="/images/reporting/global-filters.png"
- alt="Home dashboard: Global filters"
- caption="Home dashboard: Global filters"
- max-width="60%"
- %}
-
-### Runtimes and Managed Clusters
-
-Identify the health of the runtimes and managed clusters in your enterprise.
-Health status is displayed for both hosted (if you have Hosted GitOps), and hybrid runtimes.
-
-Managed clusters are external clusters registered to runtimes to which you deploy applications and GitOps-managed resources.
-
- {% include
- image.html
- lightbox="true"
- file="/images/reporting/runtimes-clusters-widgets.png"
- url="/images/reporting/runtimes-clusters-widgets.png"
- alt="Runtimes and Managed Clusters in the Home dashboard"
- caption="Runtimes and Managed Clusters in the Home dashboard"
- max-width="80%"
- %}
-
-{: .table .table-bordered .table-hover}
-| Item | Description |
-| ------------------------| ---------------- |
-|**Runtimes** | Identify failed runtimes.|
-|**Managed Clusters** |{::nomarkdown}
The number at the end of the bar is the total number of deployments for the application, with the overall decrease or increase compared to the reference period. {:/} | - - - -### Delivery Pipelines - -> Delivery Pipline data is shown for hybrid enviroments. - -Displays all active pipelines for the selected date range, providing insights into trends for pipelines. Active pipelines are those with at least one active or completed workflow. -Analytics are derived by comparing the selected date range to the corresponding reference period. If your date range is the last seven days, the reference period is the seven days that precede the date range. - -{% include - image.html - lightbox="true" - file="/images/reporting/delivery-pipeline-widget.png" - url="/images/reporting/delivery-pipeline-widget.png" - alt="Delivery Pipelines in the Home dashboard" - caption="Delivery Pipelines in the Home dashboard" - max-width="80%" - %} - -{: .table .table-bordered .table-hover} - -| Item | Description | -| ------------------------| ---------------- | -|**Pipelines** | The number prefixed to the pipeline name indicates the change in position of the pipeline compared to the reference period. To drill down into a specific pipeline, click the pipeline.| -|**Filter** | The filters available to focus on the pipelines of interest:{::nomarkdown}(i) In the event that the Achieved Uptime Percentage is less than the Target Uptime Percentage in three consecutive calendar months (a “Triggering Event”), Client shall have the right to cancel the agreement (the “Cancellation Right”) by providing Codefresh written notice of such cancellation (a “Cancellation Notice”) within 14 days after the last day of the calendar month in which the Triggering Event arose (the “Triggering Month”). If Client does not provide a Cancellation Notice within 14 days after the last day of the Triggering Month, the Cancellation Right arising with respect to the Triggering Event shall expire.
- - -(ii) Exercise of a Cancellation Right pursuant to this SLA will be Client’s sole and exclusive remedy, and the entire liability of Codefresh, for any failure to achieve the Target Uptime Percentage or any breach of this SLA. - - -{:/} - -**3. ERROR PRIORITIES AND RESPONSE TIMES**. - -Issues with the Codefresh Platform are classified based on severity of the issues and the required resources needed to resolve them. Codefresh will designate the severity and impact of the reported -issue as defined below and will use commercially reasonable efforts to respond and commence working on the applicable issue in accordance with the time periods below. - -{::nomarkdown} -3.1. SLA Response Times. - -{:/} - -| Priority | Silver* | Gold* | Platinum** | -| -------------- | ---------------------------- | -----------------| -----------------| -|Urgent | 4 Hours | 2 Hours | 1 Hour | -| High | 6 Business Hours | 4 Business Hours | 2 Hours | -| Normal | 1 Business Day | 6 Business Hours | 3 Business Hours | -| Low | 1 Business Week | 2 Business Days | 8 Business Hours | - -***Silver and Gold:** 9AM - 5PM PST support. Production down events will be handled with utmost urgency. - -****Platinum:** 24/7 support. Customers with Platinum SLA can open urgent tickets in our Off-hours. - - -**3.2. Priority Definitions**. - -{: .table .table-bordered .table-hover} -| Priority Level | Description | -| -------------- | ---------------------------- | -| Urgent | Previously-working production services or functionality of the services are not available and there is no acceptable work around provided. | -| High | Disabled functionality, errors that result in a lack of significant functionality in the Services which prevent the user from accomplishing their testing with no acceptable work around provided.| -| Normal | Errors that cause previously-working non-critical features to malfunction. | -| Low | General questions, How-To’s, best practices questions, and feature requests.| - -[Severity Examples](https://support.codefresh.io/hc/en-us/articles/360018951039-Codefresh-SLA-definitions) - -**3.3. Support Channels**. - -{: .table .table-bordered .table-hover} -| Channel | Free | Silver | Gold | Platinum| -|----------------|-----------|--------- |------|---------| -| Support Portal | X | X | X | X | -| SLA | | X | X | X | -| Phone* | | | X | X | -| Slack** | | | | X | - -***Phone**: An initial reply by our answering service who will open a support ticket immediately which will be prioritized accordingly. This does include the 'Live support'/co-piloting/on boarding features offered by our Professional Services. - -****Slack:** Not intended to be used for critical issues. - -**4. VERSION HISTORY**. - -{: .table .table-bordered .table-hover} -| Version Number | Nature of Change | Date Approved | -| -------------- | ---------------------------- | ---------------------------- | -|2.0 | General updates | April 20, 2022 | -|1.1 | Added support information | April 7, 2021 | -|1.0 | Initial version | January 17, 2021 | - diff --git a/_docs/terms-and-privacy-policy/terms-of-service.md b/_docs/terms-and-privacy-policy/terms-of-service.md deleted file mode 100644 index 8e1f193c..00000000 --- a/_docs/terms-and-privacy-policy/terms-of-service.md +++ /dev/null @@ -1,279 +0,0 @@ ---- -title: "" -description: "" -group: terms-and-privacy-policy -redirect_from: - - /docs/terms-of-service/ - - /docs/terms-and-privacy-policy/ -toc: true ---- -{::nomarkdown} - -
- -
CODEFRESH, INC.TERMS OF SERVICEBy executing any applicable Order that references these Terms of Service (collectively the “Agreement”), the Parties to the Agreement acknowledge and agree that these binding standard terms and conditions (the “Terms”) shall apply:
- -The following Terms dictate the Agreement between Codefresh, Inc. a Delaware corporation, or the Codefresh -entity set forth in the applicable Order if different, and its respective affiliates, -(collectively, “Codefresh”) and the licensee identified in the Agreement -(“Licensee” or “You”). Your right to access and use the Service, -whether or not an Agreement has been executed between Codefresh and Licensee -(or an entity that Licensee represents), is expressly conditioned on acceptance -of these Terms. By accessing or using the Services provided by Codefresh, -Licensee agrees to be bound by and abide by these Terms. These Terms shall apply -to all use by Licensee and Users of the Service.
- -1. GENERAL TERMS.
- -1.1. Definitions. Capitalized terms not defined herein shall be given the meaning set forth in -the applicable Order.
- -(i) “Account” means a user account created to access the -Codefresh platform.
- -(ii) “Codefresh Content” means data, Documentation, reports, text, -images, sounds, video, and content made available through any of the Service.
- -(iii) “Documentation” means the user documentation that Codefresh -makes generally available to users at https://codefresh.io/docs/.
- -(iv) “Licensee” means an individual, entity, or other legal person -using the Service.
- -(v) “Licensee Content” means all data, software, information, -text, audio files, graphic files, content, and other materials that you upload, post, deliver, provide, or otherwise transmit or store in connection with or relating to the Service submitted by or for Licensee to the Service or collected and processed by or for Licensee using the Service, excluding Codefresh Content and Non-Codefresh Applications.
- -(vi) “Malicious Code” means code, files, scripts, agents, or programs intended to do harm, including, for example, viruses, worms, time bombs and Trojan horses.
- -(vii) “Non-Codefresh Application(s)” means a web-based or offline software application that is provided by Licensee or a third party and interoperates with the Service.
- -(viii) “Order” means a Service order form, other ordering document, web-based, or email-based ordering mechanism or registration process for the Service.
- -(ix) “Service” means the Site, including related services provided through the site, or the Software.
- -(x) “Site” means Codefresh’s website, located at https://support.codefresh.io.
- -(xi) “SLA” means the “service level agreement” in effect as of the Order’s Effective Date, which can be found at https://codefresh.io/docs/docs/terms-and-privacy-policy/privacy-policy/.
- -(xii) “Software” means any software developed and made available to Licensee as set forth in an applicable Order, which may include Codefresh’s build, test, and deployment docker container software tools, services, and related technologies.
- -(xiii) “User” means an individual who is authorized by Licensee to use the Service, for whom Licensee (or Codefresh at Licensee’s request) has supplied a user identification and password either manually or using a Non-Codefresh Application. Users may include Licensee’s employees, consultants, contractors, agents, and third parties that Licensee transacts business with.
- -1.2. Codefresh may provide its Services to you through the Site or on-premises as set forth in an applicable Order. By entering into an Order or otherwise downloading, accessing, or using the Service, Licensee unconditionally accepts and agrees to, and represents that it has the authority to bind itself and its affiliates -to, all of these Terms.
- - - -2. CLOUD-BASED SERVICES.
- -2.1. Scope of Service. For all cloud-based Services provided via Codefresh’s remote platform hereunder (such platform, the “Codefresh Cloud”), the “Scope” shall mean both the authorized number of Users and number of Cloud Credits (as defined below) set forth in the applicable Order.
- -2.2. Cloud Credits. Licensee may purchase Cloud Credits, which allow Users to use the Service on Codefresh Cloud in a specific capacity (each such unit, a “Cloud Credit”). Cloud Credits are available during the Term and expire upon termination. Cloud Credits are not redeemable for cash and are not refundable as cash under any circumstances. Cloud Credits are not transferable and may only be applied to Licensee’s account. Cloud Credits usage will be calculated based on the infrastructure size Licensee uses, as set out in the applicable Order, and as detailed in the below chart:
- -- -- - --
-- -Machine Size -CPU -Memory -Credit/minute -- -S -1 -1 GB -5 -- -M -2 -4 GB -10 -- -L -4 -8 GB -20 -- -XL -8 -16 GB -40 -- -XXL -16 -32 GB -80 -3. ON-PREMISES SERVICES.
- -3.1. Scope of Services. For all Services provided to Licensee on-premises by Codefresh (the “On-Premises Services”), the “Scope” shall mean the authorized number of Users as set forth in the applicable Order.
- -3.2. Equipment Maintenance. Licensee shall be responsible for obtaining and maintaining any equipment and ancillary services or tools needed to connect to, access or otherwise use the Service, including, without limitation, modems, hardware, server, software, operating system, networking, web servers, long distance, and local telephone service (collectively, “Equipment”). Licensee shall be responsible for ensuring that such Equipment is compatible with the Service (and, to the extent applicable, the Software) and complies with all configurations and specifications set forth in the Documentation.
- - -4. LICENSE AND RESTRICTIONS; LICENSEE AND USER OBLIGATIONS.
- -4.1. License. Subject to these Terms and payment of all fees described in an Order, during the Term Codefresh grants Licensee and each User a limited, non-sublicensable, non-exclusive, non-transferable license to use the object code of any Software and Codefresh Content solely in connection with the Service and any terms and procedures Codefresh may prescribe from time to time.
- -4.2. Restrictions. Subject to these Terms, Licensee and Users may access and use the Service and Codefresh Content only for lawful purposes. All rights, title, and interest in and to the Service and its components, Codefresh Content and all related intellectual property rights will remain with and belong exclusively to Codefresh. Licensee shall maintain the copyright notice and any other notices that appear on the Service on any copies and any media. Neither Licensee nor any User shall directly or indirectly (nor shall they allow any third party to) (i) modify, reverse engineer, or attempt to hack or otherwise discover any source code or underlying code, ideas, or algorithms of the Service (except to the extent that applicable law prohibits reverse engineering restrictions), (ii) sell, resell, license, sublicense, provide, lease, lend, use for timesharing, or service bureau purposes or otherwise use -or allow others to use the Service or Codefresh Content for the benefit of any third party, (iii) use the Service or Codefresh Content, or allow the transfer, transmission, export, or re-export of the Service or Content or portion thereof, in violation of any export control laws or regulations administered by the U.S. Commerce Department, OFAC, or any other government agency, (iv) use -the Service to store or transmit infringing, libelous, or otherwise unlawful or tortious material, or to store or transmit material in violation of third-party privacy or intellectual property rights, (v) use the Service to store or transmit Malicious Code, (vi) interfere with or disrupt the integrity or performance of the Service or its components, (vii) attempt to gain unauthorized access to the Service or its related systems or networks, (viii) permit direct or indirect access to or use of any Service or Codefresh Content in a way that circumvents a contractual usage limit, (ix) copy the Service or any part, feature, function or user interface thereof, access the Service in order to build a competitive product or service, or (x) use the Service for any purpose other than as expressly licensed herein.
- -4.3. Licensee Service Obligations. Any User of the Service must be thirteen (13) years old or older to use the Service. Licensee shall (i) ensure and be responsible for Users’ compliance with these Terms, (ii) be responsible for the quality and legality of Licensee Content and the means by which Licensee acquired Licensee Content, (iii) use commercially reasonable efforts to prevent unauthorized access to or use of the Service, and notify Codefresh promptly of any such -unauthorized access or use, (iv) use the Service only in accordance with the Codefresh’s Service documentation and applicable laws and government regulations, and (v) comply with terms of service of Non-Codefresh Applications with which Licensee uses the Service. Licensee and Users are responsible for maintaining the security of User’s accounts and passwords. Codefresh cannot and shall not be liable for any loss or damage from Licensee’s or any User’s failure to comply with this security obligation. Licensee and Users may not access the Service, if they are Codefresh’s direct competitor, except with Codefresh’s prior written consent. In addition, Licensee and Users may not access the Service for purposes of monitoring its availability, performance, or functionality, or for any other benchmarking or competitive purposes.
- -4.4. Enforcement. -Licensee shall promptly notify Codefresh of any suspected or alleged violation of these Terms and shall cooperate with Codefresh with respect to: (i) investigation by Codefresh of any suspected or alleged violation of these Terms and (ii) any action by Codefresh to enforce these Terms. Codefresh may, in its sole discretion, suspend or terminate any User’s access to the Service with or -without written notice to Licensee in the event that Codefresh reasonably determines that a User has violated these Terms. Licensee shall be liable for any violation of these Terms by any User.
- -4.5. Excess Use. Should Licensee use the Service beyond the applicable Scope (“Excess -Use”), Codefresh shall invoice Licensee for the Excess Use at Codefresh’s current pricing plans, such that Licensee is billed in accordance with the actual usage of the Service. To verify any Excess Use, and to extent Licensee uses On-Premises Services, Licensee will maintain, and Codefresh will be entitled to audit, any records relevant to Licensee's use of the Service -hereunder. Codefresh may audit such records on reasonable notice at Codefresh's cost (or if the audits reveal material non-compliance with these Terms, at Licensee's cost), including without limitation, to confirm number of Users and/or Excess Use.
- -5. TRIAL LICENSE.
- -From time to time, Licensee may be invited to try certain products at no charge for a free trial or evaluation period or if such products are not generally available to licensees (collectively, “Trial License”). Trial Licenses will be designated or identified as beta, pilot, evaluation, trial, or similar. Notwithstanding anything to the contrary herein, Trial Licenses are licensed for Licensee’s internal evaluation purposes only (and not for production use), are provided “as is” without warranty or indemnity of any kind and may be subject to additional terms. Unless otherwise -stated, any Trial Licenses shall expire thirty (30) days from the trial start date. Notwithstanding the foregoing, Codefresh may discontinue Trial Licenses at any time at its sole discretion and may never make any Trial Licenses generally available. Codefresh will have no liability for any harm or damage arising out of or in connection with any Trial Licenses.
- - - -6. PROVISION OF THE SERVICE; SUPPORT.
- -6.1. Account Generation. As part of the registration process, each User shall generate a username and password for its Account either manually or through a Non-Codefresh Application. Each User is responsible for maintaining the confidentiality of their login, password, and Account and for all activities that occur under any such logins or the Account. Codefresh reserves the right to access Licensee’s and any User’s Account in order to respond to Licensee’s and Users’ requests for technical support. Codefresh has the right, but not the obligation, to monitor the Service, Codefresh Content, or Licensee Content, to the extent CodeFresh has access. Licensee further agrees that Codefresh may remove or disable any Codefresh Content at any time for any reason (including, but not limited to, upon receipt of claims or allegations from third parties or authorities relating to such Codefresh Content), or for no reason at all.
- -6.2. Accessing the Service. Licensee and its Users may enable or log in to the Service via certain Non-Codefresh Applications, such as GitHub. By logging into or directly integrating these Non-Codefresh Applications into the Service, Codefresh Users’ may have access to additional features and capabilities. To take advantage of such features and capabilities, Codefresh may ask Users to authenticate, register for, or log into Non-Codefresh Applications on the websites of their respective providers. As part of such integration, the Non-Codefresh Applications will provide Codefresh with access to certain information that Users have provided to such Non-Codefresh Applications, and Codefresh will use, store, and disclose such information in accordance with Codefresh’s Privacy Policy located at https://codefresh.com/privacy/. The manner in which Non-Codefresh Applications use, store, and disclose Licensee and User information is governed solely by the policies of the third parties operating the Non-Codefresh Applications, and Codefresh shall have no liability or responsibility for the privacy practices or other actions of any third-party site or service that may be enabled within the Service. In addition, Codefresh is not responsible for the accuracy, availability, or reliability of any information, content, goods, data, opinions, advice, or statements made available in connection with Non-Codefresh Applications. As such, Codefresh shall not be liable for any damage or loss caused or alleged to be caused by or in connection with use of or reliance on any such Non-Codefresh Applications. Codefresh enables these features merely as a convenience and the integration or inclusion of such features does not imply an endorsement or recommendation.
- -6.3. Support. Codefresh will provide Licensee with maintenance and support services in -accordance with and subject to the SLA. Community-based support is also available via Codefresh’s Discuss site located at https://discuss.codefresh.com (or -successor URL) for the Service at no additional charge. Upgraded support is available if purchased pursuant to an Order.
- - - -7. FEES AND PAYMENT.
- -7.1. Licensee shall pay Codefresh the fees set forth in an Order in accordance with the terms set forth therein; provided that Codefresh may change any applicable fees upon thirty (30) days’ notice at any time and such new fees shall become effective for any subsequent renewal Term. All payments shall be made in U.S. dollars. -Any payments more than thirty (30) days overdue will bear a late payment fee of one and one-half percent (1.5%) per month or the maximum rate allowed by law, whichever is lower. In addition, Licensee will pay all taxes, shipping, duties, withholdings, and similar expenses, as well as all pre-approved out of pocket expenses incurred by Codefresh in connection with any consulting and/or support -services, promptly upon invoice. If Licensee is paying any fees by credit card, Licensee shall provide Codefresh complete and accurate information regarding the applicable credit card. Licensee represents and warrants that all such information is correct and that Licensee is authorized to use such credit card. Licensee will promptly update its account information with any changes (for -example, a change in billing address or credit card expiration date) that may occur. Licensee hereby authorizes Codefresh to bill such credit card in advance on a periodic basis in accordance with these Terms and the applicable Order, and Licensee further agrees to pay any charges so incurred.
- -7.2. For any upgrade in a subscription level for a month-to-month service plan, Codefresh shall automatically charge Licensee the new subscription fee, effective as of the date the service upgrade is requested and for each subsequent one-month recurring cycle pursuant to the billing method applicable to Licensee. If Codefresh is providing Licensee the Service pursuant to a yearly service plan, Codefresh will immediately charge Licensee any increase in subscription level plan cost pursuant to the billing method applicable to -Licensee, prorated for the remaining Term of Licensee’s yearly billing cycle; provided, however, any decrease in a subscription level plan cost shall only take effect upon the renewal date of the then current yearly service plan. Licensee’s downgrading its subscription level may cause the loss of features or capacity of Licensee’s Account. Codefresh does not accept any liability for such loss.
- -7.3.If any amount owing by Licensee under these Terms for the Service is thirty (30) or more days overdue (or ten (10) or more days overdue in the case of amounts Licensee has authorized Codefresh to charge to Licensee’s credit card), Codefresh may, in its sole discretion and without limiting its other rights and remedies, suspend Licensee’s and any User’s access to the Service and/or otherwise limit the functionality of the Service until such amounts are paid in full.
- -7.4. Licensee agrees that its purchases are not contingent on the delivery of any future functionality or features, or dependent on any oral or written public comments made by Codefresh regarding future functionality or features.
- - - -8. TERM; EXPIRATION AND TERMINATION.
- -8.1. These Terms shall continue in effect for the initial term and any renewal term as specified in an Order (collectively, the “Term”). If either party materially breaches these Terms, the other party shall have the right to terminate the applicable Order and, in the event that no Order exists, these Terms (and, in each case, all licenses granted herein) upon thirty (30) days (ten (10) days in the case of non-payment and immediately in the case of a material breach) written notice of any such breach, unless such breach is cured during such notice period. In the case of a free trial or Codefresh otherwise providing the Service at no cost to a Licensee, Codefresh shall have, upon Licensee or any -Users failing to use the Service for more than six (6) consecutive months, the right, in its sole discretion, to terminate all User Accounts of Licensee and terminate Licensee’s and all Licensee’s Users’ access to and use of the Service without notice. Upon expiration or termination of an Order or these Terms, Licensee shall immediately be unable access and use the Service, all Licensee Content -may be deleted from the Service at Codefresh’s sole discretion (such information cannot be recovered once Licensee’s Account or any User Account is -terminated) and Licensee shall return or destroy all copies of all Codefresh Content and all portions thereof in Licensee’s possession and so certify to -Codefresh, if such certification is requested by Codefresh. Any provision of these Terms that, by its nature and context is intended to survive, including provisions relation to payment of outstanding fees, confidentiality, warranties, and limitation of liability, will survive termination of these Terms.
- -8.2. Codefresh will promptly terminate without notice the accounts of Users that are determined by Codefresh to be “repeat infringer(s).” A repeat infringer is a User who has been notified of infringing activity more than twice and/or has had Licensee Content or Non-Codefresh Applications removed from the Service more -than twice.
- -9. WARRANTIES; DISCLAIMERS.
- -Codefresh represents and warrants that the Service will function in substantial compliance with the applicable Documentation. In order to be entitled to any remedy based on a purported breach of the foregoing representation and warranty, Licensee must inform Codefresh of the purported deficiency in the Service within thirty (30) days of the day on which Licensee first -becomes aware of the condition giving rise to such claim. EXCEPT AS EXPRESSLY SET FORTH HEREIN, THE SERVICE, SITE, CODEFRESH CONTENT, AND ALL SERVER AND NETWORK COMPONENTS ARE PROVIDED ON AN “AS IS” AND “AS AVAILABLE” BASIS. CODEFRESH EXPRESSLY DISCLAIMS ANY AND ALL WARRANTIES, WHETHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, IMPLIED WARRANTIES OF MERCHANTABILITY, -TITLE, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT. LICENSEE AND USERS ACKNOWLEDGE THAT CODEFRESH DOES NOT WARRANT THAT THE SERVICE WILL BE -UNINTERRUPTED, TIMELY, SECURE, ERROR-FREE OR VIRUS-FREE, NOR DOES CODEFRESH MAKE ANY WARRANTY AS TO THE RESULTS THAT MAY BE OBTAINED FROM USE OF THE SERVICE, AND NO INFORMATION, ADVICE, OR SERVICES OBTAINED BY LICENSEE OR USERS FROM CODEFRESH OR THROUGH THE SERVICE SHALL CREATE ANY WARRANTY NOT EXPRESSLY STATED IN THESE TERMS. THE SERVICE MAY BE TEMPORARILY UNAVAILABLE FOR SCHEDULED MAINTENANCE OR FOR UNSCHEDULED EMERGENCY MAINTENANCE, EITHER BY CODEFRESH OR BY THIRD-PARTY PROVIDERS, OR BECAUSE OF CAUSES BEYOND CODEFRESH’S REASONABLE CONTROL. CODEFRESH SHALL USE REASONABLE EFFORTS TO PROVIDE ADVANCE NOTICE OF ANY SCHEDULED SERVICE DISRUPTION.
- -10. INDEMNIFICATION.
- -10.1. Licensee will indemnify, defend and hold harmless Codefresh and its officers, directors, employee and agents, from and against any third-party claims, disputes, demands, liabilities, damages, losses, and costs and expenses, including, without limitation, reasonable legal and professional fees, arising out of or in any way connected with (i) Licensee’s or User’s access to or use of the Service that is in violation of law or this Agreement, or (ii) the Licensee Content as provided to Codefresh that is in violation of law or this Agreement, provided that Codefresh: (a) promptly notifies Licensee in writing of the claim; (b) grants Licensee sole control of the defense and settlement of the claim; and (c) provides Licensee, at Licensee’s expense, with all assistance, information and authority reasonably required for the defense and settlement of the claim.
- -10.2 Codefresh will indemnify, defend and hold harmless Licensee and its officers, directors, employee and agents, from and against any claims, disputes, demands, liabilities, damages, losses, and costs and expenses, including, without limitation, reasonable legal and professional fees, to the extent that it is based upon a third-party claim that the Service, as provided by under this Agreement and used within the scope of this Agreement, infringes or misappropriates any intellectual property right in any jurisdiction, and will pay any costs, damages and reasonable attorneys’ fees attributable to such claim that are awarded against Licensee, provided that Licensee: (i) promptly notifies Codefresh in writing of the claim; (ii) grants Codefresh sole control of the defense and settlement of the claim; and (iii) provides Codefresh, at Codefresh’s expense, with all assistance, information and authority reasonably required for the claim.If use of any of the Codefresh Content and/or the Service is, or in Codefresh’s reasonable opinion is likely to be, the subject of a claim specified in this Section, then Codefresh may, at its sole option and expense: (a) procure for Licensee the right to continue using the Codefresh Content and/or the Service; (b) replace -or modify the Codefresh Content and/or the Service so that it is non-infringing while maintaining substantially equivalent in function to the original Codefresh Content and/or the Service; or (c) if options (a) and (b) above cannot be accomplished despite Codefresh’s reasonable efforts, then Codefresh or Licensee may terminate this Agreement and Codefresh will provide pro rata refund of unused/unapplied fees paid in advance for any applicable subscription term. THE PROVISIONS OF -THIS SECTION 10.2 SET FORTH CODEFRESH’S SOLE AND EXCLUSIVE OBLIGATIONS, AND LICENSEE’S SOLE AND EXCLUSIVE REMEDIES, WITH RESPECT TO INDEMNIFICATION OBLIGATIONS FOR INFRINGEMENT OR MISAPPROPRIATION OF INTELLECTUAL PROPERTY RIGHTS OF ANY KIND. - -
11. LIMITATION OF LIABILITY.
- -EXCEPT FOR A LIABILITY ARISING FROM SECTION 4.2 OR A PARTY’S INDEMNITY OBLIGATIONS SET FORTH IN SECTION 10, EACH PARTY’S LIABILITY UNDER THIS AGREEMENT SHALL BE LIMITED TO THE FEES PAID OR PAYABLE BY LICENSEE TO CODEFRESH IN THE TWELVE (12) MONTHS PRECEDING THE EVENT GIVING RISE TO THE LIABILITY. THE PROVISIONS OF THIS SECTION SHALL APPLY WHETHER OR NOT THE LICENSEE HAS BEEN INFORMED OF THE POSSIBILITY OF SUCH DAMAGE, AND EVEN IF AN EXCLUSIVE REMEDY SET FORTH HEREIN IS FOUND TO HAVE FAILED OF ITS ESSENTIAL PURPOSE. UNDER NO CIRCUMSTANCES AND UNDER NO LEGAL THEORY (WHETHER IN CONTRACT, TORT OR OTHERWISE) SHALL EITHER PARTY BE LIABLE TO THE OTHER PARTY, ANY USER, OR ANY THIRD-PARTY FOR ANY INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, CONSEQUENTIAL OR PUNITIVE DAMAGES, INCLUDING LOST PROFITS, LOST SALES OR BUSINESS, LOST DATA, GOODWILL, OR OTHER INTANGIBLE LOSSES. THE PARTIES HAVE RELIED ON THESE LIMITATIONS IN DETERMINING WHETHER TO ENTER INTO THESE TERMS. IF APPLICABLE LAW DOES NOT ALLOW FOR CERTAIN LIMITATIONS OF LIABILITY, SUCH AS THE EXCLUSION OF IMPLIED WARRANTEES OR LIMITATION OF LIABILITY FOR INCIDENTAL OR CONSEQUENTIAL DAMAGES, THE PROVISIONS OF THIS SECTION 11 SHALL APPLY TO THE MAXIMUM EXTENT ALLOWABLE UNDER SUCH APPLICABLE LAW.
- -12. PROPRIETARY RIGHTS; LIMITED LICENSES TO CODEFRESH.
- -12.1. Intellectual Property Rights. Subject to the limited licenses expressly granted hereunder, Codefresh and its licensors reserve their respective right, title, and interest in and to the Service, including all of Codefresh’s and its licensors related intellectual property rights related to the Service (the “Intellectual Property Rights”). No rights are granted to Licensee hereunder other than as expressly set forth herein. Codefresh shall retain all right, title, and interest in and to Intellectual Property Rights, including any Software, all improvements, enhancements, modifications, and derivative works thereof, and all related Intellectual Property Rights.
- -12.2. License to Host Licensee Content. Licensee hereby grants Codefresh a worldwide, non-exclusive, royalty-free, fully paid, sublicensable, limited-term license to host, copy, transmit and display Licensee Content that Licensee or any User posts to the Service, solely as necessary for Codefresh to provide the Service in accordance with these Terms. Subject to the limited licenses granted herein, Codefresh acquires no right, title or interest from Licensee or Licensee’s licensors under these Terms in or to Licensee Content.
- -12.3. License to Use Feedback. Licensee hereby grants to Codefresh a worldwide, perpetual, irrevocable, royalty-free license to use and incorporate into the Service any suggestion, enhancement request, recommendation, correction, or other feedback provided by Licensee or Users relating to the operation of the Service.
- -13. CONFIDENTIALITY.
- -Any technical, financial, business or other information provided by one party (the “Disclosing Party”) to the other party (the “Receiving Party”) and designated as confidential or proprietary or that reasonably should be understood to be confidential given the nature of the information and the circumstances of disclosure (“Confidential Information”) shall be held in confidence and not disclosed and shall not be used except to the extent necessary to carry out the Receiving Party’s obligations or express rights hereunder, except as otherwise authorized by the -Disclosing Party in writing. For clarity, the Service and Codefresh Content shall be deemed Confidential Information of Codefresh whether or not otherwise designated as such. The Receiving Party shall use the same degree of care that it uses to protect the confidentiality of its own confidential information of like kind (but not less than a reasonable standard of care). These obligations -will not apply to information that (i) was previously known by the Receiving Party, as demonstrated by documents or files in existence at the time of disclosure, (ii) is generally and freely publicly available through no fault of the Receiving Party, (iii) the Receiving Party otherwise rightfully obtains from third parties without restriction, or (iv) is independently developed by the -Receiving Party without reference to or reliance on the Disclosing Party’s Confidential Information, as demonstrated by documents or files in existence at the time of disclosure. The Receiving Party may disclose Confidential Information of the Disclosing Party to the extent compelled by law to do so, provided the Receiving Party gives the Disclosing Party prior notice of the -compelled disclosure (to the extent legally permitted) and reasonable assistance, at the Disclosing Party’s cost, if the Disclosing Party wishes to contest the disclosure. If the Receiving Party is compelled by law to disclose the Disclosing Party’s Confidential Information as part of a civil proceeding to which the Disclosing Party is a party, and the Disclosing Party is not contesting the disclosure, the Disclosing Party will reimburse the Receiving Party for its reasonable cost of compiling and providing secure access to that Confidential Information. In the event that such protective order or other remedy is not obtained, the Receiving Party shall furnish only that portion of the Confidential Information that is legally required and use commercially reasonable efforts to obtain assurance that confidential treatment will be accorded the Confidential Information.
- -14. PROTECTION OF CONFIDENTIAL LICENSEE CONTENT; SECURITY.
- -14.1. Codefresh shall maintain administrative, physical, and technical safeguards for protection of the security, confidentiality and integrity of Licensee Content that is Licensee’s Confidential Information (“Confidential Licensee Content”). Those safeguards shall include, but will not be limited to, measures for preventing access, use, modification, or disclosure of Confidential Licensee Content by Codefresh’s personnel except (a) to provide the Service and prevent or address service or technical problems, (b) as compelled by law in accordance with Section 13 (Confidentiality) above, or (c) as Licensee expressly permits in writing.
- -14.2. Licensee understands that the operation of the Service, including Licensee Content, may involve (i) transmissions over various networks; (ii) changes to conform and adapt to technical requirements of connecting networks or devices; and (iii) transmission to Codefresh’s third-party vendors and hosting partners solely to -provide the necessary hardware, software, networking, storage, and related technology required to operate and maintain the Service. Accordingly, Licensee -acknowledges that Licensee bears sole responsibility for adequate backup of Licensee Content. Codefresh will have no liability to Licensee for any unauthorized access or use of any of Licensee Content, or any corruption, deletion, destruction, or loss of any of Licensee Content.
- -15. DISPUTE RESOLUTION.
- -15.1. This Agreement and any action related thereto will be governed by the laws of the State of California without regard to its conflict of laws provisions. Licensee and Codefresh irrevocably consent to the jurisdiction of, and venue in, the state or federal courts located in the County of San Francisco, California for any disputes arising -under this Agreement, provided that the foregoing submission to jurisdiction and venue shall in no way limit the obligation to arbitrate disputes set forth in Section 15.2.
- -15.2. Except for actions to protect a party’s intellectual property rights and to enforce an arbitrator’s decision hereunder, any controversy or claim arising out of or relating to this Agreement, or the breach thereof, shall be settled by arbitration administered by the American Arbitration Association (“AAA”) under its Commercial Arbitration Rules, or such applicable substantially equivalent rules as the AAA may adopt that are then in effect (the “AAA Rules”), and judgment on the award rendered by the arbitrator(s) may be -entered in any court having jurisdiction thereof. There shall be one arbitrator, and such arbitrator shall be chosen by mutual agreement of the parties in accordance with AAA Rules. The arbitration shall be conducted remotely to the extent practicable and otherwise in San Francisco, California. The arbitrator shall apply the laws of the State of California to all issues in dispute. The -controversy or claim shall be arbitrated on an individual basis and shall not be consolidated in any arbitration with any claim or controversy of any other party. The findings of the arbitrator shall be final and binding on the parties and may be entered in any court of competent jurisdiction for enforcement. Enforcements of any award or judgment shall be governed by the Federal Arbitration Act.
- -16. MISCELLANEOUS.
- -16.1. Assignment. Neither party may assign this Agreement without the other party’s prior written consent and any attempt to do so will be void, except that either party may assign this Agreement, without the other party’s consent, to a successor or acquirer, as the case may be, in connection with a merger, acquisition, sale of all or substantially all of such party’s assets or substantially similar transaction, provided, however, that Licensee may not assign this Agreement to a competitor or customer of Codefresh without Codefresh’s prior written consent. Subject to the foregoing, this Agreement will bind and benefit the parties and their respective successors and assigns.
- -16.2. Electronic Signature. The parties consent to using electronic signatures to sign this Agreement and to be legally bound to their electronic signatures. The parties acknowledge that his or her electronic signature will have the same legal force and effect as a handwritten signature.
- -16.3. Fees. In any action between the parties seeking enforcement of any of the terms and provisions of this Agreement, the prevailing party in such action shall be awarded, in addition to damages, injunctive or other relief, its reasonable costs and expenses, not limited to taxable costs, reasonable attorney’s fees, -expert fees, and court fees and expenses.
- -16.4. No Partnership or Joint Venture. The Agreement is not intended to be, and shall not be construed as, an agreement to form a partnership, agency relationship, or a joint venture between the parties. Except as otherwise specifically provided in the Agreement, neither party shall be authorized to act as an agent of or -otherwise to represent the other party.
- -16.5. Headings. Captions to, and headings of, the articles, sections, subsections, paragraphs, or subparagraphs of this Agreement are solely for the convenience of the parties, are not a part of this Agreement, and shall not be used for the interpretation or determination of the validity of this Agreement or any provision hereof.
- -16.6. Publicity. Licensee grants Codefresh the right to use Licensee’s company name and logo as a reference for marketing or promotional purposes on Codefresh’s website and in other public or private communications with its existing or potential customers, subject to Licensee’s standard trademark usage guidelines as provided -to Codefresh from time-to-time.
- -16.7. No Election of Remedies. Except as expressly set forth in this Agreement, the exercise by either party of any of its remedies under this Agreement will not be deemed an election of remedies and will be without prejudice to its other remedies under this Agreement or available at law or in equity or otherwise.
- -16.8. Notices. All notices required or permitted under this Agreement will be in writing, will reference this Agreement, and will be deemed given: (i) when delivered personally; (ii) one (1) business day after deposit with a nationally-recognized express courier, with written confirmation of receipt; (iii) three (3) business days after having been sent by registered or certified mail, return receipt requested, postage prepaid; or (iv) twenty-four (24) hours after having been sent via e-mail to the contact person at the address listed in each Order (or if to Codefresh, at legal@codefresh.io) unless a party notifies the other party in -writing of a change to the contact person and/or the contact person’s contact information. Email shall not be sufficient for notices of termination or an indemnifiable claim. All such notices will be sent to the addresses set forth above or to such other address as may be specified by either party to the other party in accordance with this Section.
- -16.9. Waiver & Severability. The failure by either party to enforce any provision of this Agreement will not constitute a waiver of future enforcement of that or any other provision. The waiver of any such right or provision will be effective only if in writing and signed by a duly authorized representative of each party. If any provision of this Agreement is held invalid or unenforceable by a court of competent jurisdiction, the remaining provisions of this Agreement will remain in full force and effect, and the provision affected will be construed so as to be enforceable to the maximum extent permissible by law.
- -16.10. Entire Agreement. This Agreement, together with the SLA and any subsequently executed Order(s), constitutes the complete and exclusive agreement of the parties with respect to its subject matter and supersedes all prior understandings and agreements, whether written or oral, with respect to its -subject matter. Any waiver, modification, or amendment of any provision of this Agreement will be effective only if in writing and signed by the parties hereto.
- -16.11. Force Majeure. Neither party will be responsible for any failure or delay in its performance under this Agreement due to causes beyond its reasonable control, including, but not limited to, labor disputes, strikes, lockouts, shortages of or inability to obtain labor, energy, raw materials or supplies, war, acts of terror, riot, acts of God or governmental action.
- -16.12. Counterparts. This Agreement may be executed in counterparts, each of which will be deemed an original, but all of which together will constitute one and the same instrument.
- -16.13. Updating Terms. As its business evolves, Codefresh may change these Terms (not including any then-current, active Orders) from time to time. Licensee may review the most current version of these Terms at any time by visiting https://codefresh.io/docs/docs/terms-and-privacy-policy/terms-of-service/ and by visiting the most current versions of the other pages that are referenced in the Agreement. All changes will become effective upon posting of the change. If Client (or any User) accesses or uses the Services after the effective date, that use will constitute Client’s acceptance of any revised terms and conditions. Codefresh may change these Terms from time to time by providing Licensee and Users at least thirty (30) days’ notice either by emailing the email address associated with Licensee’s or User’s account or by posting a notice on the Service.
- -
- -Terms last updated May 12, 2022
-{:/} - diff --git a/_docs/troubleshooting/common-issues.md b/_docs/troubleshooting/common-issues.md deleted file mode 100644 index 525a88da..00000000 --- a/_docs/troubleshooting/common-issues.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: "Common issues" -description: "" -group: troubleshooting -redirect_from: - - /docs/common-issues/ - - /docs/troubleshooting/ -toc: true ---- -In this section, we offer helpful information about issues you may encounter and questions you might have. - -## General usage issues - -- [Non admin users can are thrown out back to classic Codefresh]({{site.baseurl}}/docs/troubleshooting/common-issues/non-admin-users-support/) - - - - - - - diff --git a/_docs/troubleshooting/common-issues/non-admin-users-support.md b/_docs/troubleshooting/common-issues/non-admin-users-support.md deleted file mode 100644 index 91f8e648..00000000 --- a/_docs/troubleshooting/common-issues/non-admin-users-support.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -title: "Non admin users can are thrown out back to classic Codefresh" -description: "" -group: troubleshooting -sub_group: common-issues -toc: true ---- - -For the time being only admin users of your account will be able to use Codefresh Argo Platform. - -The reason for this is that the roles and permissions model has not yet been released and thus all users are able to view all entities. - -The roles and permissions model will be released before going into GA. diff --git a/_docs/troubleshooting/runtime-issues.md b/_docs/troubleshooting/runtime-issues.md deleted file mode 100644 index 31b2a2c0..00000000 --- a/_docs/troubleshooting/runtime-issues.md +++ /dev/null @@ -1,94 +0,0 @@ ---- -title: "Runtimes" -description: "" -group: troubleshooting -toc: true ---- - - -#### Pre-installation checks or runtime collision check failed - -**Possible cause** - You have Argo Project components from other installations in your cluster. - -**Possible actions** - 1. Uninstall the Codefresh runtime. - 1. Remove the Argo Project components from your cluster. - 1. Reinstall the Codefresh runtime. - -#### Pre-installation error: please upgrade to the latest cli version: `v` - -**Possible cause** - Codefresh has a new CLI version. - -**Possible actions** -Run the appropriate command to upgrade to the latest version: - - {: .table .table-bordered .table-hover} -| Download mode | OS | Command | -| -------------- | ----------| ----------| -| `Curl` | MacOS-x64 | `curl -L --output - https://github.com/codefresh-io/cli-v2/releases/latest/download/cf-darwin-amd64.tar.gz | tar zx && mv ./cf-darwin-amd64 /usr/local/bin/cf && cf version`| -| | MacOS-m1 |`curl -L --output - https://github.com/codefresh-io/cli-v2/releases/latest/download/cf-darwin-arm64.tar.gz | tar zx && mv ./cf-darwin-arm64 /usr/local/bin/cf && cf version` | -| | Linux - X64 |`curl -L --output - https://github.com/codefresh-io/cli-v2/releases/latest/download/cf-linux-amd64.tar.gz | tar zx && mv ./cf-linux-amd64 /usr/local/bin/cf && cf version` | -| | Linux - ARM | `curl -L --output - https://github.com/codefresh-io/cli-v2/releases/latest/download/cf-linux-arm64.tar.gz | tar zx && mv ./cf-linux-arm64 /usr/local/bin/cf && cf version`| -| `Brew` | N/A| `brew tap codefresh-io/cli && brew install cf2`| - -#### Failed to bootstrap repository: authentication required -**Possible cause** -The Git token provided for runtime installation is not valid. - -**Possible actions** -* Make sure the token: - * Has a valid expiration date. - * Scope includes `repo` and `admin-repo.hook` - -#### Failed adding git integration <...> 404 not found - -**Possible cause** -Another process is probably occupying the address you provided as your `ingress-host`. - -**Possible actions** -* Terminate the process to free up the address. - -#### Failed to create default git integration:...failed making a graphql API call...the HTTP request failed - -**Possible cause** - The Ingress controller does not have a valid SSL certificate. The certificate must be from a Certificate Authority. - -**Possible actions** -1. Get a valid CA-signed certificate for the Ingress controller. -1. Run the runtime installation. - -_OR_ - -* Continue with the runtime installation in `insecure` mode: - - `cf intg git add default --api-url https://api.github.com --runtime --insecure` - where: - ` ` is the name of the runtime installation. - -#### Failed to create default git integration:...GraphQL Error (Code: 401): ("response":{"error":"Unauthorized: Invalid token."status":401, "headers":{}}..) -**Possible cause** - The ingress host specified does not point to the cluster selected for runtime installation. - -**Possible actions** -Make sure the ingress host points to the cluster on which the runtime is installed. - - -#### Timeout error, either for applications or while waiting for the installation to complete -**Possible cause** - `Cron-executer` has identified that not all your applications are synced and healthy. - Codefresh runtime installation syncs app status at 10-minute intervals. The timeout occurs if after the last status sync, at least one application is either not synced or healthy. - -**Possible actions** - -Without terminating the runtime install, do the following: - -1. In the Argo CD UI, check the status of your apps: - * Port forward your `argo-cd server` pod using default 8080 ports. - * Access it via `localhost:8080` with the Username `admin`, and Password which is the decoded `argocd-initial-admin-secret` in your cluster. - > With `k9s`, in the `secrets` view, press `x`. -1. If all apps are perfectly synced and healthy, check the logs of the `cron-executor` service. -1. If the logs don't show a cause for the error, try freeing up resources: - * Free up memory with `docker system prune -a --volumes`. - * Increase the resources allocated to your cluster. \ No newline at end of file diff --git a/_docs/whats-new/whats-new.md b/_docs/whats-new/whats-new.md deleted file mode 100644 index aa22dce0..00000000 --- a/_docs/whats-new/whats-new.md +++ /dev/null @@ -1,1347 +0,0 @@ ---- -title: "What's new in Codefresh?" -description: "" -group: whats-new -redirect_from: - - /docs/whats-new/ -toc: true ---- - -Built on Argo, the world’s most popular and fastest-growing open source software delivery, Codefresh unlocks the full enterprise potential of Argo Workflows, Argo CD, Argo Events, and Argo Rollouts, providing a control-plane for managing them at scale. - - - -## October 2022 - -### Features & enhancements -{::nomarkdown} -
-{:/} - -#### Kubernetes version runtime support -We now support Kubernetes server versions 1.21 and higher. - -{::nomarkdown} -
-{:/} - -#### Request Routing Service for runtimes -We have changed the routing mechanism for hybrid runtimes. URL requests and webhooks are now routed through a new internal routing service instead of through the ingress controller. - -The change is effective from runtime version 0.0.543 and higher. If you already have runtimes installed, this change does not require any action from you, both to upgrade to the new runtime version or retain existing runtimes. Older runtimes continue to use the ingress controller for routing purposes. - -See [Hybrid runtime architecture]({{site.baseurl}}/docs/getting-started/architecture/#hybrid-runtime-architecture) and [Request Routing Service]({{site.baseurl}}/docs/getting-started/architecture/#request-routing-service). - -{::nomarkdown} -
-{:/} - -#### More Git providers for runtimes -Codefresh runtimes now support GitHub Enterprise, GitLab, and Bitbucket as Git providers, apart from GitHub, which is the default. - -When installing the first hybrid or hosted runtime for your account, you can define the Git provider of choice. Because Codefresh creates a configuration repository that is shared with subsequent runtimes in the same account, you cannot change the Git provider for a different runtime in the same account. - -Each Git provider requires runtime tokens with specific scopes and has specific installation requirements. Once installed, you can authorize access to the Git provider through OAuth or a personal access token. - -Note that GitLab cloud is not supported for hosted runtimes. - -See [Git provider and repo flags]({{site.baseurl}}/docs/runtime/installation/#git-provider-and-repo-flags). - -{::nomarkdown} -
-{:/} - -#### Turn off notifications for runtimes -Codefresh alerts you to runtimes that are insecure or have invalid or expired Git personal access tokens. You can turn off these notifications selectively for runtimes for which these alerts are less critical, such as non-production runtimes. - -The option is user-specific, and applies only to runtimes in the user's account. - - -{% include - image.html - lightbox="true" - file="/images/whats-new/rel-notes-oct22-dismiss-runtime-notifications.png" - url="/images/whats-new/rel-notes-oct22-dismiss-runtime-notifications.png" - alt="Turn off notifications for selected runtime" - caption="Turn off notifications for selected runtime" - max-width="80%" -%} - -Runtimes with disabled notifications are prefixed with an icon as in the picture below. - -{% include - image.html - lightbox="true" - file="/images/whats-new/rel-notes-oct22-dimiss-notifications-indication.png" - url="/images/whats-new/rel-notes-oct22-dimiss-notifications-indication.png" - alt="Runtime with disabled notifications" - caption="Runtime with disabled notifications" - max-width="80%" -%} - -{::nomarkdown} -
-{:/} - -#### Rollout Player for deployments -Managing ongoing rollouts during a deployment is now simple with the Rollout Player. Clicking the rollout name in Timeline > Updated Services, displays both the visualization of the steps in the rollout and the Rollout Player. With the Rollout Player you can control individual steps in an ongoing rollout and even promote the rollout to a release. - -{% include - image.html - lightbox="true" - file="/images/whats-new/rel-notes-oct-22-rollout-player.png" - url="/images/whats-new/rel-notes-oct-22-rollout-player.png" - alt="Rollout Player" - caption="Rollout Player" - max-width="40%" -%} - - -The Rollput Player allows you to: -* Resume an indefinitley paused step -* Forward a step by skipping its execution -* Promote the rollout to deployment by skipping remaining pause, analysis - -{::nomarkdown} -
-{:/} - -#### Context menu for application resources -We have enhanced the functionality for application resources in the Current State tab with the context menu for resources. The options available differ according to the type of resource. - - - -**On-demand sync for individual application resources** -Sync is a context menu option available for all resources that track sync status. You can sync individual resources as needed or when out-of-sync without synchronizing or refreshing the application. - -{% include - image.html - lightbox="true" - file="/images/whats-new/rel-notes-oct-22-sync-context-menu.png" - url="/images/whats-new/rel-notes-oct-22-sync-context-menu.png" - alt="Sync option in resource context menu" - caption="Sync option in resource context menu" - max-width="50%" -%} - -**Rollout resource actions** -The context menu for `rollout` resource types have actions to control the rollout. - -{% include - image.html - lightbox="true" - file="/images/whats-new/rel-notes-oct22-rollout-context-menu.png" - url="/images/whats-new/rel-notes-oct22-rollout-context-menu.png" - alt="Context menu options for Rollout resource" - caption="Context menu options for Rollout resource" - max-width="50%" -%} - -{::nomarkdown} -
-{:/} - -#### Other enhancements - -**Git Sources as Application Type filter** -The list of filters for Application Type in the Applications dashboard includes the Git Source filter. Filtering by Git Source shows `Git Source Apps` which are applications created by Codefresh that store definitions of Argo Project resources. - -{% include - image.html - lightbox="true" - file="/images/whats-new/rel-notes-oct22-app-type-git-source.png" - url="/images/whats-new/rel-notes-oct22-app-type-git-source.png" - alt="Git Source as Application Type filter" - caption="Git Source as Application Type filter" - max-width="40%" -%} - - -**Manifests for Analysis Runs** -Analysis Run now shows the manifest in addition to the run results. - -{% include - image.html - lightbox="true" - file="/images/whats-new/rel-notes-oct22-analysis-run-manifest.png" - url="/images/whats-new/rel-notes-oct22-analysis-run-manifest.png" - alt="Manifest for Analysis Run" - caption="Manifest for Analysis Run" - max-width="40%" -%} - -{::nomarkdown} -
-{:/} - -### Bug fixes - -{::nomarkdown} -
-{:/} - -**Runtimes** - -* 500: Internal Server Error when adding cluster command to hosted runtime. -* Commit SHA link in Activity Log goes to the Home page instead of to the Commit URL for the Git provider. -* Ingress controller errors for cluster even when `skip-ingress` flag is defined. -* Retry mechanism requests cause delay in Git integration checks. -* For hosted runtimes, Git Source is not displayed though the Connect to Git provider step is marked as complete. -* No option to log out on selecting invalid authentication mode. -* Removing a managed cluster does not display any indication in Codefresh UI. -* Up-to-date runtimes display upgrade indication. - - -{::nomarkdown} -
-{:/} - -**Applications** -* Applications deleted in Git displayed as errors, or as Missing in Codefresh. -* Tagging/untagging favorite application breaks relationship to parent application. -* Application definitions validation for cluster URL that does not exist shows wrong entity type. -* Incorrect number of replicas for previous image in Applications dashboard. -* Mismatch between information reported for cluster and namespace in Applications dashboard and Images. -* Source link in Timeline tab redirects to incorrect branch. -* Missing Health indication for Argo Rollouts in Codefresh UI. - -{::nomarkdown} -
-{:/} - -**Delivery Pipelines and workflows** -* 100% CPU consumption for workflows with more than 20 nodes. -* Discard Changes button enabled when there are no changes. - - -## September 2022 - - - -### Features & enhancements -{::nomarkdown} -
-{:/} - -#### Enriched application header -Every application includes a header that highlights key information and links to key aspects of the application. For example, you can see both the current sync state and the result of the previous sync operation, with links to pull-out panels including additional details. - - -{% include - image.html - lightbox="true" - file="/images/whats-new/rel-notes-sep22-app-header.png" - url="/images/whats-new/rel-notes-sep22-app-header.png" - alt="Application header for selected appplication" - caption="Application header for selected appplication" - max-width="80%" -%} - -#### Refresh and hard refresh to manage applications -Just as you can manually synchronize applications directly in Codefresh, you can now perform Refresh and Hard Refresh for applications. -In the Applications dashboard, both options are available in the context menu of each application. On selecting an application, you can see them on the top-right next to the Synchronize button. - - -{% include - image.html - lightbox="true" - file="/images/whats-new/rel-notes-sep22-refresh-hardrefresh.png" - url="/images/whats-new/rel-notes-sep22-refresh-hardrefresh.png" - alt="Refresh/Hard refresh options for selected application" - caption="Refresh/Hard refresh options for selected application" - max-width="80%" -%} - - - -#### Click resume indefinitely paused rollouts -Argo Rollouts allows you to pause a rollout indefinitely and resume it manually instead of automatically after a fixed duration. Manually resuming a rollout is generally done through the CLI. -Codefresh provides you the option of resuming an indefinitely paused rollout directly from the Applications dashboard in Codefresh, with a single click. - -In the Timelines tab of the selected application, an ongoing rollout that is indefinitely paused displays the pause button. Resuming the rollout is as simple as clicking the pause button. - - -{% include - image.html - lightbox="true" - file="/images/whats-new/rel-notes-sep22-resume-pause.png" - url="/images/whats-new/rel-notes-sep22-resume-pause.png" - alt="Resume indefinitley paused rollout" - caption="Resume indefinitley paused rollout" - max-width="60%" -%} - -#### Custom path for application resources -When creating applications, in addition to changing the name of the manifest, you can now also define the path for the manifest within the Git Source. Use the front slash (/) to add subfolders to the path. The resource is created in the Git Source you select, according to the path you defined. - -{% include - image.html - lightbox="true" - file="/images/whats-new/rel-notes-sep22-app-yaml-location.png" - url="/images/whats-new/rel-notes-sep22-app-yaml-location.png" - alt="Define location for application YAML" - caption="Define location for application YAML" - max-width="60%" -%} - - - -#### Events tab for applications -In the previous month's release, we added the Events panel displaying successful and events for the application. -For more visibility and easier access, the same Events tab is now displayed with the Current State, Timeline, Services, and Configuration tabs for the selected application. - - -{% include - image.html - lightbox="true" - file="/images/whats-new/rel-notes-sep22-events-tab.png" - url="/images/whats-new/rel-notes-sep22-events-tab.png" - alt="Events tab for application" - caption="Events tab for application" - max-width="60%" -%} - - -### Bug fixes - -{::nomarkdown} -
-{:/} - -**Runtimes** -* Incorrect status for Hosted runtime when app-proxy is unreachable. -* Git provider not registered for hosted runtimes with Git Sources defined in the shared configuration repo. -* Authentication failure between platform and app proxy. -* Adding cluster to a runtime shows an error even when the cluster is added to the runtime. -* Duplicate dates in Activity Log notifications. -* Argo CD fails to connect to K8s 1.24 clusters. -* After uninstalling a runtime, argo-rollouts and rollout-reporter files remain for managed cluster remain in shared configuration repo. -* Deleted managed cluster shows as Unknown. - -{::nomarkdown} -
-{:/} - -**Applications** -* Health status does not change to progressing when previously degraded. -* Wrong git source reference -* Git Source applications in the Applications dashboard not reflected in the Runtimes > Git Source tab. -* Switching from YAML to form view after changing fields does not update validations. -* App details drawer crashes when application does not have resources. -* Missing namespace for resources. -* Full Screen does not work in Safari. -* Recreating an application with the same name as that of a deleted application displays incorrect data for rollouts in the Timeline tab. -* In the Timeline tab, data for a new release with long sync duration is assigned to the previous release. - - -## August 2022 - -### Features & enhancements - -#### GitHub Container Registry -In this release, we added support for GitHub Container Registry (GHCR), a popular container registry tool. The settings for GitHub Container registry integration are identical to that of the other container registry integrations: the integration name, the runtimes to share the integration with, and the domain, username, and token. -You also have the Test Connection option to test credentials before committing the changes. -Once defined, you can reference the integration by name in the CI platforms. - -{% include - image.html - lightbox="true" - file="/images/whats-new/rel-notes-aug22-github-cr.png" - url="/images/whats-new/rel-notes-aug22-github-cr.png" - alt="GitHub Container registry integration" - caption="GitHub Container registry integration" - max-width="70%" -%} - -See [GitHub Container registry]({{site.baseurl}}/docs/integrations/ci-integrations/container-registries/github-cr/). - -#### Labels and annotations for managed clusters -The Codefresh CLI supports labels and annotations for managed clusters. -When you add a managed cluster in Codefresh, you can optionally add labels and annotations with the `--labels` and the `--annotations` flags. Codefresh supports the standard key-value formats for both, with multiple items separated by `,`. K8s rules for labels and annotations are valid here as well. - -See [Adding a managed cluster with Codefresh CLI]({{site.baseurl}}/docs/runtime/managed-cluster/#add-a-managed-cluster-with-codefresh-cli), and [Adding a managed cluster with Kustomize]({{site.baseurl}}/docs/runtime/managed-cluster/#add-a-managed-cluster-with-kustomize). - -#### Event information for application resources -View events for application resources directly in Codefresh. -While the Applications dashboard flags errors in all applications at the global level, the Events tab isolates successful and failed events per resource within an application, useful for resources such as pods. - -Instead of having to navigate to Argo CD to view events for an application resource, clicking the resource in the Current State view in Codefresh displays the Events tab for that resource. Events are displayed in descending order, with the most recent event displayed first. - - -{% include - image.html - lightbox="true" - file="/images/whats-new/rel-notes-aug22-events-tab.png" - url="/images/whats-new/rel-notes-aug22-events-tab.png" - alt="Events tab for application in Current State" - caption="Events tab for application in Current State" - max-width="60%" -%} - -#### Quick View for applications -Similar to the detailed views for application resources, Codefresh offers a detailed view also for the application itself. -The Quick View for an application, collates definition, deployment, and event information, in the same location. The information is grouped into tabs for intuitive viewing: Summary, Metadata, Parameters, Sync Options, Manifest, and Events (as in the picture below). - -Easily access the Quick View either by selecting Quick View from the application’s context menu in the Applications dashboard, or by clicking the application resource in the Current State view. - -{% include - image.html - lightbox="true" - file="/images/whats-new/rel-notes-aug22-quickview-events.png" - url="/images/whats-new/rel-notes-aug22-quickview-events.png" - alt="Application Quick View: Events tab" - caption="Application Quick View: Events tab" - max-width="40%" -%} - -See [Application Quick View]({{site.baseurl}}/docs/deployment/applications-dashboard/#application-quick-view). - - - -#### Usability enhancements for applications -**Context menu for applications** -Every application in the Applications dashboard includes a new context menu with access to frequently-used and useful options such as Quick View, synchronize, and edit applications. - - -{% include - image.html - lightbox="true" - file="/images/whats-new/rel-notes-aug22-new-app-nav.png" - url="/images/whats-new/rel-notes-aug22-new-app-nav.png" - alt="Tab order on application drilldown" - caption="Tab order on application drilldown" - max-width="70%" -%} - - -**Validations before commit with intuitive error message** -Codefresh validates Source, Destination, and Advanced Settings such as the Argo CD Project, when you create or update applications, _before_ committing the changes. -For easy identification, the section with the error is also highlighted in the Form, not only in the YAML manifest. For example, if the Revision or Path is missing in the General settings, the section is highlighted in red and the message displayed includes details on the possible reasons for the error. - -{% include - image.html - lightbox="true" - file="/images/whats-new/rel-notes-aug22-app-validation-errors.png" - url="/images/whats-new/rel-notes-aug22-app-validation-errors.png" - alt="Validation errors in Form mode for application" - caption="Validation errors in Form mode for application" -max-width="60%" -%} - -#### Miscellaneous changes - -{: .table .table-bordered .table-hover} -| Item | Description | -| ---------- | -------- | -| `CF_HOST` | Deprecated from v 0.0.460 and higher in CI integrations. Recommend using `CF_RUNTIME_NAME` instead. See [CI integrations argument reference]({{site.baseurl}}/docs/integrations/ci-integrations/#ci-integration-argument-reference). | -| `GHCR_GITHUB_TOKEN_AUTHENTICATION` | New value for `CF_CONTAINER_REGISTRY_INTEGRATION` argument. Can be selected for GitHub Container (GHCR) registries even when you don’t have a GHCR integration in Codefresh. See [GitHub Action-Codefresh integration arguments]({{site.baseurl}}/docs/integrations/ci-integrations/github-actions/#github-action-codefresh-integration-arguments).| - - - -### Bug fixes - -**Runtimes** -* Uninstalling runtime does not remove the integrations shared with the runtimes. -* Uninstalling a hosted or hybrid runtime does not remove it from the shared configuration repository. -* Unable to install Argo Rollouts on clusters with long cluster names. -* Empty Argo CD logs with "http internal error" in Codefresh. -* 500 status code on using default GKE/EKS context/cluster names. - -**Applications** -* Trying to commit an application that already exists results in a commit failure. - -**Images** -* Filters are not retained on navigating away from the Images dashboard. - -**Pipelines, workflows and Workflow Templates** - -* Workflow Template filter does not work for Git Source. -* Missing validation for `WORKFLOW_NAME` variable. -* Incorrect sync history date for Workflow Templates. -* Error on detaching predefined filters in pipelines. - -**Integrations** -* Docker Hub integration list appears empty until refreshed even when there are integrations. -* Test Connection option disabled when integration name is not defined. - - - - -## July 2022 - -### Features & enhancements - -#### Hosted GitOps -Codefresh has launched Hosted GitOps, our newest offering, a hosted and managed version of Argo CD. - -From application analytics, to application creation, rollout, and deployment, you get the best of both worlds: Argo CD with Codefresh's advanced functionalities and features for CD operations. -What it also means is easy set up and zero maintenance overhead. - -Read on for a summary of what you get with Hosted GitOps. - -**Hosted runtime** -Hosted GitOps supports hosted runtimes. The runtime is hosted on a Codefresh cluster and managed by Codefresh. Codefresh guides you through the three-step process of setting up your hosted environment. Read more in [Hosted runtime](#hosted-runtime). - -**Dashboards for visibility and traceability** -Here's a recap of Codefresh dashboards, including a brand new dashboard dedicated to DORA metrics: -* Home dashboard: For global analytics and system-wide deployment highlights, start with the Home dashboard. -* DORA metrics: A _new_ dashboard for DORA metrics and DevOps quantification. Read more in [DORA metrics](#dora-metrics). -* Applications dashboard: Easily track deployments and visualize rollouts across clusters and runtimes in the Applications dashboard. - -**Application lifecycle management** -Manage the entire application lifecycle directly in Codefresh, from creating, editing, and deleting applications. -Define all application settings in a single location through the intuitive Form mode or directly in YAML, and commit all changes to Git. - -Synchronize applications manually when needed. Read more in [On-demand app synchronization](#on-demand-app-synchronization). - -**Integrations for image enrichment** -With Hosted GitOps, you can integrate your CI tools with Codefresh for image enrichment. Read more in [Integrations for image enrichment](#integrations-for-image-enrichment) - -{::nomarkdown} -
-{:/} - -#### Hosted runtime -Hosted GitOps supports a GitHub-based SaaS runtime, hosted on a Codefresh cluster, and managed by Codefresh. -Setting up your hosted environment takes just a few clicks. All you need is a Codefresh account, a Git account, and a Kubernetes cluster to which to deploy your applications. - -{% include - image.html - lightbox="true" - file="/images/whats-new/rel-notes-jul22-hosted-initial-view.png" - url="/images/whats-new/rel-notes-jul22-hosted-initial-view.png" - alt="Hosted runtime setup" - caption="Hosted runtime setup" - max-width="80%" -%} - -Codefresh guides you through the simple three-step process of provisioning your hosted runtime. From that point, Codefresh handles administration and maintenance of the hosted runtime, including version and security updates. - -See [Set up a hosted (Hosted GitOps) environment]({{site.baseurl}}/docs/runtime/hosted-runtime/). - -{::nomarkdown} -
-{:/} - -#### DORA metrics -DORA metrics have become integral to enterprises wanting to quantify DevOps performance, and Codefresh has out-of-the-box support for it. - -The DORA dashboard in Codefresh goes beyond quantification, with features such as the Totals bar displaying key metrics, filters that allow you to pinpoint just which applications or runtimes are contributing to problematic metrics, show metrics for starred applications, and the ability to set a different view granularity for each DORA metric. - -{% include - image.html - lightbox="true" - file="/images/whats-new/rel-notes-jul22-dora-metrics.png" - url="/images/whats-new/rel-notes-jul22-dora-metrics.png" - alt="DORA metrics" - caption="DORA metrics" - max-width="60%" -%} - -See [DORA metrics]({{site.baseurl}}/docs/reporting/dora-metrics/). - -{::nomarkdown} -
-{:/} - -#### Integrations for image enrichment -If you have our Hosted GitOps for CD and a different tool for CI, you can continue to enrich images, retaining your CI tools. Allow Codefresh to retrieve and report the image information in your deployments by connecting your CI tools to Codefresh. Connect CI tools, issue tracking tools, container registries, and more. - - -This release introduces our integration offering, starting with: -* GitHub Actions, Jenkins, and Codefresh Classic for CI -* Jira for issue tracking -* Docker Hub, Quay, JFrog Artifactory for container registries - -{% include - image.html - lightbox="true" - file="/images/whats-new/rel-notes-jul22-github-action-settings.png" - url="/images/whats-new/rel-notes-jul22-github-action-settings.png" - alt="Image enrichment with GitHub Actions integration" - caption="Image enrichment with GitHub Actions integration" - max-width="60%" -%} - - We are continually expanding the range of integrations, so stay tuned for release announcements on new integrations. - -Codefresh encrypts the credentials for every integration you create, and stores them securely as Kubernetes Sealed Secrets, ensuring that the integration flow is completely GitOps-compatible. Pipelines reference the integration by the integration name instead of integration credentials. Codefresh retrieves enrichment information using the encrypted Kubernetes secrets. - -See [Image enrichment with integrations]({{site.baseurl}}/docs/integrations/image-enrichment-overview/). - -{::nomarkdown} -
-{:/} - -#### Edit and delete applications - -Application management has become easier as you can now edit and delete applications directly in Codefresh. - -Update General and Advanced settings for application. Go directly to the Configuration tab for the application by selecting Edit in the Applications dashboard. - - -{% include - image.html - lightbox="true" - file="/images/whats-new/rel-notes-jul22-edit-app-option.png" - url="/images/whats-new/rel-notes-jul22-edit-app-option.png" - alt="Edit application option" - caption="Edit application option" -max-width="80%" -%} - -The Delete application option is available when you select an application. -Codefresh warns you of the implication of deleting the selected application in the Delete form based on the Prune resource setting. - -{% include - image.html - lightbox="true" - file="/images/whats-new/rel-notes-jul22-delete-app.png" - url="/images/whats-new/rel-notes-jul22-delete-app.png" - alt="Delete application" - caption="Delete application" -max-width="50%" -%} - -See [Update application configuration]({{site.baseurl}}/docs/deployment/create-application/#update-application-configuration) and [Delete an application]({{site.baseurl}}/docs/deployment/create-application/#delete-an-application). - -{::nomarkdown} -
-{:/} - -#### On-demand app synchronization -Manually synchronize applications whenever needed directly from Codefresh. The synchronize option is a significant enhancement to the application lifecycle management options that we already support in Codefresh. - -The set of options for application synchronization are identical to that of Argo CD. For usability, they are grouped into two sets: Revision and Additional Options. - -{% include - image.html - lightbox="true" - file="/images/whats-new/rel-notes-jul22-sync-app.png" - url="/images/whats-new/rel-notes-jul22-sync-app.png" - alt="Synchronize application" - caption="Synchronize application" - max-width="60%" -%} - -{::nomarkdown} -
-{:/} - -#### Activate access for Codefresh support -User Settings include an option to allow Codefresh support personnel account access for troubleshooting purposes. The option is disabled by default. When enabled, access is always coordinated and approved, and all actions are audited. - -{% include - image.html - lightbox="true" - file="/images/whats-new/rel-notes-jul22-account-access.png" - url="/images/whats-new/rel-notes-jul22-account-access.png" - alt="Enable account access" - caption="Enable account access" - max-width="80%" -%} - -See [Enable access for Codefresh support]({{site.baseurl}}/docs/administration/user-settings/#enable-access-for-codefresh-support). - -{::nomarkdown} -
-{:/} - -#### View logs by container -When viewing logs for applications and workflows, you can now select the container for which to display them. - -{% include - image.html - lightbox="true" - file="/images/whats-new/rel-notes-jul22-log-container.png" - url="/images/whats-new/rel-notes-jul22-log-container.png" - alt="View logs by container" - caption="View logs by container" - max-width="50%" -%} - -### Bug fixes -**Runtimes** -* Unable to remove managed cluster on failure to add shared configuration repository. -* Maximum character limit not validated in cluster names. -* Failure when downloading logs for all runtime components. -* New cluster automatically assigned Unknown status. -* Sealed secret remains in cluster after uninstalling runtime. -* Unable to view rollouts on managed cluster. - - -**Applications** - -* Resources without namespaces (such as cluster role) do not open in Current State. -* Sync state icon frozen when syncing the application. -* Application created with the same name as deleted application displayed as new deployment. -* No error when creating an application with the same name as an existing application. -* Applications dashboard does not display an application with incorrect Source. -* Applications dashboard does not display the Jira issue for Docker image. -* Sync policy appears as Manual though set to automatic. -* Sync error message partially cut off. -* Application release does not always return binaryId, and repositoryName for transition images. -* Application name not displayed in sync errors. - -**Images** -* Registry filter used with other filters returns wrong results. -* Find query for image applications. - - -**Other** - -* Unable to view, access, and add SSO integrations. -* Failure on sealing key management check. -* Home dashboard: Most active pipelines and Delivery Pipelines displayed not aligned with the Time filter. -* Incorrect sorting for workflow and pipeline lists. - - - -## June 2022 - -### Features & enhancements - -#### Shared configuration for runtimes -Define configuration settings for a runtime once, and reuse the configuration settings for multiple runtimes in the same account. Reduce time needed to define and maintain configuration settings for every runtime separately. - -After defining the repository in which to store configuration settings, you can reference the repository, selectively from specific runtimes, or from all runtimes, and share the configuration. - -Older versions of hybrid runtimes without the shared repository must be upgraded to the latest version to leverage the shared configuration, specifically for integrations with CI platforms and tools. - -For details, see [Shared runtime configuration]({{site.baseurl}}/docs/runtime/shared-configuration/). - -#### Logs for runtime components -View and download logs for runtimes and runtime components. The logs record events from the time of application launch for all resources in the application. - -Download logs for offline viewing and analysis, or view logs per component online, and download as needed: - -* Download all logs: Available for every runtime for download as a single `.tar.gz` file, including the different log files for each runtime component. -{% include - image.html - lightbox="true" - file="/images/whats-new/rel-notes-june22-runtime-logs-all.png" - url="/images/whats-new/rel-notes-june22-runtime-logs-all.png" - alt="Download all logs for a runtime" - caption="Download all logs for a runtime" - max-width="60%" - %} - -* View/download logs per component: Available for every runtime component. View online logs, displaying up to 1000 lines of the most recent events. Locate information with free-text search, and navigate between search results using the next/previous buttons. Enhance readability by turning on line-wrap when needed. - -{% include - image.html - lightbox="true" - file="/images/whats-new/rel-notes-june22-runtime-log-screen.png" - url="/images/whats-new/rel-notes-june22-runtime-log-screen.png" - alt="View logs online for runtime component" - caption="View logs online for runtime component" - max-width="60%" - %} - -For details, see [View/download runtime logs]({{site.baseurl}}/docs/runtime/download-runtime-logs/). - -#### OAuth2 authentication -OAuth (Open Authorization) 2.0 has become an industry standard for online authorization. Codefresh supports connections to your Git provider using OAuth2. Codefresh integrates with Git to sync repositories to your clusters, implement Git-based actions when creating resources such as Delivery Pipelines, and to enrich Images with valuable information. - -Codefresh provides a default, predefined OAuth2 application for every runtime. As an account administrator in Codefresh, you can optionally create an OAuth2 Application in GitHub and set up authentication within Codefresh. Users in Codefresh can then authorize access to GitHub with OAuth2, instead of with a personal access token. - -For details, see [Set up OAuth2 authentication]({{site.baseurl}}/docs/administration/oauth-setup/). - - -#### Application resources in Tree view -The Tree view of the Current State complements the List view of the same in the Applications dashboard. Similar to the List view, the Tree view also displays all the resources deployed for an application, with additional unique features. - -What is unique about the Tree view? -First, the Tree view simplifies visualization of and tracking resources for any deployment, think complex deployments with hundreds of resources. Second, it is designed to impart key information for each resource at a glance. Every resource shows its health status (color-coded border), sync state (icon prefixed to name), and metadata on mouse-over. - -{% include - image.html - lightbox="true" - file="/images/whats-new/rel-notes-june22-tree-view.png" - url="/images/whats-new/rel-notes-june22-tree-view.png" - alt="Application Current State: Tree view" - caption="Application Current State: Tree view" - max-width="60%" - %} - - -**Progressive discovery** - -By the very nature of its design, the Tree View allows progressive discovery. View all resources at once, or start with a parent resource, and expand it to view siblings and children to understand how they are connected. - -**Resource filters** - -The filters in the List view are available also in the Tree view. These global filters help narrow the scope of the resources displayed, by kind, health status, and sync state. The filters set in either the List or Tree vies are retained when navigating between them. - -**Resource search and find** - -The Search option lets you locate resources by searching for any part of the resource name. Similar to the filters, search results are also retained when navigating between Tree and List views. -For quick search, use the Find option to locate and navigate to required resources. - -**Resource inventory** - -At the bottom-left, the resource inventory summarizes your deployment in numbers per resource kind. Syncing and Out-of-Sync resources for each kind are bucketed separately, for visibility, and for quick access to filter resources by these states. - -**Resource manifest and logs** - -In addition to the metadata on mouse-over for a resource, clicking a resource shows its manifests and logs based on the resource type. View and compare the Desired and Live states for managed resources in Git repositories. -Another usability enhancement is the ability to share resource details by copying the URL and sending it to others in your organization for collaborative review. - -Logs are displayed if the resource has logs: - -* For online viewing, you have free-text search and line-wrap functionalities. -* For offline viewing and analysis, you can download the complete log into a text file. - -For details, see [Current State Tree view]({{site.baseurl}}/docs/deployment/applications-dashboard/view-modes-for-application-resources/#working-with-resources-in-tree-view). - -#### Application rollout visualization -In addition to installing Argo Rollouts in your cluster, visualize Argo Rollout history and progress directly in the Applications (deployment) dashboard. Visualize rollouts from multiple clusters and runtimes in a single centralized location through the Deployment tab. - -**Rollout progress** -Ongoing rollouts show the progress of the rollout in the real time. Completed rollouts show the switch to the new version according to the deployment strategy. - -{% include - image.html - lightbox="true" - file="/images/whats-new/rel-notes-june22-rollout-in-progress.png" - url="/images/whats-new/rel-notes-june22-rollout-in-progress.png" - caption="Application Rollout: Progress visualization" - max-width="60%" - %} - -**Rollout steps** - -As the rollout occurs, visualize step-by-step progress. Expanding Background Analysis displays metric queries and the manifest of the analysis template. - -{% include - image.html - lightbox="true" - file="/images/whats-new/rel-notes-june22-rollout-analysis.png" - url="/images/whats-new/rel-notes-june22-rollout-analysis.png" - caption="Application Rollout: Steps visualization" - max-width="30%" - %} - - {% include - image.html - lightbox="true" - file="/images/whats-new/rel-notes-june22-rollout-query-metrics.png" - url="/images/whats-new/rel-notes-june22-rollout-query-metrics.png" - caption="Application Rollout: Query metrics" - max-width="30%" - %} - -For details, see [Rollout progress and step visualization]({{site.baseurl}}/docs/deployment/applications-dashboard/#monitor-rollouts-by-deployment). - -#### Nested workflows -Add nested workflow functionality to Codefresh pipelines. A nested workflow is a step within the parent workflow that either submits a new workflow, or creates a PR (Pull Request) that runs a different workflow based on the PR result. - -Nested workflows run independently of the parent workflow that submitted them. A nested submit workflow has traceability in both directions, from the parent to child, and from the child to the parent. A workflow triggered by a nested PR identifies the PR that triggered it. - -Here’s an example of a parent workflow that submits two nested workflows, and the link back to the parent workflow from one of the child workflows. - - {% include - image.html - lightbox="true" - file="/images/whats-new/rel-notes-jun22-nested-parent-submit.png" - url="/images/whats-new/rel-notes-jun22-nested-parent-submit.png" - caption="Parent workflow with two nested submit workflows" - max-width="60%" - %} - - {% include - image.html - lightbox="true" - file="/images/whats-new/rel-notes-jun22-nested-child-submit.png" - url="/images/whats-new/rel-notes-jun22-nested-child-submit.png" - caption="Child submit workflow with link to parent workflow" - max-width="60%" - %} - -The Codefresh Hub for Argo has two ready-to-use Workflow Templates that: - -* Submits a workflow -* Creates a PR to run the workflow that tracks the PR - -For details, see [Nested workflows]({{site.baseurl}}/docs/pipelines/nested-workflows/). - -### Bug fixes -**Runtimes** - -* Encrypted Git integration remains when uninstalling runtime through the CLI, and decryption through app-proxy fails. -* Rollback occurs during installation via CLI. -* Runtime ignores –Demo resources=false flag install confirmation. -* Installation via CLI stops when demo resources are not installed even when –demo -resources flag is set to false. -* No errors during installation via CLI when flags are incorrectly located. -* Runtime name with health or sync errors not highlighted in Codefresh UI. - -**Images** - -* Empty pages on changing filters in page two or higher. -* Broken link for an image not in logged-in user account. -* Images view not updated with current application with rollout resource. - -**Applications** - -* Lock out due to slow application load. -* Application dashboard remains frozen in Progressing state. -* Application dashboard > Timeline tab: - - * Default view not restored on removing date range defined in the Timeline tab. - * Order of deployments in the chart not identical to the list of rollouts. - * Committer for GitOps change missing in Commit information. - * Missing commit message for SHA link. - * Changes to an image tag not reflected. - * Rollout shows as in progress even after deployment status is healthy. - * New release in Argo CD not displayed in Codefresh UI when latest release was degraded without previous rollout data. - * Rollout YAML unavailable when application source is a Helm repo. -* Applications dashboard > Services tab: - - * Progressing rollout with manual traffic management returns empty Services list. -* Applications dashboard > Current State - * Resource tree/list not restored on removing filters. - - -**Pipelines** - -* Selecting an existing Workflow Template creates a new Workflow Template. -* Incorrect line numbers for pipeline template in Form mode. - - -## May 2022 - -### Features & enhancements - -#### Runtime disaster recovery -Runtimes are integral to all CI/CD actions and operations in Codefresh. In this release, we added the capability to restore runtimes in case of cluster failures, either partial or complete. -All you need is the existing Git repo where you installed the runtime containing the runtime resources. The restore process reinstalls the runtime, leveraging the resources in the existing repo. You can choose to restore the runtime to the failed cluster or to a different cluster. -For details, see [Restore runtimes]({{site.baseurl}}/docs/runtime/runtime-recovery/). - -#### AWS ALB ingress controller -AWS Application Load Balancer (ALB) is now part of our list of supported ingress controllers. -For details, see Ingress controller requirements in [Requirements]({{site.baseurl}}/docs/runtime/requirements/#ingress-controller), and [Post-installation configuration]({{site.baseurl}}/docs/runtime/installation/#post-installation-configuration). - - -#### Labels for runtime namespace -When installing runtimes, the `--namespace-label` flag lets you add labels to the runtime namespace. The labels identify and grant access to the installation network, required with service mesh ingress controllers such as Istio. -For both CLI-based and silent installations, add the flag followed by one or more labels in `key=value` format. Note that these labels must be identical to those defined in the 'namespace' resource spec. -For details, see [Runtime installation flags]({{site.baseurl}}/docs/runtime/installation/#runtime-installation-flags). - -#### Internal and external ingress hosts -Codefresh runtimes support defining two ingress hosts, an internal and an external ingress host, for private and public networks. Previously, runtimes supported a single ingress host for both the app-proxy and webhook ingress resources. Internal and external ingress separation allows you to expose the Codefresh app-proxy service only within your private network, while keeping the webhook ingress unchanged. -* New runtime installations: The `--internal-ingress-host` flag lets you can define an ingress host for communication with the app-proxy. For details, see [Runtime installation flags]({{site.baseurl}}/docs/runtime/installation/#runtime-installation-flags). -* Existing runtimes: To add an internal ingress host, you need to commit changes to the installation repository by modifying `app-proxy ingress` and `.yaml`. -For details, see _Internal ingress host configuration (optional)_ in [Post-installation configuration]({{site.baseurl}}/docs/runtime/installation#post-installation-configuration). - -For further customizations, add annotations for internal and external ingress hosts through the `--internal-ingress-annotation` and `--external-ingress-annotation` flags. - -#### oktapreview domain support -You can set up Okta SSO to log into your Okta preview environment. - -#### Git Source enhancements -A common scenario when using Git repositories for CI/CD is to include or exclude specific files or directories in the target repository from the destination repo or cluster. When creating or editing Git Sources in Codefresh, you can now include or exclude folders and files in the target Git repo, using Glob patterns for the same. - -{% include - image.html - lightbox="true" - file="/images/whats-new/rel-notes-may22-git-source-exclude-include.png" - url="/images/whats-new/rel-notes-may22-git-source-exclude-include.png" - alt="Include/exclude options in Git Source" - caption="Include/exclude options in Git Source" - max-width="50%" - %} - -You can also delete Git Sources if needed. Selecting additional actions for a Git Source, displays the Git Source details with the Delete option. - -{% include - image.html - lightbox="true" - file="/images/whats-new/rel-notes-may22-git-source-delete.png" - url="/images/whats-new/rel-notes-may22-git-source-delete.png" - alt="Delete Git Source" - caption="Delete Git Source" - max-width="90%" - %} - -For details, see [Add and manage Git Sources]({{site.baseurl}}/docs/runtime/git-sources/). - -### Bug fixes -**Runtimes** - -* With Istio ingress, app proxy communication with Argo CD fails with `Unexpected token u in JSON error`. -* Adding a managed cluster always commits manifests to the main branch and not to the defined default branch. -* Add managed cluster command fails when ingress host includes `/` suffix. -* Application groups not supported in Current State for older runtime versions. -* Retrieving a list of Git Sources for a runtime via CLI, causes the CLI to crash. -* Uninstalling a runtime does not remove runtime-related secrets from the cluster. - -**Applications** - -* Applications deleted from the Argo UI not removed from the Applications dashboard in Codefresh. -* Back button in Applications > Timeline tab does not work. -* Hierarchy for AppSet application created in Argo CD not rendered correctly in Codefresh. -* Most Active Applications list in the Home dashboard is incorrectly sorted. -* Link to CI build on Service in Applications Dashboard is hard-coded to Workflows. -* Add Application wizard creates invalid manifest. -* Removing a resource from an application does not remove it from the application’s Current State list. -* Deleting an application deletes it from the cluster and the Git repo, but not from the database. -* Creating an application without path results in an error. -* On page reload, deployment chart in Application > Timeline tab does not reflect set filters. -* Resources with changed file names are not reported in Argo CD. -* Unknown state for application sets with targets on external clusters. - -**Others** -* Clicking the Settings icon shows a console error. -* Workflow Templates reported without Git manifests and desired state. -* Get list of workflows for a pipeline via CLI returns 400 bad request. -* GitHub user without a public email address causes autopilot to crash in app-proxy. -* Within a staging app, regular deployment transition is empty and shows only replicas count. - - -## March-April 2022 - -### Features & enhancements - -#### Kubernetes version runtime support -We now support the latest Kubernetes server versions, 1.22 and 1.23. - -#### Ingress controllers -We are continually working on supporting additional Ingress controllers, and this release adds support for: -* Ambassador -* NGINX Enterprise -* Istio -* Traefik - -All ingress controllers must be configured to report their status. -For details, see [Ingress controller requirements]({{site.baseurl}}/docs/runtime/requirements/#ingress-controller). - - -#### Argo CD managed cluster support -Argo CD can manage clusters without Argo CD installed on them. Now you have the same functionality in Codefresh, to add, view, and manage remote clusters. -Admins can add an external cluster to a Codefresh runtime, and register it automatically as a managed cluster. From that point on, you have complete visibility into health and sync status, and options to manage them, including installing Argo Rollouts. - -With managed clusters in Codefresh, you get: -* Streamlined management: All cluster- and cluster-component level operations are managed through the runtime, in a centralized location. You can install new components, uninstall existing components, and remove the cluster from the runtime's managed list. A single click installs Argo Rollouts on the managed cluster. - -{% include - image.html - lightbox="true" - file="/images/whats-new/rel-notes-argo-rollouts.png" - url="/images/whats-new/rel-notes-argo-rollouts.png" - alt="Install Argo Rollouts for managed cluster in topology view" - caption="Install Argo Rollouts for managed cluster in topology view" - max-width="70%" - %} - -* Seamless upgrades: Upgrades to runtimes or to runtime components in the local cluster automatically upgrades those in managed clusters as well. -* Integration with dashboards: Applications dashboards reflect deployment information for applications in all managed clusters. When Argo Rollouts are installed, application rollouts are also reported to the dashboard. - -For details, see [Managed clusters]({{site.baseurl}}/docs/runtime/managed-cluster). - -#### Topology views for runtimes - -Get a visual representation of the runtimes in your deployments, managed clusters, and cluster components with the Topology view for runtimes. -Quickly identify key information such as health and sync status, and version. -Add new clusters to or remove existing clusters from runtime management. - -{% include - image.html - lightbox="true" - file="/images/whats-new/rel-notes-runtime-topology-view.png" - url="/images/whats-new/rel-notes-runtime-topology-view.png" - alt="Runtime topology view" - caption="Runtime topology view" - max-width="70%" - %} - -For details, see [Topology view for runtimes]({{site.baseurl}}/docs/runtime/monitor-manage-runtimes/#topology-view). - -#### Analytics dashboard -In addition to Delivery Pipelines, the Analytics dashboard shows Runtimes, Managed Clusters, Deployments, and Applications, to give you the complete CI/CD picture with key facts and insights. - -**Usability enhancements** - * Global filters are now located at the top of the dashboard. - * Resource-specific filters are available for that resource. - * A convenient View button takes you to the dedicated resource view for additional analysis. - - -{% include - image.html - lightbox="true" - file="/images/whats-new/rel-notes-analytics-dashboard.png" - url="/images/whats-new/rel-notes-analytics-dashboard.png" - alt="Analytics dashboard" - caption="Analytics dashboard" - max-width="70%" - %} - -#### Applications dashboard -The Applications dashboard displays the individual deployments across your enterprise. Here are the main enhancements: - -**Application inventory and status filters** - - The health status snapshot in the Applications dashboard also works as a quick filter. Selecting a status filters applications by that status. - Filter criteria that match child applications automatically expands the parent application to show the child applications. - - {% include - image.html - lightbox="true" - file="/images/whats-new/app-dashboard-status-filter.png" - url="/images/whats-new/app-dashboard-status-filter.png" - alt="Applications dashboard: Filter by status" - caption="Applications dashboard: Filter by status" - max-width="70%" - %} - -**Rollouts** - - Intuitive visualization with the option to open the Images view in a new browser window. - - {% include - image.html - lightbox="true" - file="/images/whats-new/rel-notes-apps-open-image.png" - url="/images/whats-new/rel-notes-apps-open-image.png" - alt="Applications dashboard: Link to Image view" - caption="Applications dashboard: Link to Image view" - max-width="70%" - %} - -**Git committers** - Hovering over an avatar shows all commits made by that committer. - - -**Current state of cluster resources** - Hierarchical representation of the resources deployed by this application in the cluster. - - {% include - image.html - lightbox="true" - file="/images/whats-new/rel-notes-app-current-state.png" - url="/images/whats-new/rel-notes-app-current-state.png" - alt="Applications dashboard: Current State" - caption="Applications dashboard: Current State" - max-width="70%" - %} - -#### Workflow Templates -Codefresh provides full-fledged management for the Workflow Template resource, from optimizing existing Workflow Templates, to creating new ones, and testing Workflow Templates before commit. - - {% include - image.html - lightbox="true" - file="/images/whats-new/wrkflow-template-main.png" - url="/images/whats-new/wrkflow-template-main.png" - alt="Workflow Templates" - caption="Workflow Templates" - max-width="70%" - %} - -**Create, test, and optimize Workflow Templates** - Create Workflow Templates in three steps. Start by selecting one from the Codefresh Hub for Argo, or start with a blank template form. Customize the Workflow Template, and either run the template to test it or commit to submit it. - - {% include - image.html - lightbox="true" - file="/images/whats-new/wrkflow-template-add.png" - url="/images/whats-new/wrkflow-template-add.png" - alt="Add Workflow Template panel" - caption="Add Workflow Template panel" - max-width="50%" - %} - - For both new and existing Workflow Templates, the **Run** option enables you to test a new template, or changes to an existing template, without needing to first commit the changes. If the Workflow Template has previous iterations, you can view the arguments and values used in those iterations. - - {% include - image.html - lightbox="true" - file="/images/whats-new/rel-notes-wrkflow-temp-manifest-run.png" - url="/images/whats-new/rel-notes-wrkflow-temp-manifest-run.png" - alt="Run option for Workflow Templates" - caption="Run option for Workflow Templates" - max-width="70%" - %} - - {% include - image.html - lightbox="true" - file="/images/whats-new/rel-notes-wrkflow-temp-run-args-view.png" - url="/images/whats-new/rel-notes-wrkflow-temp-run-args-view.png" - alt="Run Workflow Template: Arguments list" - caption="Run Workflow Template: Arguments list" - max-width="40%" - %} - - The Workflows and Delivery Pipelines tabs associated with the selected Workflow Template are displayed in the respective tabs, giving you all the information in the same location. - - -**Rename Workflow Template** - After creating a Workflow Template, you can rename it by selecting the template and clicking **Rename**. - The new name must be unique within the cluster. - - {% include - image.html - lightbox="true" - file="/images/whats-new/rel-notes-rename-workflow-template.png" - url="/images/whats-new/rel-notes-rename-workflow-template.png" - alt="Rename Workflow Template" - caption="Rename Workflow Template" - max-width="70%" - %} - - -#### Application creation wizard - -Create applications that are fully GitOps-compliant from the Codefresh UI. The application manifest is generated, committed to Git, and synced to your cluster. -When creating the application, you can use the UI forms, or edit the manifest directly. - - - -{% include - image.html - lightbox="true" - file="/images/whats-new/rel-notes-app-create-settings.png" - url="/images/whats-new/rel-notes-app-create-settings.png" - alt="Application settings in application creation wizard" - caption="Application settings in application creation wizard" - max-width="70%" -%} - - -#### Delivery Pipeline flows -The Delivery Pipeline flow features several usability and functionality enhancements. - -**Seamless integration of Argo Event information with Argo Workflows** - - Once a workflow is submitted for a Delivery Pipeline, the Workflows tab visualizes the connections between the steps in the workflow. - With Argo Event information for the workflow also incorporated into the visualization, you have a unified view of Argo Events and Argo Workflows in one and the same location, the events that triggered the workflow combined with the workflow itself. - - The Event Source manifest, the event payload, and the Sensor manifest are displayed as pull-out panels, allowing you to easily copy paths for attributes from event payloads, view logs, and download artifacts. - - This example shows the event payload from Argo Events for the workflow. - -{% include - image.html - lightbox="true" - file="/images/whats-new/rel-notes-event-payload.png" - url="/images/whats-new/rel-notes-event-payload.png" - alt="Panel with Event Payload in Workflows tab" - caption="Panel with Event Payload in Workflows tab" - max-width="70%" -%} - - This example shows the sensor manifest from Argo Events for the workflow. - -{% include - image.html - lightbox="true" - file="/images/whats-new/rel-notes-event-srce-manifest.png" - url="/images/whats-new/rel-notes-event-srce-manifest.png" - alt="Panel with Sensor manifest in Workflows tab" - caption="Panel with Sensor manifest in Workflows tab" - max-width="70%" -%} - -**Rename trigger resource** - - Similar to Workflow Templates, you can now change the trigger name of a Delivery Pipeline. The sensor name cannot be changed. - -{% include - image.html - lightbox="true" - file="/images/whats-new/rel-notes-rename-pipeline-trigger.png" - url="/images/whats-new/rel-notes-rename-pipeline-trigger.png" - alt="Rename trigger option for Delivery Pipeline" - caption="Rename trigger option for Delivery Pipelines" - max-width="70%" -%} - -**Git repo selection for commits** - - A dropdown list allows you to select one or more Git repos in the Trigger Conditions tab. Start typing, and use autocomplete to view and select from the available Git repos. - -{% include - image.html - lightbox="true" - file="/images/whats-new/rel-notes-git-repo-select.png" - url="/images/whats-new/rel-notes-git-repo-select.png" - alt="Git repo selection for Delivery Pipelines" - caption="Git repo selection for Delivery Pipelines" - max-width="70%" -%} - - -**Errors/warning in manifests synced with the line number in manifest** - - Clicking the line number next to an error or a warning changes focus to the line in the manifest file with the error or warning. - - -#### Workflows dashboard enhancements - -**Link from workflows to their pipelines** - - Workflow names in the dashboard are clickable links. Clicking a workflow name takes you directly to the pipeline associated with that workflow. - -**New status for active workflows without events** - -Identify workflows that are active but do not have any execution data with the new status filter in the Workflows dashboard. Filtering by Status ‘Unknown’ shows workflows without events for the last hour. - -{% include - image.html - lightbox="true" - file="/images/whats-new/rel-notes-workflow-unknown-status.png" - url="/images/whats-new/rel-notes-workflow-unknown-status.png" - alt="Unknown status filter for workflows" - caption="Unknown status filter for workflows" - max-width="50%" -%} - -#### Image reporting with Docker config.json -You can now also authenticate to a Docker registry using `docker./config.json` to report image information. Note that `config.json` is not currently supported for GCR, ECR, and ACR. -For more information on the required fields, see [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"}. - - -#### OpenShift 4.8 support -CSDP supports Red Hat OpenShift 4.8. For detailed information, read their [blog](https://cloud.redhat.com/blog/red-hat-openshift-4.8-is-now-generally-available#:~:text=OpenShift%204.8%20improves%20the%20bare,is%20now%20shipping%20with%20OpenShift){:target="\_blank"}. - -### Bug fixes - -**Applications dashboard** - -* Inaccurate results when filtering by Application type. -* Cluster shows the address of the Argo CD cluster instead of the target cluster. -* Broken Commit link in Application Preview. -* Filter by favorites does not show ApplicationSets. -* Releases not ordered correctly. -* Missing tags for Application/AppllicationSet. -* Loop created on changing date in the Applications dashboard. -* Rollouts in Deployment chart not aligned with the actual order of rollouts. -* Missing current release label. -* Missing commit message -* JIRA annotations not displayed for Images in Docker.io. -* Avatars show up intermittently. -* Incorrect Committers in Applications dashboard. -* Performance issues. - -**Images** - -* Duplicate applications in Images repositories with different tags. -* Unmarked deployed images. - -**Pipelines** - -* Empty event-sources. -* Missing created/updated/deleted status for resources. -* Event mapping issues. -* Creating a new pipeline with an existing Template shows empty Template tab. - -**Upgrade** - -* Agent upgrade overrides configuration in previous release. - -**Uninstall** - -* Artifacts in database after uninstalling with `--force` flag. -* Uninstallation issues with newer K8s versions. - - diff --git a/images/deployments/kubernetes/define-k8s-deployment-resource.png b/images/deployments/kubernetes/define-k8s-deployment-resource.png new file mode 100644 index 00000000..381ea2e7 Binary files /dev/null and b/images/deployments/kubernetes/define-k8s-deployment-resource.png differ diff --git a/images/deployments/kubernetes/define-k8s-service-resource.png b/images/deployments/kubernetes/define-k8s-service-resource.png new file mode 100644 index 00000000..2488975b Binary files /dev/null and b/images/deployments/kubernetes/define-k8s-service-resource.png differ diff --git a/images/deployments/kubernetes/deploying-private-cf-registry.png b/images/deployments/kubernetes/deploying-private-cf-registry.png new file mode 100644 index 00000000..92b9c979 Binary files /dev/null and b/images/deployments/kubernetes/deploying-private-cf-registry.png differ diff --git a/images/deployments/kubernetes/environment-variables-deployment.png b/images/deployments/kubernetes/environment-variables-deployment.png new file mode 100644 index 00000000..6b90e010 Binary files /dev/null and b/images/deployments/kubernetes/environment-variables-deployment.png differ diff --git a/images/deployments/kubernetes/quick-ui-deploy.png b/images/deployments/kubernetes/quick-ui-deploy.png new file mode 100644 index 00000000..b2bc242d Binary files /dev/null and b/images/deployments/kubernetes/quick-ui-deploy.png differ