diff --git a/_config.yml b/_config.yml
index 4630cb270..4d4595c13 100644
--- a/_config.yml
+++ b/_config.yml
@@ -1,5 +1,5 @@
title: Codefresh | Docs
-description: "Codefresh is a Docker-native CI/CD platform. Instantly build , test and deploy Docker images."
+description: "Codefresh DevOps platform for Argo. Ditch the scripts of the past. Get the best of DevOps in a single platform."
# Server
source: "."
@@ -116,11 +116,11 @@ schedule_demo: "https://codefresh.io/schedule-a-demo/"
codefresh_login: "https://g.codefresh.io/login"
codefresh_signup: "https://g.codefresh.io/signup"
-link_main: "https://codefresh.io"
-link_cli: "https://cli.codefresh.io"
+link_main: "https://codefresh.io/codefresh-argo-platform/"
+link_cli: "https://github.com/codefresh-io/cli-v2#installation"
link_git_examples: "https://github.com/codefresh-examples/examples/"
link_api: "https://g.codefresh.io/api/"
-link_plugins: "https://codefresh.io/steps/"
+link_plugins: "https://codefresh.io/argohub/"
link_community: "https://community.codefresh.io/"
ga_tracking_code: "UA-53554200-2"
diff --git a/_data/home-content.yml b/_data/home-content.yml
index 383ef8782..5b0abcb56 100644
--- a/_data/home-content.yml
+++ b/_data/home-content.yml
@@ -1,264 +1,281 @@
-- title: Getting Started
+
+- title: Introduction
icon: images/home-icons/started.svg
url: ''
links:
- - title: Setup Codefresh Account
- localurl: /docs/getting-started/create-a-codefresh-account/
- - title: Your first CI/CD pipeline
- localurl: /docs/getting-started/create-a-basic-pipeline/
- - title: Kubernetes Quick start guide
- localurl: /docs/getting-started/deployment-to-kubernetes-quick-start-guide/
- - title: Helm Quick start guide
- localurl: /docs/getting-started/helm-quick-start-guide/
- - title: Frequently Asked Questions
- localurl: /docs/getting-started/faq/
+ - title: What is Codefresh?
+ localurl: /docs/getting-started/intro-to-codefresh/
+ - title: Codefresh for CI
+ localurl: /docs/getting-started/ci-codefresh/
+ - title: Codefresh for CD
+ localurl: /docs/getting-started/cd-codefresh/
+ - title: Codefresh for GitOps
+ localurl: /docs/getting-started/gitops-codefresh/
+ - title: Concepts in Codefresh
+ localurl: /docs/getting-started/concepts/
-- title: Pipelines
- icon: images/home-icons/pipeline.svg
+
+- title: Quick starts
+ icon: images/home-icons/tutorial.svg
url: ''
links:
- - title: Introduction to Pipelines
- localurl: /docs/configure-ci-cd-pipeline/introduction-to-codefresh-pipelines/
- - title: Creating Pipelines
- localurl: /docs/configure-ci-cd-pipeline/pipelines/
- - title: Pipeline triggers
- localurl: /docs/configure-ci-cd-pipeline/triggers/
- - title: Monitoring pipelines
- localurl: /docs/configure-ci-cd-pipeline/monitoring-pipelines/
- - title: Shared Configuration
- localurl: /docs/configure-ci-cd-pipeline/shared-configuration/
- - title: Using secrets
- new: true
- localurl: /docs/configure-ci-cd-pipeline/secrets-store/
- - title: Pipeline caching
- localurl: /docs/configure-ci-cd-pipeline/pipeline-caching/
- - title: Running pipelines locally
- localurl: /docs/configure-ci-cd-pipeline/running-pipelines-locally/
- - title: Debugging pipelines
- new: true
- localurl: /docs/configure-ci-cd-pipeline/debugging-pipelines/
-- title: Learn by example
- icon: images/home-icons/tutorial.svg
+ - title: Create Codefresh account
+ localurl: /docs/quick-start/create-codefresh-account/
+ - title: CI/CD quick starts
+ localurl: /docs/quick-start/ci-quick-start/
+ - title: GitOps quick starts
+ localurl: /docs/quick-start/gitops-quick-start/
+
+
+- title: Pipeline integrations
+ icon: images/home-icons/cloud-integrations.png
+ links:
+ - title: Hosted GitOps
+ localurl: /docs/integrations/codefresh-hosted-gitops/
+ - title: Git providers
+ localurl: /docs/integrations/git-providers/
+ - title: Kubernetes
+ localurl: /docs/integrations/kubernetes/
+ - title: Amazon Web Services
+ localurl: /docs/integrations/amazon-web-services/
+ - title: Microsoft Azure
+ localurl: /docs/integrations/microsoft-azure/
+ - title: Google Cloud
+ localurl: /docs/integrations/google-cloud/
+ - title: Docker Registries
+ localurl: /docs/integrations/docker-registries/
+ - title: Secret Storage
+ localurl: /docs/integrations/secret-storage/
+ - title: Helm
+ localurl: /docs/integrations/helm/
+ - title: Argo CD
+ localurl: /docs/integrations/argocd/
+ - title: Datadog
+ localurl: /docs/integrations/datadog/
+ - title: Jenkins integration/migration
+ localurl: /docs/integrations/jenkins-integration/
+ - title: Codefresh API
+ localurl: /docs/integrations/codefresh-api/
+
+
+
+- title: GitOps integrations
+ icon: images/home-icons/integrations.svg
url: ''
links:
- - title: Go
- localurl: /docs/learn-by-example/golang/
- - title: Java
- localurl: /docs/learn-by-example/java/
- - title: Node.js
- localurl: /docs/learn-by-example/nodejs/
- - title: Php
- localurl: /docs/learn-by-example/php/
- - title: Python
- localurl: /docs/learn-by-example/python/
- - title: Ruby On Rails
- localurl: /docs/learn-by-example/ruby/
- - title: C/C++
- localurl: /docs/learn-by-example/cc/
- - title: C# (.NET core)
- localurl: /docs/learn-by-example/dotnet/
- - title: More...
- localurl: /docs/yaml-examples/examples/
+ - title: GitOps image enrichment with integrations
+ localurl: /docs/gitops-integrations/image-enrichment-overview/
+ - title: Codefresh pipelines for GitOps
+ localurl: /docs/gitops-integrations/ci-integrations/codefresh-classic/
+ - title: GitHub Actions for GitOps
+ localurl: /docs/gitops-integrations/ci-integrations/github-actions/
+ - title: Jenkins for GitOps
+ localurl: /docs/gitops-integrations/ci-integrations/jenkins/
+ - title: Jira for GitOps
+ localurl: /docs/gitops-integrations/issue-tracking/jira/
+ - title: Amazon ECR for GitOps
+ localurl: /docs/gitops-integrations/container-registries/amazon-ecr/
+ - title: Docker Hub Registry for GitOps
+ localurl: /docs/gitops-integrations/container-registries/dockerhub/
+ - title: GitHub Container Registry for GitOps
+ localurl: /docs/gitops-integrations/container-registries/github-cr/
+ - title: JFrog Artifactory for GitOps
+ localurl: /docs/gitops-integrations/container-registries/jfrog/
+ - title: Quay Registry for GitOps
+ localurl: /docs/gitops-integrations/container-registries/quay/
+
+- title: Dashboards & insights
+ icon: images/home-icons/guides.png
+ url: ''
+ links:
+ - title: GitOps Overview dashboard
+ localurl: /docs/dashboards/home-dashboard/
+ - title: DORA metrics
+ localurl: /docs/dashboards/dora-metrics/
+ - title: Images
+ localurl: /docs/dashboards/images/
+
+
+
+
- title: CI/CD guides
icon: images/home-icons/guides.png
url: ''
links:
- - title: Build your app
- localurl: /docs/ci-cd-guides/packaging-compilation/
- - title: Building Docker images
- localurl: /docs/ci-cd-guides/building-docker-images/
- - title: Working with Docker registries
- localurl: /docs/ci-cd-guides/working-with-docker-registries/
- - title: Pull Requests and branches
- localurl: /docs/ci-cd-guides/pull-request-branches/
- - title: Pipelines for Microservices
- localurl: /docs/ci-cd-guides/microservices/
- - title: Production and Staging deployments
- new: true
- localurl: /docs/ci-cd-guides/environment-deployments/
- - title: Preview Environments
- new: true
- localurl: /docs/ci-cd-guides/preview-environments/
- - title: GitOps deployments
- new: true
- localurl: /docs/ci-cd-guides/gitops-deployments/
- - title: Progressive Delivery
- new: true
- localurl: /docs/ci-cd-guides/progressive-delivery/
-
-
-
-- title: Yaml Syntax
- icon: images/home-icons/yaml.svg
+ - title: Building your app
+ localurl: /docs/ci-cd-guides/packaging-compilation/
+ - title: Building Docker images
+ localurl: /docs/ci-cd-guides/building-docker-images/
+ - title: Accessing a Docker registry from Kubernetes cluster
+ localurl: /docs/ci-cd-guides/access-docker-registry-from-kubernetes/
+ - title: Working with Docker registries
+ localurl: /docs/ci-cd-guides/working-with-docker-registries/
+ - title: Adding config maps to namespaces
+ localurl: /docs/ci-cd-guides/add-config-maps-to-your-namespaces/
+ - title: Pull Requests and branches
+ localurl: /docs/ci-cd-guides/pull-request-branches/
+ - title: Pipelines for microservices
+ localurl: /docs/ci-cd-guides/microservices/
+ - title: Deploying to predefined environments
+ localurl: /docs/ci-cd-guides/environment-deployments/
+ - title: Previewing dynamic environments
+ localurl: /docs/ci-cd-guides/preview-environments/
+ - title: Helm best practices
+ localurl: /docs/ci-cd-guides/helm-best-practices/
+ - title: Templating for Kubernetes
+ localurl: /docs/ci-cd-guides/kubernetes-templating/
+ - title: Image enrichment
+ localurl: /docs/ci-cd-guides/image-enrichment/
+
+
+
+
+- title: Example catalog
+ icon: images/home-icons/tutorial.svg
url: ''
links:
- - title: Pipeline definition
- localurl: /docs/codefresh-yaml/what-is-the-codefresh-yaml/
- - title: Pipeline steps
- localurl: /docs/codefresh-yaml/steps/
- - title: Pipeline stages
- localurl: /docs/codefresh-yaml/stages/
- - title: Variables
- localurl: /docs/codefresh-yaml/variables/
- - title: Step conditions
- localurl: /docs/codefresh-yaml/conditional-execution-of-steps/
- - title: Service Containers
- localurl: /docs/codefresh-yaml/service-containers/
- - title: Advanced Workflows
- localurl: /docs/codefresh-yaml/advanced-workflows/
- - title: Deployment environments
- localurl: /docs/codefresh-yaml/deployment-environments/
- - title: Hooks
- localurl: /docs/codefresh-yaml/hooks/
- - title: Plugins
- localurl: /docs/codefresh-yaml/steps/#creating-your-own-step
- - title: Examples
- localurl: /docs/yaml-examples/examples/
-
-- title: Testing
- icon: images/home-icons/testing.svg
+ - title: CI examples
+ localurl: /docs/example-catalog/ci-examples/
+ - title: CD examples
+ localurl: /docs/example-catalog/cd-examples/
+
+- title: Pipelines
+ icon: images/home-icons/pipeline.svg
url: ''
links:
- - title: Unit tests
- localurl: /docs/testing/unit-tests/
- - title: Integration Tests
- localurl: /docs/testing/integration-tests/
- - title: Test reports
- localurl: /docs/testing/test-reports/
- - title: Preview environment tutorial
- localurl: /docs/getting-started/on-demand-environments/
- - title: Creating compositions
- localurl: /docs/testing/create-composition/
- - title: Dynamic preview environments
- localurl: /docs/testing/automatic-preview-environments/
- - title: Security Scanning
- localurl: /docs/testing/security-scanning/
- - title: SonarQube Scanning
- localurl: /docs/testing/sonarqube-integration/
-
-- title: Kubernetes
- icon: images/home-icons/k8s.svg
+ - title: Introduction to pipelines
+ localurl: /docs/pipelines/introduction-to-codefresh-pipelines/
+ - title: Creating pipelines
+ localurl: /docs/pipelines/pipelines/
+ - title: Steps in pipelines
+ localurl: /docs/pipelines/steps/
+ - title: Triggers in pipelines
+ localurl: /docs/pipelines/triggers/
+ - title: Monitoring pipelines
+ localurl: /docs/pipelines/monitoring-pipelines/
+ - title: Advanced workflows for pipelines
+ localurl: /docs/pipelines/advanced-workflows/
+ - title: Shared configuration
+ localurl: /docs/pipelines/configuration/shared-configuration/
+ - title: Using secrets
+ localurl: /docs/pipelines/configuration/secrets-store/
+ - title: Caching in pipelines
+ localurl: /docs/pipelines/pipeline-caching/
+ - title: Running pipelines locally
+ localurl: /docs/pipelines/running-pipelines-locally/
+ - title: Debugging pipelines
+ localurl: /docs/pipelines/debugging-pipelines/
+
+
+
+- title: Deployments
+ icon: images/home-icons/deployment.svg
url: ''
links:
- - title: Kubernetes deployment options
- localurl: /docs/deploy-to-kubernetes/deployment-options-to-kubernetes/
- - title: Connecting to your cluster
- localurl: /docs/deploy-to-kubernetes/add-kubernetes-cluster/
- - title: Managing your cluster
- localurl: /docs/deploy-to-kubernetes/manage-kubernetes/
- - title: Environment Dashboard
- localurl: /docs/deploy-to-kubernetes/environment-dashboard/
- - title: Accessing a Docker registry from your cluster
- localurl: /docs/deploy-to-kubernetes/access-docker-registry-from-kubernetes/
- - title: Kubernetes manifest templates
- localurl: "/docs/deploy-to-kubernetes/kubernetes-templating/"
- - title: Run custom kubectl commands
- localurl: "/docs/deploy-to-kubernetes/custom-kubectl-commands/"
-- title: "Helm"
- icon: images/home-icons/helm.svg
+ - title: Deployment options for Kubernetes
+ localurl: /docs/deployments/kubernetes/
+ - title: Managing Kubernetes clusters
+ localurl: /docs/deployments/kubernetes/manage-kubernetes/
+ - title: Using Helm in Codefresh pipelines
+ localurl: /docs/deployments/helm/using-helm-in-codefresh-pipeline/
+ - title: Managing Helm releases
+ localurl: /docs/deployments/helm/helm-releases-management/
+ - title: Promoting Helm environments
+ localurl: /docs/deployments/helm/helm-environment-promotion/
+ - title: Creating GitOps applications
+ localurl: /docs/deployments/gitops/create-application/
+ - title: Monitoring GitOps applications
+ localurl: /docs/deployments/gitops/applications-dashboard/
+ - title: Managing GitOps applications
+ localurl: /docs/deployments/gitops/manage-application/
+
+
+
+
+- title: Argo CD Workflows
+ icon: images/home-icons/pipeline.svg
url: ''
links:
- - title: Helm best practices
- localurl: /docs/new-helm/helm-best-practices/
- - title: Using Helm in a Codefresh pipeline
- localurl: /docs/new-helm/using-helm-in-codefresh-pipeline/
- - title: Helm Releases management
- localurl: /docs/new-helm/helm-releases-management/
- - title: Codefresh Managed Helm Repositories
- localurl: /docs/new-helm/managed-helm-repository/
- - title: Helm Charts and repositories
- localurl: /docs/new-helm/add-helm-repository/
- - title: Helm Environment Promotion
- localurl: /docs/new-helm/helm-environment-promotion/
-- title: Deployment
- icon: images/home-icons/deployment.svg
+ - title: Creating Argo CD workflows
+ localurl: /docs/workflows/create-pipeline
+ - title: Nested Argo CD workflows
+ localurl: /docs/workflows/nested-workflows/
+ - title: Configure artifact repository
+ localurl: /docs/workflows/configure-artifact-repository/
+ - title: Selectors for concurrency synchronization
+ localurl: /docs/workflows/concurrency-limit/
+ - title: Sharing file systems
+ localurl: /docs/workflows/sharing-file-system/
+
+
+
+
+- title: Installation
+ icon: images/home-icons/runtimes.svg
url: ''
links:
- - title: Deploy to Kubernetes
- localurl: /docs/deploy-to-kubernetes/codefresh-kubernetes-integration-demochat-example/
- - title: Deploy with Helm
- localurl: /docs/yaml-examples/examples/helm/
- - title: Deploy with Kustomize
- localurl: /docs/yaml-examples/examples/deploy-with-kustomize/
- - title: Deploy to a VM with Packer
- localurl: /docs/yaml-examples/examples/packer-gcloud/
- - title: Deploy with Terraform
- localurl: /docs/yaml-examples/examples/terraform/
- - title: Deploy with Pulumi
- localurl: /docs/yaml-examples/examples/pulumi/
- - title: Deploy to Nomad
- localurl: /docs/yaml-examples/examples/nomad/
- - title: Deploy to ECS/Fargate
- localurl: /docs/yaml-examples/examples/amazon-ecs/
- - title: Deploy to Elastic Beanstalk
- localurl: /docs/yaml-examples/examples/elastic-beanstalk/
- - title: Deploy to Docker Swarm
- localurl: /docs/yaml-examples/examples/docker-swarm/
-
-- title: Integrations
- icon: images/home-icons/cloud-integrations.png
+ - title: Installation options
+ localurl: /docs/installation/installation-options/
+ - title: Codefresh Runner installation
+ localurl: /docs/installation/codefresh-runner/
+ - title: On-Premises installation
+ localurl: /docs/installation/codefresh-on-prem/
+ - title: On-Premises upgrade
+ localurl: /docs/installation/codefresh-on-prem-upgrade/
+ - title: Hosted GitOps installation
+ localurl: /docs/installation/gitops/hosted-runtime/
+ - title: Hybrid GitOps installation
+ localurl: /docs/installation/gitops/hybrid-gitops/
+
+
+
+- title: Administration
+ icon: images/home-icons/administration.svg
url: ''
links:
- - title: Codefresh Hosted GitOps
- new: true
- localurl: /docs/integrations/codefresh-hosted-gitops/
- - title: Git Providers
- localurl: /docs/integrations/git-providers/
- - title: Kubernetes
- localurl: /docs/integrations/kubernetes/
- - title: Amazon Web Services
- localurl: /docs/integrations/amazon-web-services/
- - title: Microsoft Azure
- localurl: /docs/integrations/microsoft-azure/
- - title: Google Cloud
- localurl: /docs/integrations/google-cloud/
- - title: Docker Registries
- localurl: /docs/integrations/docker-registries/
- - title: Secret Storage
- new: true
- localurl: /docs/integrations/secret-storage/
- - title: Helm
- localurl: /docs/integrations/helm/
- - title: Argo CD
- new: true
- localurl: /docs/integrations/argocd/
- - title: Datadog
- new: true
- localurl: /docs/integrations/datadog/
- - title: Jenkins integration/migration
- localurl: /docs/integrations/jenkins-integration/
- - title: Codefresh API
- localurl: /docs/integrations/codefresh-api/
-
-
-- title: "Administration"
- icon: images/home-icons/integrations.svg
+ - title: Create a Codefresh account
+ localurl: /docs/administration/account-user-management/create-codefresh-account/
+ - title: Adding users and teams
+ localurl: /docs/administration/account-user-management/add-users/
+ - title: Set up OAuth2 for Git providers
+ localurl: /docs/administration/account-user-management/oauth-setup/
+ - title: Access control
+ localurl: /docs/administration/account-user-management/access-control/
+ - title: Audit
+ localurl: /docs/administration/account-user-management/audit/
+ - title: User settings
+ localurl: /docs/administration/user-self-management/user-settings/
+ - title: Manage Git PATs
+ localurl: /docs/administration/user-self-management/manage-pats/
+ - title: Codefresh IP addresses
+ localurl: /docs/administration/platform-ip-addresses/
+
+- title: Single Sign-On
+ icon: images/home-icons/administration.svg
+ url: ''
+ links:
+ - title: Federated Single Sign-On (SSO) overview
+ localurl: /docs/single-sign-on/single-sign-on/
+ - title: Setting up OIDC Federated SSO
+ localurl: /docs/single-sign-on/oidc/
+ - title: Setting up SAML2 Federated SSO
+ localurl: /docs/single-sign-on/saml/
+ - title: LDAP Single Sign-On (SSO)
+ localurl: /docs/single-sign-on/ldap/
+
+- title: Reference
+ icon: images/home-icons/guides.png
url: ''
links:
- - title: Installation Options
- localurl: /docs/administration/installation-security
- - title: Codefresh CLI
- url: http://cli.codefresh.io/
- - title: Codefresh behind the firewall
- localurl: /docs/administration/behind-the-firewall
- - title: Codefresh Runner
- localurl: /docs/administration/codefresh-runner
- - title: Codefresh On-Premises Installation
- localurl: /docs/administration/codefresh-on-prem
- - title: Codefresh On-Premises Upgrade
- localurl: /docs/administration/codefresh-on-prem-upgrade
- - title: User Settings
- localurl: /docs/administration/user-settings
- - title: Single Sign on
- localurl: /docs/single-sign-on/sso-overview
- - title: Access Control
- localurl: /docs/administration/access-control
- - title: Audit Logs
- localurl: /docs/administration/audit-logs
- - title: Platform IPs
- localurl: /docs/administration/platform-ip-addresses
+ - title: Git tokens
+ localurl: /docs/reference/git-tokens/
+ - title: Secrets for GitOps
+ localurl: /docs/reference/secrets
+ - title: Shared configuration repo
+ localurl: /docs/reference/shared-configuration/
+
- title: "Incubation"
icon: images/home-icons/plugins.svg
@@ -270,3 +287,8 @@
localurl: /docs/incubation/osx-ios-builds
- title: ARM architecture Support
localurl: /docs/incubation/arm-support
+
+
+
+
+
diff --git a/_data/nav.yml b/_data/nav.yml
index 0e35ae90b..448e8cf33 100644
--- a/_data/nav.yml
+++ b/_data/nav.yml
@@ -1,266 +1,181 @@
-- title: Getting started
- pages:
- - title: Create a Codefresh Account
- - title: Create a Basic Pipeline
- - title: On-demand environments
- - title: Deployment to Kubernetes
- url: "/deployment-to-kubernetes-quick-start-guide"
- - title: Deployment to Kubernetes with Helm
- url: "/helm-quick-start-guide"
- - title: Frequently Asked Questions
- url: "/faq"
-
-- title: Configure a CI/CD pipeline
- url: "/configure-ci-cd-pipeline"
+- title: Introduction
+ url: "/getting-started"
pages:
- - title: "Introduction to Codefresh pipelines"
- url: "/introduction-to-codefresh-pipelines"
- - title: "Creating pipelines"
- url: "/pipelines"
- - title: "Triggers"
- url: "/triggers"
- sub-pages:
- - title: "Git Triggers"
- url: "/git-triggers"
- - title: "DockerHub Triggers"
- url: "/dockerhub-triggers"
- - title: "Azure Triggers"
- url: "/azure-triggers"
- - title: "Quay Triggers"
- url: "/quay-triggers"
- - title: "Helm Triggers"
- url: "/helm-triggers"
- - title: "Artifactory Triggers"
- url: "/jfrog-triggers"
- - title: "Timer (Cron) Triggers"
- url: "/cron-triggers"
- - title: "Monitoring Pipelines"
- - title: "Shared Configuration"
- - title: Using Secrets
- url: "/secrets-store"
- - title: "Caching"
- url: "/pipeline-caching"
- - title: "Public logs and status badges"
- url: "/build-status"
- - title: Running pipelines locally
- url: "/running-pipelines-locally"
- - title: Debugging pipelines
- url: "/debugging-pipelines"
+ - title: What is Codefresh?
+ url: "/intro-to-codefresh"
+ - title: Codefresh for CI
+ url: "/ci-codefresh"
+ - title: Codefresh for CD
+ url: "/cd-codefresh"
+ - title: Codefresh for GitOps
+ url: "/gitops-codefresh"
+ - title: Concepts in Codefresh
+ url: "/concepts"
+
-- title: Learn by example
- url: "/learn-by-example"
+- title: Quick starts
+ url: "/quick-start"
pages:
- - title: Go
- url: "/golang"
- sub-pages:
- - title: 'Go Web Docker'
- url: "/golang-hello-world"
- - title: 'Go CLI'
- url: "/goreleaser"
- - title: Java
- url: "/java"
+ - title: Create Codefresh account
+ url: "/create-codefresh-account"
+ - title: CI/CD quick starts
+ url: "/ci-quick-start"
sub-pages:
- - title: Spring Boot 2/Maven
- url: "/spring-boot-2"
- - title: Gradle
- url: "/gradle"
- - title: Publish JAR
- url: "/publish-jar"
- - title: Node.js
- url: "/nodejs"
+ - title: Pipeline quick start
+ url: "/create-ci-pipeline"
+ - title: Kubernetes deployment quick start
+ url: "/deploy-to-kubernetes"
+ - title: Helm quick start
+ url: "/deploy-with-helm"
+ - title: On-demand environment quick start
+ url: "/on-demand-environments"
+ - title: GitOps quick starts
+ url: "/gitops-quick-start"
sub-pages:
- - title: Let's Chat
- url: "/lets-chat"
- - title: Voting app
- url: "/voting-app"
- - title: React
- url: "/react"
- - title: Php
- url: "/php"
- - title: Python
- url: "/python"
- sub-pages:
- - title: Django
- url: "/django"
- - title: Voting app
- url: "/voting-app"
- - title: Ruby On Rails
- url: "/ruby"
- - title: "C/C++"
- url: "/cc"
- sub-pages:
- - title: 'C'
- url: "/c-make"
- - title: 'C++'
- url: "/cpp-cmake"
- - title: Rust
- url: "/rust"
- - title: C# (.NET Core)
- url: "/dotnet"
- - title: Scala
- url: "/scala"
- sub-pages:
- - title: 'Scala: Hello World'
- url: "/scala-hello-world"
- - title: Mobile
- url: "/mobile"
- sub-pages:
- - title: 'Android'
- url: "/android"
- - title: General
- url: "/general"
- sub-pages:
- - title: Selenium test
- url: "/selenium-test"
+ - title: Provision a hosted runtime
+ url: "/install-hosted"
+ - title: Prepare for hybrid runtime installation
+ url: "/verify-requirements"
+ - title: Install a hybrid runtime
+ url: "/runtime"
+ - title: Create an application
+ url: "/create-app-ui"
+ - title: Create and commit resources for application
+ url: "/create-app-specs"
+ - title: Update the image tag for application
+ url: "/create-rollout"
+
-- title: CI/CD Guides
+
+
+- title: Dashboards & insights
+ url: "/dashboards"
+ pages:
+ - title: GitOps Overview dashboard
+ url: "/home-dashboard"
+ - title: DORA metrics
+ url: "/dora-metrics"
+ - title: Images
+ url: "/images"
+
+
+
+- title: CI/CD guides
url: "/ci-cd-guides"
pages:
- - title: "Build your app"
+ - title: Building your app
url: "/packaging-compilation"
- - title: "Building Docker Images"
+ - title: Building Docker images
url: "/building-docker-images"
- - title: "Working with Docker registries"
- url: "/working-with-docker-registries"
- - title: "Pull Requests and branches"
+ - title: Accessing Docker registries from Kubernetes cluster
+ url: "/access-docker-registry-from-kubernetes"
+ - title: Working with Docker registries
+ url: "/working-with-docker-registries"
+ - title: Adding config maps to namespaces
+ url: "/add-config-maps-to-your-namespaces"
+ - title: Pull Requests and branches
url: "/pull-request-branches"
- - title: "Pipelines for Microservices"
+ - title: Building microservices
url: "/microservices"
- - title: "Production and Staging deployments"
+ - title: Deploying to predefined environments
url: "/environment-deployments"
- - title: "Preview Environments"
- url: "/preview-environments"
- - title: "GitOps Deployments"
- url: "/gitops-deployments"
- - title: "Progressive Delivery"
- url: "/progressive-delivery"
-
-- title: Codefresh YAML
- url: "/codefresh-yaml"
- pages:
- - title: "Pipeline definition"
- url: "/what-is-the-codefresh-yaml"
- - title: Steps
- url: "/steps"
- sub-pages:
- - title: "Git-Clone"
- url: "/git-clone"
- - title: "Freestyle"
- url: "/freestyle"
- - title: "Build"
- url: "/build"
- - title: "Push"
- url: "/push"
- - title: "Composition"
- url: "/composition"
- - title: "Launch-Composition"
- url: "launch-composition"
- - title: "Deploy"
- url: "/deploy"
- - title: "Approval"
- url: "/approval"
- - title: Stages
- url: "/stages"
- - title: "Variables"
- url: "/variables"
- - title: "Conditional Execution of Steps"
- url: "/conditional-execution-of-steps"
- - title: "Service containers"
- url: "/service-containers"
- - title: "Post-Step Operations"
- url: "/post-step-operations"
- - title: "Advanced Workflows"
- url: "/advanced-workflows"
- - title: "Deployment environments"
- url: "/deployment-environments"
- - title: "Condition Expression Syntax"
- url: "/condition-expression-syntax"
- - title: "Hooks"
- url: "/hooks"
- - title: "Docker image Metadata"
- url: "/docker-image-metadata"
- - title: "Annotations"
- url: "/annotations"
+ - title: Previewing dynamic environments
+ url: "/preview-environments"
+ - title: Helm best practices
+ url: "/helm-best-practices"
+ - title: Kubernetes templating
+ url: "/kubernetes-templating"
+ - title: Image enrichment
+ url: "/image-enrichment"
-- title: "YAML Examples"
- url: "/yaml-examples"
+
+
+
+- title: Example catalog
+ url: "/example-catalog"
pages:
- - title: Examples
- url: "/examples"
- - title: "Git"
- url: "/examples"
+ - title: CI examples
+ url: "/ci-examples"
sub-pages:
- - title: Checking out Git repositories
+ - title: Check out Git repositories
url: "/git-checkout"
- - title: Custom Git commmands
+ - title: Custom Git commands
url: "/git-checkout-custom"
- - title: Non git checkouts
+ - title: Non-Git checkouts
url: "/non-git-checkout"
- title: Use Git Hash in CI
url: "/get-short-sha-id-and-use-it-in-a-ci-process"
- - title: "Image Builds"
- url: "/examples"
- sub-pages:
- - title: Build an Image with the Dockerfile in Root Directory
- url: "/build-an-image-dockerfile-in-root-directory"
- - title: Build an Image - Specify Dockerfile Location
+ - title: Build an Image with the Dockerfile in root directory
+ url: "/build-an-image-with-the-dockerfile-in-root-directory"
+ - title: Build an Images specifying Dockerfile Location
url: "/build-an-image-specify-dockerfile-location"
- - title: Build an Image from a Different Git Repository
+ - title: Build an Image from a different Git repository
url: "/build-an-image-from-a-different-git-repository"
- - title: Build and Push an Image
+ - title: Build and push an Image
url: "/build-and-push-an-image"
- - title: Build an Image with Build Arguments
+ - title: Build an Image with build arguments
url: "/build-an-image-with-build-arguments"
- - title: Sharing data between steps
+ - title: Share data between steps
url: "/shared-volumes-between-builds"
- - title: Uploading/downloading from Google Storage buckets
+ - title: Upload/download from Google Storage buckets
url: "/uploading-or-downloading-from-gs"
- - title: Calling other pipelines
+ - title: Call other pipelines
url: "/call-child-pipelines"
- - title: Trigger a K8s Deployment from a DockerHub Push Event
- url: "/trigger-a-k8s-deployment-from-docker-registry"
- - title: "Testing"
- url: "/examples"
- sub-pages:
- - title: Run Unit Tests
+ - title: Run unit tests
url: "/run-unit-tests"
- - title: Run Integration Tests
+ - title: Run integration tests
url: "/run-integration-tests"
- - title: Fan-in/Fan-out Example with Unit Tests
- url: "fan-in-fan-out"
- - title: "Code Coverage"
- url: "/examples"
- sub-pages:
- - title: Codecov Coverage Reports
+ - title: Fan-in/fan-out with unit tests
+ url: "/fan-in-fan-out"
+ - title: Codecov coverage reports
url: "/codecov-testing"
- - title: Coveralls Coverage Reports
+ - title: Coveralls coverage reports
url: "/coveralls-testing"
- - title: Codacy Coverage Reports
+ - title: Codacy coverage reports
url: "/codacy-testing"
- - title: "Databases"
- url: "/examples"
- sub-pages:
- - title: Run Integration Tests with Mongo
+ - title: Run integration tests with Mongo
url: "/integration-tests-with-mongo"
- - title: Run Integration Tests with MySQL
+ - title: Run integration tests with MySQL
url: "/integration-tests-with-mysql"
- - title: Run Integration Tests with PostgreSQL
+ - title: Run integration tests with PostgreSQL
url: "/integration-tests-with-postgres"
- - title: Run Integration Tests with Redis
+ - title: Run integration tests with Redis
url: "/integration-tests-with-redis"
- title: Populate a database with existing data
url: "/populate-a-database-with-existing-data"
- - title: Shared volumes for composition
+ - title: Share volumes in composition steps
url: "/shared-volumes-of-service-from-composition-step-for-other-yml-steps"
- title: Import data to MongoDB
url: "/import-data-to-mongodb"
- - title: "Deployments"
- url: "/examples"
+ - title: NodeJS + Angular2 + MongoDB
+ url: "/nodejs-angular2-mongodb"
+ - title: Vault secrets pipelines
+ url: "/vault-secrets-in-the-pipeline"
+ - title: Decrypt with Mozilla SOPS
+ url: "/decryption-with-mozilla-sops"
+ - title: Launch Composition
+ url: "/launch-composition"
+ - title: Use Docker compose
+ url: "/launching-a-composition-and-defining-a-service-environment-variables-using-a-file"
+ - title: Send notification to Slack
+ url: "/sending-the-notification-to-slack"
+ - title: Send notification to Jira
+ url: "/sending-the-notification-to-jira"
+ - title: CD examples
+ url: "/cd-examples"
sub-pages:
+ - title: Secure a Docker Container Using HTTP Basic Auth
+ url: "/secure-a-docker-container-using-http-basic-auth"
+ - title: Spring Boot + Kafka + Zookeeper
+ url: "/spring-boot-kafka-zookeeper"
+ - title: Web terminal
+ url: "/web-terminal"
+ - title: Trigger a K8s Deployment from a DockerHub Push Event
+ url: "/trigger-a-k8s-deployment-from-docker-registry"
- title: Deploy to VM
url: "/packer-gcloud"
- - title: Deploy to a VM using ftp
+ - title: Deploy to a VM via FTP
url: "/transferring-php-ftp"
- title: Deploy to Tomcat using SCP
url: "/deploy-to-tomcat-via-scp"
@@ -280,145 +195,50 @@
url: "/deploy-with-kustomize"
- title: Deploy to Docker Swarm
url: "/docker-swarm"
+ - title: GitOps secrets
+ url: "/gitops-secrets"
- title: Amazon ECS/Fargate
url: "/amazon-ecs"
- title: Elastic Beanstalk
- url: "/elastic-beanstalk"
- - title: "Secrets"
- url: "/examples"
- sub-pages:
- - title: Vault Secrets in the Pipeline
- url: "/vault-secrets-in-the-pipeline"
- - title: Decryption with Mozilla SOPS
- url: "/decryption-with-mozilla-sops"
- - title: GitOps secrets
- url: "/gitops-secrets"
- - title: "Compositions"
- url: "/examples"
- sub-pages:
- - title: Launch Composition
- url: "/launch-composition"
- - title: Use Docker compose
- url: "/launching-a-composition-and-defining-a-service-environment-variables-using-a-file"
- - title: "Notifications"
- url: "/examples"
- sub-pages:
- - title: Sending the notification to Slack
- url: "/sending-the-notification-to-slack"
- - title: Sending the notification to Jira
- url: "/sending-the-notification-to-jira"
- - title: "Security"
- url: "/examples"
- sub-pages:
- - title: Secure a Docker Container Using HTTP Basic Auth
- url: "/secure-a-docker-container-using-http-basic-auth"
- - title: "General"
- url: "/examples"
- sub-pages:
- - title: NodeJS + Angular2 + MongoDB
- url: "/nodejs-angular2-mongodb"
- - title: Spring Boot + Kafka + Zookeeper
- url: "/spring-boot-kafka-zookeeper"
- - title: Web terminal
- url: "/web-terminal"
+ url: "/elastic-beanstalk"
-- title: "Testing"
- url: "/testing"
- pages:
- - title: "Unit testing"
- url: "/unit-tests"
- - title: "Integration Tests"
- url: "/integration-tests"
- - title: "Test Reports"
- url: "/test-reports"
- - title: Creating compositions
- url: "/create-composition"
- - title: Dynamic preview environments
- url: "/automatic-preview-environments"
- - title: Security Scanning
- url: "/security-scanning"
- - title: SonarQube Scanning
- url: "/sonarqube-integration"
-
-- title: Deploy to Kubernetes
- url: "/deploy-to-kubernetes"
- pages:
- - title: "Deployment options for Kubernetes"
- url: "/deployment-options-to-kubernetes"
- - title: Connect your Kubernetes cluster
- url: "/add-kubernetes-cluster"
- - title: Manage your Kubernetes cluster
- url: "/manage-kubernetes"
- - title: Environment Dashboard
- url: "/environment-dashboard"
- - title: Accessing a Docker registry from Kubernetes
- url: "/access-docker-registry-from-kubernetes"
- - title: Add config maps to your namespaces
- url: "/add-config-maps-to-your-namespaces"
- - title: Kubernetes manifest templates
- url: "/kubernetes-templating"
- - title: Run custom kubectl commands
- url: "/custom-kubectl-commands"
- - title: Example - Deploy demochat to Kubernetes cluster
- url: "/codefresh-kubernetes-integration-demochat-example"
-
-- title: "Helm Deployments"
- url: "/new-helm"
- pages:
- - title: Helm best practices
- url: "/helm-best-practices"
- - title: Using Helm in a Codefresh pipeline
- url: "/using-helm-in-codefresh-pipeline"
- - title: Helm Releases management
- url: "/helm-releases-management"
- - title: Codefresh Managed Helm Repos
- url: "/managed-helm-repository"
- - title: Helm Charts and repositories
- url: "/add-helm-repository"
- - title: Custom Helm uploads
- url: "/custom-helm-uploads"
- - title: Helm environment promotion
- url: "/helm-environment-promotion"
- - title: Helm 2 Support
- url: "/helm2-support"
-
-- title: Integrations
+- title: Pipeline integrations
url: "/integrations"
pages:
- - title: Codefresh Hosted GitOps
+ - title: Hosted GitOps
url: "/codefresh-hosted-gitops"
- title: Git Providers
url: "/git-providers"
- title: Kubernetes
url: "/kubernetes"
- - title: Amazon Services
+ - title: Amazon Web Services
url: "/amazon-web-services"
- title: Microsoft Azure
url: "/microsoft-azure"
- title: Google Cloud
url: "/google-cloud"
- - title: "Docker Registries"
+ - title: Docker registries
url: "/docker-registries"
sub-pages:
- - title: "Docker Hub"
+ - title: Docker Hub
url: "/docker-hub"
- - title: "Azure Docker Registry"
+ - title: Azure Docker Registry
url: "/azure-docker-registry"
- - title: "Amazon EC2 Container Registry"
+ - title: Amazon EC2 Container Registry
url: "/amazon-ec2-container-registry"
- - title: "Google Container Registry"
+ - title: Google Container Registry
url: "/google-container-registry"
- - title: "Google Artifact Registry"
+ - title: Google Artifact Registry
url: "/google-artifact-registry"
- - title: "JFrog Bintray.io/Artifactory"
+ - title: JFrog Bintray.io/Artifactory
url: "/bintray-io"
- - title: "Quay.io"
+ - title: Quay.io
url: "/quay-io"
- - title: "GitHub Container Registry"
+ - title: GitHub Container Registry
url: "/github-container-registry"
- - title: "DigitalOcean Container Registry"
+ - title: DigitalOcean Container Registry
url: "/digital-ocean-container-registry"
- - title: "Other Registries"
+ - title: Other Registries
url: "/other-registries"
- title: Secret Storage
url: "/secret-storage"
@@ -452,42 +272,272 @@
- title: Codefresh API
url: "/codefresh-api"
-- title: Administration
- url: "/administration"
+
+- title: GitOps integrations
+ url: "/gitops-integrations"
+ pages:
+ - title: Image enrichment with GitOps integrations
+ url: "/image-enrichment-overview"
+ - title: GitOps CI integrations
+ url: "/ci-integrations"
+ sub-pages:
+ - title: Codefresh pipelines
+ url: "/codefresh-classic"
+ - title: GitHub Actions
+ url: "/github-actions"
+ - title: Jenkins
+ url: "/jenkins"
+ - title: GitOps issue tracking integrations
+ url: "/issue-tracking"
+ sub-pages:
+ - title: Jira
+ url: "/jira"
+ - title: GitOps container registry integrations
+ url: "/container-registries"
+ sub-pages:
+ - title: Amazon ECR
+ url: "/amazon-ecr"
+ - title: Docker Hub Registry
+ url: "/dockerhub"
+ - title: GitHub Container Registry
+ url: "/github-cr"
+ - title: JFrog Artifactory
+ url: "/jfrog"
+ - title: Quay Registry
+ url: "/quay"
+
+- title: Deployments
+ url: "/deployments"
+ pages:
+ - title: Kubernetes
+ url: "/kubernetes"
+ sub-pages:
+ - title: Manual Deployments
+ url: "/manual-deployment"
+ - title: Automated Deployments
+ url: "/automated-deployment"
+ - title: Environment dashboard
+ url: "/environment-dashboard"
+ - title: Managing Kubernetes clusters
+ url: "/manage-kubernetes"
+ - title: Custom kubectl commands
+ url: "/custom-kubectl-commands"
+ - title: Helm
+ url: "/helm"
+ sub-pages:
+ - title: Using Helm in a Codefresh pipeline
+ url: "/using-helm-in-codefresh-pipeline"
+ - title: Managing Helm Releases
+ url: "/helm-releases-management"
+ - title: Using managed Helm repos
+ url: "/managed-helm-repository"
+ - title: Helm Charts and repositories
+ url: "/helm-charts-and-repositories"
+ - title: Creating and uploading Helm packages
+ url: "/custom-helm-uploads"
+ - title: Promoting Helm environments
+ url: "/helm-environment-promotion"
+ - title: GitOps
+ url: "/gitops"
+ sub-pages:
+ - title: Creating GitOps applications
+ url: "/create-application"
+ - title: Monitoring GitOps applications
+ url: "/applications-dashboard"
+ - title: Managing GitOps applications
+ url: "/manage-application"
+ - title: Progressive delivery with GitOps
+ url: "/install-argo-rollouts"
+
+
+
+- title: Pipelines
+ url: "/pipelines"
pages:
- - title: Installation Options
- url: "/installation-security"
- - title: Codefresh behind the firewall
+ - title: Introduction to Codefresh pipelines
+ url: "/introduction-to-codefresh-pipelines"
+ - title: Creating pipelines
+ url: "/pipelines"
+ - title: Steps in pipelines
+ url: "/steps"
+ sub-pages:
+ - title: Git-clone
+ url: "/git-clone"
+ - title: Freestyle
+ url: "/freestyle"
+ - title: Build
+ url: "/build"
+ - title: Push
+ url: "/push"
+ - title: Composition
+ url: "/composition"
+ - title: Launch-composition
+ url: "/launch-composition"
+ - title: Deploy
+ url: "/deploy"
+ - title: Approval
+ url: "/approval"
+ - title: Triggers in pipelines
+ url: "/triggers"
+ sub-pages:
+ - title: Git triggers
+ url: "/git-triggers"
+ - title: DockerHub triggers
+ url: "/dockerhub-triggers"
+ - title: Azure triggers
+ url: "/azure-triggers"
+ - title: Quay triggers
+ url: "/quay-triggers"
+ - title: Helm triggers
+ url: "/helm-triggers"
+ - title: Artifactory triggers
+ url: "/jfrog-triggers"
+ - title: Timer (Cron) triggers
+ url: "/cron-triggers"
+ - title: Variables in pipelines
+ url: "/variables"
+ - title: Hooks in pipelines
+ url: "/hooks"
+ - title: Annotations in pipelines
+ url: "/annotations"
+ - title: Conditional execution of steps
+ url: "/conditional-execution-of-steps"
+ - title: Post-step operations
+ url: "/post-step-operations"
+ - title: Grouping steps into stages
+ url: "/stages"
+ - title: Caching in pipelines
+ url: "/pipeline-caching"
+ - title: Debugging pipelines
+ url: "/debugging-pipelines"
+ - title: Monitoring pipelines
+ url: "/monitoring-pipelines"
+ - title: Advanced workflows for pipelines
+ url: "/advanced-workflows"
+ - title: Deployment environments
+ url: "/deployment-environments"
+ - title: Running pipelines locally
+ url: "/running-pipelines-locally"
+ - title: Configuration for pipelines
+ url: "/configuration"
+ sub-pages:
+ - title: Global pipeline settings
+ url: "/pipeline-settings"
+ - title: Shared configuration
+ url: "/shared-configuration"
+ - title: Secrets for pipelines
+ url: "/secrets-store"
+ - title: Public logs and status badges
+ url: "/build-status"
+ - title: Service containers
+ url: "/service-containers"
+ - title: Docker image metadata
+ url: "/docker-image-metadata"
+ - title: Pipeline definitions YAML
+ url: "/what-is-the-codefresh-yaml"
+
+
+- title: Argo Workflows
+ url: "/workflows"
+ pages:
+ - title: Creating workflows
+ url: "/create-pipeline"
+ - title: Nested workflows
+ url: "/nested-workflows"
+ - title: Configure artifact repository
+ url: "/configure-artifact-repository"
+ - title: Selectors for concurrency synchronization
+ url: "/concurrency-limit"
+ - title: Sharing file systems
+ url: "/sharing-file-system"
+
+- title: Testing
+ url: "/testing"
+ pages:
+ - title: Unit testing
+ url: "/unit-tests"
+ - title: Integration testing
+ url: "/integration-tests"
+ - title: Creating test reports
+ url: "/test-reports"
+ - title: Creating compositions
+ url: "/create-composition"
+ - title: Dynamic preview environments
+ url: "/automatic-preview-environments"
+ - title: Security scanning
+ url: "/security-scanning"
+ - title: SonarQube scanning
+ url: "/sonarqube-integration"
+
+
+
+- title: Installation
+ url: "/installation"
+ pages:
+ - title: Options
+ url: "/installation-options"
+ - title: Architecture
+ url: "/runtime-architecture"
+ - title: Runner installation behind firewalls
url: "/behind-the-firewall"
- - title: Codefresh Runner
+ - title: Runner
url: "/codefresh-runner"
- - title: Codefresh On-Premises Installation
+ - title: On-Premises
url: "/codefresh-on-prem"
- - title: Codefresh On-Premises Upgrade
+ - title: On-Premises upgrade
url: "/codefresh-on-prem-upgrade"
- - title: Add Users
- url: "/invite-your-team-member"
- - title: User Settings
- url: "/user-settings"
- - title: Pipeline Execution Context
- url: "/pipeline-execution-context"
- - title: Pipeline Settings
- url: "/pipeline-settings"
- - title: Access Control
- url: "/access-control"
- - title: Audit Logs
- url: "/audit-logs"
- - title: Hybrid installation (legacy)
- url: "/codefresh-hybrid"
- - title: Codefresh Platform IPs
- url: "/platform-ip-addresses"
+ - title: GitOps
+ url:
+ sub-pages:
+ - title: Hosted GitOps Runtime
+ url: "/hosted-runtime"
+ - title: Hybrid GitOps Runtime
+ url: "/hybrid-gitops"
+ - title: Monitoring & managing GitOps Runtimes
+ url: "/monitor-manage-runtimes"
+ - title: Add external clusters to GitOps Runtimes
+ url: "/managed-cluster"
+ - title: Add Git Sources to to GitOps Runtimes
+ url: "/git-sources"
+ - title: Download/upgrade GitOps CLI
+ url: "/upgrade-gitops-cli"
+ - title: CLI
+ url: "/cli"
+
+- title: Administration
+ url: "/administration"
+ pages:
+ - title: Account & user management
+ sub-pages:
+ - title: Create a Codefresh account
+ url: "/create-codefresh-account"
+ - title: Adding users and teams
+ url: "/add-users"
+ - title: Configuring access control
+ url: "/access-control"
+ - title: Setting up OAuth2 for Git providers
+ url: "/oauth-setup"
+ - title: Authorize access to organizations/projects
+ url: "/hosted-authorize-orgs"
+ - title: Pipeline execution context
+ url: "/pipeline-execution-context"
+ - title: Auditing actions in Codefresh
+ url: "/audit"
+ - title: User self-management
+ sub-pages:
+ - title: Managing personal settings
+ url: "/user-settings"
+ - title: Managing Git PATs
+ url: "/manage-pats"
+ - title: Codefresh IP addresses
+ url: "/platform-ip-addresses"
- title: Single Sign-On
url: /single-sign-on
pages:
- - title: SSO Overview
- url: /sso-overview
- - title: Synchronize Teams
+ - title: Single sign-on overview
+ url: /single-sign-on
+ - title: Common configuration
url: /team-sync
- title: OpenID Connect
url: /oidc
@@ -512,10 +562,36 @@
- title: OneLogin
url: /saml-onelogin
- title: PingID SSO
- url: /saml-pingidsso
+ url: /saml-pingid
- title: LDAP
url: /ldap
+- title: Reference
+ url: "/reference"
+ pages:
+ - title: Git tokens
+ url: "/git-tokens"
+ - title: Secrets
+ url: "/secrets"
+ - title: Shared configuration repo
+ url: "/shared-configuration"
+
+- title: What's new
+ url: "/whats-new"
+ pages:
+ - title: Changelog
+ url: "/changelog"
+ - title: GitOps what's new
+ url: "/gitops-whats-new"
+
+- title: New Codefresh
+ url: "/new-codefresh"
+ pages:
+ - title: Navigation quick reference
+ url: "/menu-navigation"
+ - title: Documentation changes
+ url: "/doc-changes"
+
- title: Incubation
url: "/incubation"
pages:
@@ -525,7 +601,7 @@
url: "/osx-ios-builds"
- title: ARM architecture support
url: "/arm-support"
-
+
- title: Troubleshooting
url: "/troubleshooting"
pages:
@@ -540,19 +616,17 @@
url: "/git-clone-step-issue"
- title: Handling commit messages with a quote character
url: "/handling-commit-messages-with-quotes"
- - title: The docker image does not exist or no pull access
+ - title: Docker image does not exist or no pull access
url: "/the-docker-image-does-not-exist-or-no-pull-access"
- title: 'Build step: No such file or directory'
url: "/build-step-no-such-file-or-directory"
- title: No Dockerfile found
url: "/no-dockerfile-found"
- - title: Could not tag image
+ - title: Failed to tag image
url: "/could-not-tag-image"
- - title: Failed to create container of image
- url: "/create-container-failure"
- title: Error Code 137
url: "/error-code-137"
- - title: Too many Requests
+ - title: Too many requests
url: "/dockerhub-rate-limit"
- title: Restoring data from pre-existing image hangs on
url: "/restoring-data-from-pre-existing-image-hangs-on"
@@ -564,34 +638,30 @@
url: "/workflow-terminated-by-system"
- title: cf_export limitations
url: "/cf-export-limitations"
- - title: Validation Port warnings
+ - title: Validation port warnings
url: "/validation-port-warnings"
- - title: Forbidden Cluster Resources
+ - title: Forbidden Kubernetes resources
url: "/forbidden-cluster-resources"
- title: How to use SSH keys in freestyle steps
url: "using-ssh-keys"
- title: Failed to get accounts clusters during workflow
url: "/failed-to-get-accounts-clusters-during-workflow"
- - title: API Paging issues
+ - title: Paging issues for builds and images
url: "/paging-issues-builds-images"
- - title: Git step migration
- url: "/git-step-migration"
- - title: Personal Git Deprecation
+ - title: Deprecating personal Git integrations
url: "/personal-git-deprecation"
+ - title: GitOPs runtimes
+ url: "/runtime-issues"
-- title: What's New?
- url: "/whats-new"
- pages:
- - title: What's New In Codefresh?
- url: "/whats-new"
- title: Terms and Privacy Policy
url: "/terms-and-privacy-policy"
pages:
- title: Terms of Service
url: "/terms-of-service"
- - title: Terms and Privacy
- url: "/privacy-policy"
+ - title: Privacy Policy
+ url: "/privacy-policy"
- title: Service Commitment
- url: "/sla"
-
+ url: "/sla"
+
+
diff --git a/_docs/administration/access-control.md b/_docs/administration/access-control.md
deleted file mode 100644
index 8a12721a7..000000000
--- a/_docs/administration/access-control.md
+++ /dev/null
@@ -1,269 +0,0 @@
----
-title: "Access control"
-description: "How to restrict resources in a company environment"
-group: administration
-redirect_from:
- - /docs/enterprise/access-control/
- - /docs/enterprise-account-mng/ent-account-mng/
- - /docs/enterprise/ent-account-mng/
- - /docs/administration/ent-account-mng/
-toc: true
-
----
-
-Codefresh provides several complementary ways for access control within an organization.
-
-The [first mechanism](#users-and-administrators) is a way to restrict access to parts of the UI that are intended for account administrators. For example, only an account administrator should be able to change integrations with [git providers]({{site.baseurl}}/docs/integrations/git-providers/) and [cloud services]({{site.baseurl}}/docs/deploy-to-kubernetes/add-kubernetes-cluster/).
-
-The [second mechanism](#access-to-kubernetes-clusters-and-pipelines) is policy-based access control via attributes (ABAC) on Kubernetes clusters and pipelines. This allows account administrators to define exactly which teams have access to which clusters and pipelines. For example, access to production clusters should only be granted to a subset of trusted developers/operators. On the other hand, access to a QA/staging cluster can be less strict.
-
-The [third mechanism](#pipeline-definition-restrictions) allows you to restrict the Git repositories used for loading pipeline definitions.
-
-
-## Users and administrators
-
-You can define the level of access (**user** or **administrator**) from the same screen where you [add collaborators]({{site.baseurl}}/docs/accounts/invite-your-team-member/) to your account. From the left sidebar of the Codefresh UI choose *Account Settings* and then click on the *Users & Teams* menu item under *User Management*.
-
-{% include
- image.html
- lightbox="true"
- file="/images/administration/users/invite-users.png"
- url="/images/administration/users/invite-users.png"
- alt="User Access control"
- caption="User Access control"
- max-width="90%"
-%}
-
-Next to each user you can click the drop-down box to decide the level access. There is another drop-down for the [SSO configuration]({{site.baseurl}}/docs/administration/single-sign-on/) as well.
-
-> Note that you need to be an administrator yourself, in order to add new users and change their roles.
-
-People with **User** access level can still use the Codefresh UI for day-to-day operations such as running pipelines, looking at Docker images and inspecting [test reports]({{site.baseurl}}/docs/testing/test-reports/) but they *don't* have access to following screens:
-
-* [Git Integrations]({{site.baseurl}}/docs/integrations/git-providers/)
-* [External docker registry settings]({{site.baseurl}}/docs/docker-registries/external-docker-registries/)
-* [External Helm repositories]({{site.baseurl}}/docs/new-helm/add-helm-repository/)
-* [Cloud provider settings]({{site.baseurl}}/docs/deploy-to-kubernetes/add-kubernetes-cluster/)
-* [Cloud storage settings]({{site.baseurl}}/docs/testing/test-reports/#connecting-your-storage-account)
-* [Shared configuration]({{site.baseurl}}/docs/configure-ci-cd-pipeline/shared-configuration/)
-* [API token generation]({{site.baseurl}}/docs/integrations/codefresh-api/#authentication-instructions)
-* [SSO Settings]({{site.baseurl}}/docs/administration/single-sign-on/)
-* [Runtime environment selection]({{site.baseurl}}/docs/configure-ci-cd-pipeline/pipelines/#pipeline-settings)
-* [Slack settings]({{site.baseurl}}/docs/integrations/notifications/slack-integration/)
-* [Audit logs]({{site.baseurl}}/docs/administration/audit-logs/)
-* ABAC for Kubernetes clusters
-* Billing and charging
-
-Only people with **Administrator** level have access to the respective UI screens.
-
-Note however that **Users** can still control their own email notification settings.
-
-
-## Access to Kubernetes clusters and Pipelines
-
-Codefresh also provides fine-grained control to Kubernetes clusters and pipelines via attributes ([ABAC](https://en.wikipedia.org/wiki/Attribute-based_access_control)). The process involves 3 steps:
-
-1. Assigning custom attributes to your Kubernetes clusters and/or pipelines
-1. Creating teams and assigning users to them
-1. Defining policies using teams, clusters and attribute (who, what, where)
-
-Let's see these steps in order.
-
-### Marking Kubernetes clusters with policy attributes
-
-You can mark your clusters in the [Cloud provider integration page]({{site.baseurl}}/docs/deploy-to-kubernetes/add-kubernetes-cluster/).
-
-{% include image.html
- lightbox="true"
- file="/images/administration/access-control/kubernetes-abac.png"
- url="/images/administration/access-control/kubernetes-abac.png"
- alt="Cluster tags"
- caption="Cluster tags"
- max-width="70%"
- %}
-
-To add a new tag/attribute, hover your mouse on a cluster and click on the *Edit tags* button on the right. You will get a new dialog where you can add multiple tags on a single cluster.
-
-{% include image.html
- lightbox="true"
- file="/images/administration/access-control/tagging-kubernetes-clusters.png"
- url="/images/administration/access-control/tagging-kubernetes-clusters.png"
- alt="Assigning attributes to a cluster"
- caption="Assigning attributes to a cluster"
- max-width="60%"
- %}
-
-The tag names are arbitrary and can be anything you choose that matches your company process. You can mark your clusters with product names, software lifecycle phases, department names or anything that helps your security policies. Note that each cluster
-can be assigned multiple tags, so it very easy to define multiple policies on the same cluster (e.g per project and per team).
-
->Notice that by default, all untagged clusters are seen and can be edited by all users (but not deleted). As soon as you add at least one tag on a cluster, this cluster will only be accessible to people that match the affected policy rules (explained in the next sections).
-
-### Marking pipelines with policy attributes
-
-You can also mark specific pipelines with tags. To do this click on the *Configure* menu on a pipeline and select *edit tags*
-
-
-{% include image.html
- lightbox="true"
- file="/images/administration/access-control/pipeline-tags.png"
- url="/images/administration/access-control/pipeline-tags.png"
- alt="Assigning attributes to a pipeline"
- caption="Assigning attributes to a pipeline"
- max-width="80%"
- %}
-
-Tagging pipelines works in a similar manner to Kubernetes clusters.
-
-
-Once your clusters and pipelines are tagged, you should create teams that work on these clusters.
-
-
-### Creating teams
-
-To create and manage teams of people, from the left sidebar of the Codefresh UI choose *Account Settings* and then click on the *Users & Teams* menu item under *User Management*. Finally choose the second tab called *Teams*
-
-
-> Only Enterprise customers can add new teams. Other Codefresh plans can only use the predefined *Users* and *Admin* teams. [Contact us](https://codefresh.io/contact-us/) if you wish to upgrade to an Enterprise plan.
-
-**Note that team names should only contain lower case alphanumeric characters and hyphens. Spaces are not allowed**. See the screenshot below for some sample team names.
-
-{% include image.html
- lightbox="true"
- file="/images/administration/access-control/teams.png"
- url="/images/administration/access-control/teams.png"
- alt="Managing teams"
- caption="Example teams in Codefresh"
- max-width="80%"
- %}
-
-On this screen you can:
- * Create a new team by clicking on the respective button on the top right
- * Search for a specific team by typing on the top left field
- * Edit a team by clicking on it and assigning people
-
- You can only assign existing collaborators that were added in the *People* screen as explained in the first part of this page.
- You can (and should) assign the same person to multiple teams. In most companies, people have multiple overlapping roles.
-
- >Note that by default there are already two teams for *users* and *admins* which contain the people you [invited as collaborators]({{site.baseurl}}/docs/accounts/invite-your-team-member/).
-
- With the teams in place, the final step is to create security policies.
-
-### Creating a security policy
-
- To define security policies from the left sidebar of the Codefresh UI choose *Account Settings* and then click on the *Permissions* menu item under *User Management*
-
-
- {% include image.html
- lightbox="true"
- file="/images/administration/access-control/kubernetes-policies.png"
- url="/images/administration/access-control/kubernetes-policies.png"
- alt="Kubernetes policies"
- caption="Kubernetes policies"
- max-width="80%"
- %}
-
-Here you can create new security rules using the *who, what, where* pattern. For each rule you select:
-
-1. The team the rule applies to,
-1. Cluster privileges (*Create/delete/read/update*) or pipeline privileges (*Create/delete/read/run/update*), and
-1. The effective tags (multiple tags can be used).
-
-This way you can define any policy you wish per departments, projects, roles etc. for cluster/pipeline access.
-
-There are two custom tags that you can use in rules which are "special":
-
-* `untagged` is a "tag" which refers to all clusters that don't have any tag.
-* `*` (the star character) means *all tags*.
-
-> Note that you cannot add any rules for administrators. Administrators by default have access to all clusters.
-
-#### Description of privileges
-
-For clusters:
-
-* `Create` - cluster creation requires someone to be account administrator anyway so currently this permission isn’t really necessary .
-* `Read` - can only see existing allowed clusters without any ability to change them.
-* `Update` - can see and edit existing allowed cluster resources (which means also perform [installation, removal and rollbacks of Helm charts]({{site.baseurl}}/docs/new-helm/helm-best-practices/)). Tags are managed from account settings, so this permission doesn’t apply to it currently.
-* `Delete` - cluster removal requires someone to be account administrator anyway so currently this permission isn’t really necessary.
-
-For pipelines:
-
-* `Create` - can only create new pipelines, not see, edit (which includes tagging them) or delete them. This permission should also go hand in hand with additional permissions like read/edit untagged pipelines.
-* `Read` - view allowed pipelines only.
-* `Update` - see and edit allowed pipelines only (including tagging them).
-* `Delete` - can delete allowed pipelines only.
-* `Run` - can run allowed pipelines only.
-* `Approve` - resume pipelines that are waiting for manual [approval]({{site.baseurl}}/docs/codefresh-yaml/steps/approval/).
-* `Debug` - allow the usage of the [pipeline debugger]({{site.baseurl}}/docs/configure-ci-cd-pipeline/debugging-pipelines/).
-
-## Security timeout
-
-In the third tab - *Security* of the *Users & teams* screen you can set a timeout for users that perform no action in the Codefresh GUI. The minimum time period is 15 minutes but using the drop-down menu you can also define a number for hours and days.
-
- {% include image.html
- lightbox="true"
- file="/images/administration/access-control/security-timeout.png"
- url="/images/administration/access-control/security-timeout.png"
- alt="Security timeout"
- caption="Security timeout"
- max-width="90%"
- %}
-
-Users will get a short warning 90 seconds before the last 15 minutes (if they are inactive for the defined time period). If they still perform no further actions the system will automatically log them out of Codefresh and they will have to login again in order to use the Codefresh GUI.
-
-The maximum duration time you can set is 30 days.
-
-## Pipeline definition restrictions
-
-By default, when a user [creates a pipeline]({{site.baseurl}}/docs/configure-ci-cd-pipeline/pipelines/), the definition can be loaded from the inline editor or any private or public Git repository. You can restrict this behavior and allow only specific Git sources or even disable completely the loading of pipeline definitions from Git repositories.
-
-
-The global pipeline settings are available at [https://g.codefresh.io/account-admin/account-conf/pipeline-settings](https://g.codefresh.io/account-admin/account-conf/pipeline-settings)
-
-
- {% include image.html
- lightbox="true"
- file="/images/administration/access-control/pipeline-restrictions.png"
- url="/images/administration/access-control/pipeline-restrictions.png"
- alt="Global pipeline restrictions"
- caption="Global pipeline restrictions"
- max-width="80%"
- %}
-
-In this screen there are toggle buttons for the following options:
-
- * Disable/Enable pipeline definitions defined using the inline editor of the Codefresh UI
- * Disable/Enable pipeline definitions from Git repositories connected to Codefresh
- * Disable/Enable pipeline definitions from **any** public URL
-
- Clicking on any of the toggle buttons has a global effect. It will disable the respective GUI method during pipeline creation and will disable
- running of existing pipelines that use that method. For example if you disable the inline editor by clicking the first toggle, all existing pipelines
- that have their pipeline definition defined in the editor will be disabled (the run button will not be clickable).
-
- For more fine-grained restrictions you can visit the Git integration screen of your [Git provider]({{site.baseurl}}/docs/integrations/git-providers/) and expand the *YAML Options* segment.
-
-
- {% include image.html
- lightbox="true"
- file="/images/administration/access-control/pipeline-git-restrictions.png"
- url="/images/administration/access-control/pipeline-git-restrictions.png"
- alt="Pipeline restrictions per Git provider"
- caption="Pipeline restrictions per Git provider"
- max-width="80%"
- %}
-
-
- Here you can restrict the Git repositories that can be used for pipeline definitions
-
- * per git repository name (regex or manual selection)
- * branch name (regex)
- * folder name inside a git repository (glob pattern)
-
-
-For example if you enter `/^((pipeline-definition)$).*/g` in the second field, then users will be able to load pipeline yamls only from a branch named `pipeline-definition` in a Git repository.
-
-
-## What to read next
-
-* [Codefresh installation options]({{site.baseurl}}/docs/administration/installation-security/)
-* [Managing your Kubernetes cluster]({{site.baseurl}}/docs/deploy-to-kubernetes/manage-kubernetes/)
\ No newline at end of file
diff --git a/_docs/administration/account-user-management.md b/_docs/administration/account-user-management.md
new file mode 100644
index 000000000..e85a973b6
--- /dev/null
+++ b/_docs/administration/account-user-management.md
@@ -0,0 +1,15 @@
+---
+title: "Account and User Management"
+description: "Learn how Codefresh supports different users and teams"
+group: administration
+toc: true
+---
+
+Codefresh has comprehensive support for teams and users for handling scenarios for all organization sizes.
+
+* See [how to define users and teams]({{site.baseurl}}/docs/administration/account-user-management/add-users/)
+* Configure [access control]({{site.baseurl}}/docs/administration/account-user-management/access-control/).
+* Get [audit logs]({{site.baseurl}}/docs/administration/account-user-management/audit/) to any runtime (hosted or private)
+* Learn [which IP addresses]({{site.baseurl}}/docs/administration/account-user-management/platform-ip-addresses/) are used for the SAAS runtime.
+
+.
\ No newline at end of file
diff --git a/_docs/administration/account-user-management/access-control.md b/_docs/administration/account-user-management/access-control.md
new file mode 100644
index 000000000..79769f254
--- /dev/null
+++ b/_docs/administration/account-user-management/access-control.md
@@ -0,0 +1,252 @@
+---
+title: "Configuring access control"
+description: "Restrict resources in a company environment"
+group: administration
+sub_group: account-user-management
+redirect_from:
+ - /docs/administration/access-control/
+ - /docs/enterprise/access-control/
+ - /docs/enterprise-account-mng/ent-account-mng/
+ - /docs/enterprise/ent-account-mng/
+ - /docs/administration/ent-account-mng/
+toc: true
+---
+
+Codefresh provides several complementary ways for access control within an organization:
+
+* **Role-based access**: [Role-based access]({{site.baseurl}}/docs/administration/account-user-management/add-users/#users-in-codefresh), restricts access to parts of the Codefresh UI intended for account administrators. For example, only an account administrator should be able to change integrations with [git providers]({{site.baseurl}}/docs/integrations/git-providers/) and [cloud services]({{site.baseurl}}/docs/integrations/kubernetes/#connect-a-kubernetes-cluster).
+
+* **Attribute-based access control (ABAC)**: Policy-based access control via attributes (ABAC), restricts access to [Add Kubernetes clusters with policy attributes](##add-kubernetes-clusters-with-policy-attributes). This option allows account administrators to define exactly which teams have access to which clusters and pipelines. For example, you can grant access to production clusters only to a subset of trusted developers/operators. On the other hand, access to a QA/staging cluster can be less strict.
+
+* **Git-repository access**: Restrict the Git repositories used to load [pipeline definitions](##enabledisable-access-to-pipeline-yamls-by-source).
+
+
+## Role-based access for users and administrators
+
+Role-based access, as either a user or an administrator, is usually defined when you [add users to Codefresh accounts]({{site.baseurl}}/docs/administration/account-user-management/add-users/#users-in-codefresh).
+
+> To add users and assign or change user roles, you must be an administrator yourself.
+
+
+{% include
+ image.html
+ lightbox="true"
+ file="/images/administration/users/invite-users.png"
+ url="/images/administration/users/invite-users.png"
+ alt="User roles for access control"
+ caption="User roles for access control"
+ max-width="90%"
+%}
+
+The table below lists the functionality available for role-based access.
+
+{: .table .table-bordered .table-hover}
+| Functionality | Available for Role |
+| -------------- | -------------- |
+|Run pipelines | `User` and `Admin`|
+|View Docker images | `User` and `Admin`|
+|Inspect text reports | `User` and `Admin`|
+|[Git Integrations]({{site.baseurl}}/docs/integrations/git-providers/) | `Admin`|
+|[External Docker registry settings]({{site.baseurl}}/docs/integrations/docker-registries/) | `Admin`|
+|[External Helm repositories]({{site.baseurl}}/docs/deployments/helm/helm-charts-and-repositories/) | `Admin`|
+|[Cloud provider settings]({{site.baseurl}}/docs//integrations/kubernetes/#connect-a-kubernetes-cluster) | `Admin`|
+|[Cloud storage settings]({{site.baseurl}}/docs/testing/test-reports/#connecting-your-storage-account) | `Admin`|
+|[Shared configuration]({{site.baseurl}}/docs/pipelines/configuration/shared-configuration/) | `Admin`|
+|[API token generation]({{site.baseurl}}/docs/integrations/codefresh-api/#authentication-instructions) | `Admin`|
+|[SSO Settings]({{site.baseurl}}/docs/single-sign-on/) | `Admin`|
+|[Runtime environment selection]({{site.baseurl}}/docs/pipelines/pipelines/#pipeline-settings) | `Admin`|
+|[Slack settings]({{site.baseurl}}/docs/integrations/notifications/slack-intergration/) | `Admin`|
+|[Audit logs]({{site.baseurl}}/docs/administration/audit-logs/) | `Admin`|
+|ABAC for Kubernetes clusters | `Admin`|
+|Billing and charging | `Admin`|
+
+
+
+## ABAC access control for Kubernetes clusters and pipelines
+
+ABAC (Attribute-Based Access Control), allows fine-grained access to Kubernetes clusters and pipelines. See ([ABAC](https://en.wikipedia.org/wiki/Attribute-based_access_control){:target="\_blank"}.
+
+ABAC access control includes:
+
+1. Assigning custom attributes to your Kubernetes clusters
+1. Assiging custom attributes to your pipelines
+1. Defining rules as policies using teams, clusters, and attributes (who, what, where)
+
+
+
+### Add Kubernetes clusters with policy attributes
+
+After adding Kubernetes clusters, you can configure clusters with multiple tags.
+
+Tag names are arbitrary, and can be anything you choose that matches your company process. You can tag your clusters with product names, software lifecycle phases, department names, or name that helps your security policies.
+
+You can assign multiple tags to each cluster, making it easy to define multiple policies on the same cluster. For example, per project and per team.
+
+{% include image.html
+ lightbox="true"
+ file="/images/administration/access-control/kubernetes-abac.png"
+ url="/images/administration/access-control/kubernetes-abac.png"
+ alt="Cluster tags"
+ caption="Cluster tags"
+ max-width="70%"
+ %}
+
+**Before you begin**
+* If needed, [add a Kubernetes cluster]({{site.baseurl}}/docs//integrations/kubernetes/#connect-a-kubernetes-cluster)
+
+**How to**
+
+1. Expand the provider under which you added the cluster.
+1. Mouse over the cluster to which to add tags or attributes, and then click **Edit tags** on the right.
+ The Tags page displays existing tags if any, and allows you to add multiple tags for a single cluster.
+
+
+{% include image.html
+ lightbox="true"
+ file="/images/administration/access-control/tagging-kubernetes-clusters.png"
+ url="/images/administration/access-control/tagging-kubernetes-clusters.png"
+ alt="Assigning tags to a cluster"
+ caption="Assigning tags to a cluster"
+ max-width="60%"
+ %}
+
+{:start="3"}
+1. Click **Add** and type in the tag.
+1. Continue to add tags and when finished, click **Save**.
+
+>By default, all clusters, with and without tags, are displayed and can be edited by all users (but not deleted). As soon as you add at least one tag to a cluster, the cluster is only accessible to users with the required policy rules (explained in the next sections).
+
+### Configure pipelines with policy attributes
+
+Similar to Kubernetes clusters, you can also add tags to specific pipelines.
+
+**Before you begin**
+* If needed, [create a pipeline]({{site.baseurl}}/docs/pipelines/pipelines/)
+
+**How to**
+
+1. In the Codefresh UI, from Pipelines in the sidebar, select [Pipelines](https://g.codefresh.io/pipelines/all/){:target="\_blank"}.
+1. In the row with the target pipline, click the context menu for the pipeline, and then select **Edit tags**.
+1. Type in the new tag, press Enter, and continue to add the tags you need.
+1. When finished, click **Save**.
+
+
+{% include image.html
+ lightbox="true"
+ file="/images/administration/access-control/pipeline-tags.png"
+ url="/images/administration/access-control/pipeline-tags.png"
+ alt="Assigning attributes to a pipeline"
+ caption="Assigning attributes to a pipeline"
+ max-width="80%"
+ %}
+
+
+### Define rules for access control
+Define security rules using the *who, what, where* pattern to control access to clusters and pipelines by departments, projects, roles etc.
+
+For each rule you define, select:
+1. The team the rule applies to
+1. Cluster privileges (*Create/delete/read/update*) or pipeline privileges (*Create/delete/read/run/update*)
+1. Effective tags
+
+
+**Before you begin**
+* Make sure you have [created at least one team]({{site.baseurl}}/docs/administration/account-user-management/add-users/#teams-in-codefresh)
+
+**How to**
+1. In the Codefresh UI, on the toolbar, click the **Settings** icon and then select **Account Settings**.
+1. On the sidebar, from Access & Collaboration, select [**Permissions**](https://g.codefresh.io/account-admin/permissions/teams){:target="\_blank"}.
+1. For each entity, do the following to define a rule:
+ 1. Select the team to which assign the rule.
+ 1. Select the permissions to assign to the team for that entity.
+ 1. Select either all clusters with tags (**All tags**) or all clusters that are untagged (**Without tags**).
+
+ {% include image.html
+ lightbox="true"
+ file="/images/administration/access-control/kubernetes-policies.png"
+ url="/images/administration/access-control/kubernetes-policies.png"
+ alt="Kubernetes policies"
+ caption="Kubernetes policies"
+ max-width="80%"
+ %}
+
+### Description of privileges
+
+**For clusters:**
+
+* `Create`: cluster creation requires someone to be account administrator anyway so currently this permission isn’t really necessary .
+* `Read` - can only see existing allowed clusters without any ability to change them.
+* `Update` - can see and edit existing allowed cluster resources (which means also perform [installation, removal and rollbacks of Helm charts]({{site.baseurl}}/docs/new-helm/helm-best-practices/)). Tags are managed from account settings, so this permission doesn’t apply to it currently.
+* `Delete` - cluster removal requires someone to be account administrator anyway so currently this permission isn’t really necessary.
+
+**For pipelines:**
+
+* `Create` - can only create new pipelines, not see, edit (which includes tagging them) or delete them. This permission should also go hand in hand with additional permissions like read/edit untagged pipelines.
+* `Read` - view allowed pipelines only.
+* `Update` - see and edit allowed pipelines only (including tagging them).
+* `Delete` - can delete allowed pipelines only.
+* `Run` - can run allowed pipelines only.
+* `Approve` - resume pipelines that are waiting for manual [approval]({{site.baseurl}}/docs/pipelines/steps/approval/).
+* `Debug` - allow the usage of the [pipeline debugger]({{site.baseurl}}/docs/pipelines/debugging-pipelines/).
+
+
+
+## Git-repository access restrictions
+
+By default, users can load pipeline definitions when [creating a pipeline]({{site.baseurl}}/docs/pipelines/pipelines/), from the inline editor, or any private or public Git repository.
+
+You can change the default behavior to restrict loading pipeline definitions from specific Git repositories or completely disable loading the definitions from all Git repositories.
+
+### Enable/disable access to pipeline YAMLs by source
+Enable or disable access to pipeline definition YAMLs based on the source of the YAML. These global settings are effective for all pipelines in the account and enables or disables that method of pipeline creation from the Codefresh UI.
+pipeline definitions from:
+ * The inline editor in the Codefresh UI: Disabling the inline editor for example, disables new and _all existing pipelines_
+ with pipeline definitions defined in the Codefresh editor. The Run button is disabled for all such piplines.
+ * Any Git repository connected to Codefresh
+ * **Any** public URL
+
+
+1. In the Codefresh UI, on the toolbar, click the **Settings** icon and then select **Account Settings**.
+1. From Configuration on the sidebar, select [**Pipeline Settings**](https://g.codefresh.io/account-admin/account-conf/pipeline-settings){:target="\_blank"}.
+
+ {% include image.html
+ lightbox="true"
+ file="/images/administration/access-control/pipeline-restrictions.png"
+ url="/images/administration/access-control/pipeline-restrictions.png"
+ alt="Global pipeline restrictions"
+ caption="Global pipeline restrictions"
+ max-width="80%"
+ %}
+
+{:start="3"}
+1. Turn on or off the options as needed.
+
+
+### Define access to Git repositories for pipeline YAMLs
+If access to pipeline definitions are enabled for Git repositories, you can configure fine-grained restrictions through the integrations settings for your [Git provider]({{site.baseurl}}/docs/integrations/git-providers/).
+
+1. In the Codefresh UI, on the toolbar, click the **Settings** icon and then select **Account Settings**.
+1. From Configuration on the sidebar, select [**Pipeline Integrations**](https://g.codefresh.io/account-admin/account-conf/integration){:target="\_blank"}.
+1. Select the Git provider integration, click **Edit**.
+1. Scroll down and expand **YAML Options**.
+
+ {% include image.html
+ lightbox="true"
+ file="/images/administration/access-control/pipeline-git-restrictions.png"
+ url="/images/administration/access-control/pipeline-git-restrictions.png"
+ alt="Pipeline restrictions per Git provider"
+ caption="Pipeline restrictions per Git provider"
+ max-width="80%"
+ %}
+
+{:start="5"}
+1. Configure restrictions for Git repositories that can be used for pipeline definitions:
+ * **Allow only the following repositories**: Toggle **Manual selection** to on, and then select the Git repos, or define a regex according to which to select repos.
+ * **Allow only the following branches**: Select Git repositories by the branches that match the regex. For example, this regex `/^((pipeline-definition)$).*/g`, allows users to load pipeline YAMLs only from a branch named `pipeline-definition` in a Git repository.
+ * **Allow only the following paths**: Select Git repositories by folders within the repo that match the glob pattern).
+
+
+
+## Related articles
+[Codefresh installation options]({{site.baseurl}}/docs/installation/installation-options/)
+[Managing your Kubernetes cluster]({{site.baseurl}}/docs/deployments/kubernetes/manage-kubernetes/)
diff --git a/_docs/administration/account-user-management/add-users.md b/_docs/administration/account-user-management/add-users.md
new file mode 100644
index 000000000..cef306f4a
--- /dev/null
+++ b/_docs/administration/account-user-management/add-users.md
@@ -0,0 +1,119 @@
+---
+title: "Adding users and teams"
+description: "Add users and teams to Codefresh accounts"
+group: administration
+sub_group: account-user-management
+redirect_from:
+ - /docs/administration/invite-your-team-member/
+ - /docs/accounts/
+ - /docs/accounts/invite-your-team-member/
+ - /docs/administration/invite-your-team-member/
+toc: true
+---
+
+Once you have created a Codefresh account, you can add any number of users to collaborate on repositories, workflows, and pipelines, and teams of users.
+
+
+You can then create teams in Codefresh to group users who share a common denominator, such as the same permissions, access to the same functionality, or roles. Teams make it easy for administrators to both define and manage items shared by multiple users in an orgranization.
+
+
+## Users in Codefresh
+Adding a user to an account requires assigning a role to define access to account resources, and optionally, selecting an SSO provider for the user:
+
+* **Role**: Defines the user's access level to the resources in the account.
+ * **User**: The default. With this role, users can work with your repositories and pipelines, but cannot change settings
+on clusters, docker registries, git integrations, shared configurations etc.
+ * **Administrator**: With this role, users have full access to accounts, and can change all settings, so make sure that they are trusted colleagues.
+ For guidelines on access control, see [Access control]({{site.baseurl}}/docs/administration/account-user-management/access-control/).
+* **SSO**: By default, SSO is not enabled for users. If required, explicitly select the SSO provider. For an overview of SSO, see [Single Sign on]({{site.baseurl}}/docs/single-sign-on/).
+
+
+### Add a user to a Codefresh account
+1. In the Codefresh UI, on the toolbar, click the **Settings** icon and then select **Account Settings**.
+1. On the sidebar, from Access & Collaboration select [**Users & Teams**](https://g.codefresh.io/account-admin/collaborators/users){:target="\_blank"}.
+1. Select **Users**, and then select **+ [Add User]**.
+1. Type the **User's email address**, and click **Invite**.
+
+ The user receives an email invitation, and in the Users list, the username is set to Pending, and status to Resend.
+1. From the **Role** dropdown, select either **User** or **Administrator**.
+1. If SSO is configured for the account, **Select SSO provider**.
+
+
+
+### Manage users in a Codefresh account
+
+Once you add a user to your Codefresh account, you can do the following to manage that user:
+* Resend invitations that are pending acceptance: Select  **Resend**.
+* Edit the user's email address: Select  **Edit**.
+* Change the role: From the **Role** dropdown, select the new role.
+* Change SSO provider: From the **SSO** dropdown, select the new SSO provider.
+* Remove the user account: Select  **Delete**.
+
+
+
+## Teams in Codefresh
+Teams are users who share the same permissions, roles, or requirements defined according to company processes. Teams allow you to enforce access control through ABAC (Attribute Based Access Control).
+By default, there are two teams:
+* Users
+* Admins with users [invited as collaborators](#assign-a-user-to-a-team)
+
+> Only Enterprise customers can add new teams. Other Codefresh plans can only use the predefined *Users* and *Admin* teams. [Contact us](https://codefresh.io/contact-us/){:target="\_blank"} to upgrade to an Enterprise plan.
+
+### Create a team in Codefresh
+
+Create a team in Codefresh and then assign users to the team. You can assign the same user to multiple teams, as in most companies, users have overlapping roles.
+
+1. In the Codefresh UI, on the toolbar, click the **Settings** icon and then select **User Management**.
+1. From the sidebar, from Access & Collaboration, select [**Users & Teams**](https://g.codefresh.io/account-admin/collaborators/users){:target="\_blank"}.
+1. Select **Teams**, and then select **Create a Team**.
+1. Enter the **Team Name**.
+ > The team name can include only lower-case alphanumeric characters and hyphens, without spaces.
+
+ See the screenshot below for some sample team names.
+
+{% include image.html
+ lightbox="true"
+ file="/images/administration/access-control/teams.png"
+ url="/images/administration/access-control/teams.png"
+ alt="Examples of teams in Codefresh"
+ caption="Examples of teams in Codefresh"
+ max-width="80%"
+ %}
+
+### Assign a user to a team
+1. To assign users to the team, do the following:
+ 1. Hover over the team name and click the **Settings** icon.
+ 1. Click **Invite to team**, type the email address of the user to invite, and then click **Add**.
+1. To change the name of the team, click **Edit** and type the new name.
+
+## Define session timeouts and domain restrictions for user accounts
+As an administrator, you can optionally define session timeouts to automatically log out users who have been inactive for the specified duration, and restrict invitations to specific email domains.
+
+> The maximum duration for inactivity is 30 days. Inactive users are warned 15 minutes before they are logged out.
+
+1. In the Codefresh UI, on the toolbar, click the **Settings** icon, and then select **Account Settings**.
+1. On the sidebar, from Access & Collaboration, select [**Users & Teams**](https://g.codefresh.io/account-admin/collaborators/users){:target="\_blank"}.
+1. Select **Security**.
+1. For **User Session**, add the timeout duration in minutes/hours/days.
+1. To restrict invitations to specific email domains, below User Invitations, turn on **Restrict inviting additional users..** and then in the **Email domains**, type in the domains to allow, one per line.
+
+ {% include image.html
+ lightbox="true"
+ file="/images/administration/access-control/security-timeout.png"
+ url="/images/administration/access-control/security-timeout.png"
+ alt="Security timeout"
+ caption="Security timeout"
+ max-width="90%"
+ %}
+
+## Troubleshoot add users
+
+* [User is prompted to enter an organization name](https://support.codefresh.io/hc/en-us/articles/360020177959-User-is-prompted-to-enter-an-organization-name){:target="\_blank"}
+* [Account invitation not permitting login](https://support.codefresh.io/hc/en-us/articles/360015251000-Account-invitation-not-permitting-login){:target="\_blank"}
+
+
+## Related articles
+[Access control]({{site.baseurl}}/docs/administration/account-user-management/access-control/)
+[Single Sign on]({{site.baseurl}}/docs/single-sign-on/)
+[Setting up OAuth authentication for Git providers]({{site.baseurl}}/docs/administration/account-user-management/oauth-setup)
+
diff --git a/_docs/administration/account-user-management/audit.md b/_docs/administration/account-user-management/audit.md
new file mode 100644
index 000000000..1903b3547
--- /dev/null
+++ b/_docs/administration/account-user-management/audit.md
@@ -0,0 +1,112 @@
+---
+title: "Auditing actions in Codefresh"
+description: "Get logs of all actions in Codefresh"
+group: administration
+sub_group: account-user-management
+redirect_from:
+ - /docs/administration/audit-logs/
+ - /docs/enterprise/audit-logs/
+toc: true
+---
+
+Codefresh keeps a log of all actions that happen at all times based on API calls that reach Codefresh.
+The time frames covered by audit logs depends on the pricing tier of your Codefresh account.
+
+The audit log includes:
+* UI actions from users
+* [CLI](https://codefresh-io.github.io/cli/){:target="\_blank"} invocations
+* Any [external integrations]({{site.baseurl}}/docs/integrations/codefresh-api/) used with Codefresh
+
+You can:
+* View, filter, and search for audited events
+* View API payload for an event
+* Download the audit log file in CSV
+
+## View audit logs
+The Audit Log is divided into actions audited (All Audit), and tiggers and webhooks processed by Codefresh (Triggers).
+
+
+1. In the Codefresh UI, on the toolbar, click the **Settings** icon and then select **Account Settings**.
+1. On the sidebar, from Access & Collaboration, select [**Audit**](https://g.codefresh.io/account-admin/audit/audit-all){:target="\_blank"}.
+1. To focus on a specific time frame, select the date range from the toolbar.
+ The All Audit tab includes all Codefresh events in your account, sorted by the most recent events.
+ Each event shows the following details:
+ * `Entity ID/Name`: The entity that was affected.
+ * `Entity type`: The type of entity on which the action was action, such as user, team, build, pipeline, project, etc.
+ * `Action`: The action that was taken on the entity.
+ * `Status`: The result of the API call.
+ * `User`: The name of the user who performed the action.
+ * `Last Request`: The time of the event.
+
+
+{% include image.html
+lightbox="true"
+file="/images/administration/audit/audit-logs.png"
+url="/images/administration/audit/audit-logs.png"
+alt="Audit Logs view"
+caption="Audit Logs view"
+max-width="70%"
+%}
+
+
+The Triggers tab includes all the triggers/webhooks that were processed by Codefresh, with the same information as the Audit tab.
+
+{% include image.html
+lightbox="true"
+file="/images/administration/audit/audit-triggers.png"
+url="/images/administration/audit/audit-triggers.png"
+alt="Audit Triggers view"
+caption="Audit Triggers view"
+max-width="70%"
+%}
+
+
+Both tabs have built-in paging and filtering.
+
+
+
+### Filter audited events
+
+Filter audited events to focus on a specific entity or user.
+
+{% include image.html
+lightbox="true"
+file="/images/administration/audit/audit-filter.png"
+url="/images/administration/audit/audit-filter.png"
+alt="Filtering audit actions"
+caption="Filtering audit actions"
+max-width="40%"
+%}
+
+
+### Get more details for audited events
+
+You can get the exact API payload for each event as it was sent to Codefresh, including the URL and other call parameters used for the selected event.
+
+* At the right of the row with the event, click the **More Details** (book) icon.
+
+
+{% include image.html
+lightbox="true"
+file="/images/administration/audit/api-call-details.png"
+url="/images/administration/audit/api-call-details.png"
+alt="API call details for audited event"
+caption="API call details for audited event"
+max-width="40%"
+%}
+
+
+
+## Export audit logs
+
+Export all audited events, both Audits and Triggers, to a `CSV` file, for offline processing with your own tools or for viewing in external applications such as Microsoft Excel.
+
+* On the top right of the toolbar, click **Download Audit**.
+ The downloaded file includes in addition to the events themselves, the API call information (payload and parameters) for each event.
+
+
+
+## Related articles
+[Codefresh installation options]({{site.baseurl}}/docs/installation/installation-options/)
+[Configuring access Control]({{site.baseurl}}/docs/administration/account-user-management/access-control/)
+[Codefresh API integration]({{site.baseurl}}/docs/integrations/codefresh-api/)
diff --git a/_docs/administration/account-user-management/create-codefresh-account.md b/_docs/administration/account-user-management/create-codefresh-account.md
new file mode 100644
index 000000000..d6caf0586
--- /dev/null
+++ b/_docs/administration/account-user-management/create-codefresh-account.md
@@ -0,0 +1,221 @@
+---
+title: "Create a Codefresh account"
+description: "Welcome to Codefresh!"
+group: administration
+sub_group: account-user-management
+redirect_from:
+ - /docs/getting-started/create-a-codefresh-account/
+ - /docs/
+ - /docs/create-an-account/
+ - /docs/getting-started/
+ - /docs/getting-started/introduction/
+---
+Before you can do create pipelines, build, and deploy applications in Codefresh, you need to create a Codefresh account.
+
+Creating an account in Codefresh is free (no credit card is required) and can be done in three simple steps
+
+{% include
+image.html
+lightbox="true"
+file="/images/administration/create-account/create-account-steps.png"
+url="/images/administration/create-account/create-account-steps.png"
+alt="Codefresh account creation steps"
+max-width="90%"
+%}
+
+## Step 1: Select your Identity Provider
+As the first step in setting up your account in Codefresh, select the identity provider (IdP) to use.
+Codefresh currently supports the following IdPs:
+* GitHub
+* Bitbucket
+* GitLab
+* Azure
+* Google
+* LDAP
+
+If you need an IdP that is not in the list, please [contact us](https://codefresh.io/contact-us/) with the details.
+
+>NOTES:
+ For Git repositories, the login method is less important, as you can Git repositories through [Git integrations]({{site.baseurl}}/docs/integrations/git-providers/), regardless of your sign-up process.
+
+ If you have multiple sign-up methods, as long as you use the same email address for all sign-ups, Codefresh automatically redirects you to the account dashboard.
+
+1. Go to the [Codefresh Sign Up page](https://g.codefresh.io/signup){:target="\_blank"}.
+
+
+{% include
+image.html
+lightbox="true"
+file="/images/administration/create-account/select-identity-provider.png"
+url="/images/administration/create-account/select-identity-provider.png"
+alt="Codefresh sign-up page"
+caption="Codefresh sign-up page"
+max-width="40%"
+%}
+
+{:start="2"}
+1. Select the IdP for sign-up.
+1. Continue with [Step 2: Accept the permissions request](#step2-accept-the-permissions-request).
+
+
+
+## Step 2: Accept the permissions request
+
+After you select the IdP (identity provider), Codefresh requests permission to access your basic details, and for Git providers, to access your Git repositories. The Permissions window that is displayed differs according to the IdP selected in the previous step.
+
+Don't worry, Codefresh will not do anything without your explicit approval. Codefresh needs the permissions to build and deploy your projects.
+
+1. Do any of the following:
+ * For GitHub: To continue, click **Authorize codefresh-io**.
+
+{% include
+image.html
+lightbox="true"
+file="/images/administration/create-account/github-authorize.png"
+url="/images/administration/create-account/github-authorize.png"
+alt="GitHub authorization page"
+caption="GitHub authorization page"
+max-width="50%"
+%}
+
+ * For Bitbucket: To continue, click **Grant access**.
+
+
+{% include
+image.html
+lightbox="true"
+file="/images/administration/create-account/bitbucket-authorize.png"
+url="/images/administration/create-account/bitbucket-authorize.png"
+alt="Bitbucket authorization page"
+caption="Bitbucket authorization page"
+max-width="50%"
+%}
+
+ * For GitLab: To continue, click **Authorize**.
+
+
+{% include
+image.html
+lightbox="true"
+file="/images/administration/create-account/gitlab-authorize.png"
+url="/images/administration/create-account/gitlab-authorize.png"
+alt="GitLab authorization page"
+caption="GitLab authorization page"
+max-width="50%"
+%}
+
+ Once you confirm the permissions for your Git provider, Codefresh automatically connects to your Git provider and fetches your basic account details, such as your email.
+
+{:start="2"}
+1. Continue with [Step 3: Verify account details](#step-3-verify-account-details).
+
+## Step 3: Verify account details
+
+Verifying account details is the final step in creating your Codefresh account.
+
+1. Review the details for your new account, make the relevant changes, and click **NEXT**.
+
+{% include
+image.html
+lightbox="true"
+file="/images/administration/create-account/codefresh-signup.png"
+url="/images/administration/create-account/codefresh-signup.png"
+alt="Codefresh account details"
+caption="Codefresh account details"
+max-width="40%"
+%}
+
+{:start="2"}
+1. Enter a name for your account, and click **NEXT**.
+
+{% include
+image.html
+lightbox="true"
+file="/images/administration/create-account/codefresh-accountname.png"
+url="/images/administration/create-account/codefresh-accountname.png"
+alt="Codefresh account name"
+caption="Codefresh account name"
+max-width="40%"
+%}
+
+{:start="3"}
+1. Finally, answer the questions to personalize your account and click **FINISH**.
+
+{% include
+image.html
+lightbox="true"
+file="/images/administration/create-account/codefresh-personalize.png"
+url="/images/administration/create-account/codefresh-personalize.png"
+alt="Codefresh personalize account"
+caption="Codefresh personalize account "
+max-width="40%"
+%}
+
+Congratulations! Your new Codefresh account is now ready.
+
+{% include
+image.html
+lightbox="true"
+file="/images/administration/create-account/codefresh-dashboard.png"
+url="/images/administration/create-account/codefresh-dashboard.png"
+alt="Codefresh dashboard"
+caption="Codefresh dashboard"
+max-width="40%"
+%}
+
+
+
+
+## Related articles
+[Adding users and teams]({{site.baseurl}}/docs/administration/account-user-management/add-users/)
+[Configuring access control]({{site.baseurl}}/docs/administration/account-user-management/access-control/)
+[Codefresh IP addresses]({{site.baseurl}}/docs/administration/account-user-management/platform-ip-addresses/)
+[CI pipeline quick start]({{site.baseurl}}/docs/quick-start/ci-quick-start/create-ci-pipeline/)
+[Kubernetes deployment quick start]({{site.baseurl}}/docs/quick-start/ci-quick-start/deploy-to-kubernetes)
+[Pipeline examples]({{site.baseurl}}/docs/example-catalog/ci-examples/)
+
+
+
+
diff --git a/_docs/administration/account-user-management/hosted-authorize-orgs.md b/_docs/administration/account-user-management/hosted-authorize-orgs.md
new file mode 100644
index 000000000..26f971d42
--- /dev/null
+++ b/_docs/administration/account-user-management/hosted-authorize-orgs.md
@@ -0,0 +1,31 @@
+---
+title: "Authorize organizations/projects"
+description: ""
+group: administration
+sub_group: account-user-management
+toc: true
+---
+
+If your Git provider has an OAuth application for Codefresh, you need to authorize access to the app's organizations/projects to see them in Codefresh.
+> Authorization is per organization.
+
+## Authorize organizations in GitHub
+
+Request or grant access to the organizations defined for the OAuth Codefresh application.
+
+1. Go to [GitHub > Settings](https://github.com/settings/developers){:target="\_blank"}.
+1. Click the **Codefresh** application.
+1. In the list of organizations that appears, for every organization you need to authorize, click **Request** or **Grant**, as relevant.
+
+{% include
+image.html
+lightbox="true"
+file="/images/administration/authorize-github-oauth-apps.png"
+url="/images/administration/authorize-github-oauth-apps.png"
+alt="Authorize Codefresh organizations in GitHub"
+caption="Authorize Codefresh organizations in GitHub"
+max-width="70%"
+%}
+
+## Related articles
+[Connect Git provider]({{site.baseurl}}/docs/installation/gitops/hosted-runtime/#2-connect-git-provider)
diff --git a/_docs/administration/account-user-management/oauth-setup.md b/_docs/administration/account-user-management/oauth-setup.md
new file mode 100644
index 000000000..b2115747b
--- /dev/null
+++ b/_docs/administration/account-user-management/oauth-setup.md
@@ -0,0 +1,228 @@
+---
+title: "Setting up OAuth2 for Git providers"
+description: ""
+group: administration
+sub_group: account-user-management
+toc: true
+---
+
+Codefresh integrates with the Git provider defined for your GitOps runtime account to sync repositories to your clusters, implementing Git-based operations when creating resources such as Delivery Pipelines, applications, and enriching images with valuable information.
+
+As the account administrator, you can select the authentication method for a runtime account. Users in Codefresh will then authorize access to the Git providers through the defined mechanism.
+
+{% include
+ image.html
+ lightbox="true"
+ file="/images/authentication/authentication-list.png"
+ url="/images/authentication/authentication-list.png"
+ alt="Git provider authentication accounts"
+ caption="Git provider authentication accounts"
+ max-width="80%"
+ %}
+
+Codefresh supports OAuth2 or personal access tokens (PATs) for authentication:
+
+* OAuth2 with Codefresh OAuth Application or custom OAuth2 Application
+ OAuth2 is the preferred authentication mechanism, supported for popular Git providers such as GitHub, GitHub Enterprise, GitLab Cloud and Server, and Bitbucket Cloud and Server.
+ You have the option to use the default predefined Codefresh OAuth Application, or a custom Oauth2 Application for Codefresh in your Git provider account.
+ Hosted runtime accounts automatically use Codefresh's predefined OAuth Application.
+ To use a custom Oauth2 Application for Codefresh, first create the application in your Git provider account, then create a secret on your K8s cluster, and finally configure OAuth2 access for the custom application in Authentication > Settings. See [Create a custom OAuth2 Application for Git provider](#create-a-custom-oauth2-application-for-git-provider) in this article.
+
+* Token-based authentication using PAT
+ With token-based authentication, users must generate personal access tokens from their Git providers with the required scopes and enter their personal access tokens when prompted to authorize access. See [Authorize Git access in Codefresh]({{site.baseurl}}/docs/administration/user-self-management/user-settings/#git-provider-private-access).
+
+
+
+## Authentication for Git providers and runtime accounts
+The [Git Authentication](https://g.codefresh.io/2.0/account-settings/authentication?providerName=github){:target="\_blank"} page displays the accounts by Git provider and the authentication method selected for the same.
+
+Authentication accounts are organized by Runtimes. A runtime can have a single authentication account.
+The Type column identifies the authentication for the provider account as either Codefresh, Custom, or PAT (personal access token).
+
+{% include
+ image.html
+ lightbox="true"
+ file="/images/authentication/authentication-list.png"
+ url="/images/authentication/authentication-list.png"
+ alt="Git provider authentication accounts"
+ caption="Git provider authentication accounts"
+ max-width="80%"
+ %}
+
+As the account administrator, you can change the authentication method for a Hybrid GitOps runtime at any time to either Codefresh, Custom, or manual token entry. See [Select authentication mechanism for runtime](#select-authentication-mechanism-for-runtime).
+
+## Create a custom OAuth2 Application for Git provider
+Create a custom OAuth2 Application for Codefresh in your Git provider accounts with the correct scopes, and set up authentication for the same within Codefresh. Users in Codefresh can then authorize access to the Git provider using OAuth2, instead of a personal access token.
+
+Supported Git providers:
+* GitHub and GitHub Enterprise
+* GitLab Cloud and GitLab Server
+* Bitbucket Cloud (hosted) and Bitbucket Server (hybrid)
+
+{::nomarkdown}
+
+{:/}
+
+To set up OAuth2 authorization in Codefresh, you must:
+1. [Create Custom OAuth2 Application in Git](#step-1-create-a-custom-oauth2-application-in-git)
+1. [Create a K8s `secret` in the runtime cluster](#step-2-create-a-k8s-secret-resource-in-the-runtime-cluster)
+1. [Configure OAuth2 settings for Custom Application in Codefresh](#step-3-configure-oauth2-settings-for-custom-application-in-codefresh)
+
+{::nomarkdown}
+
+{:/}
+
+### Step 1: Create a custom OAuth2 Application in Git
+Create and register an OAuth App under your organization to authorize Codefresh.
+
+1. Follow the step-by-step instructions for your Git provider:
+
+ * [GitHub](https://docs.github.com/en/developers/apps/building-oauth-apps/creating-an-oauth-app){:target="\_blank"}:
+ * For **Authorization callback URL**, enter this value:
+ `/app-proxy/api/git-auth/github/callback`
+ where:
+ `` is the IP address or URL of the ingress host in the runtime cluster.
+ * Make sure **Enable Device Flow** is _not_ selected.
+ * Select **Register application**.
+ The client ID is automatically generated, and you are prompted to generate the client secret.
+ * Select **Generate a new client secret**, and copy the generated secret.
+
+ * [GitLab Cloud and Server](https://docs.gitlab.com/ee/integration/oauth_provider.html#user-owned-applications){:target="\_blank"}:
+ * For **Redirect URI**, enter this value:
+ `/app-proxy/api/git-auth/gitlab/callback`
+ where:
+ `` is the IP address or URL of the ingress host in the runtime cluster.
+
+ * [Bitbucket Server](https://confluence.atlassian.com/adminjiraserver0902/configure-an-outgoing-link-1168853925.html){:target="\_blank"}:
+ * For **Callback URL**, enter this value:
+ `/app-proxy/api/git-auth/bitbucket-server/callback`
+ where:
+ `` is the IP address or URL of the ingress host in the runtime cluster.
+
+ > OAuth2 is not supported for hybrid runtimes with Bitbucket Cloud as the Git provider. Users can authorize access with their [Git personal access tokens](({{site.baseurl}}/docs/administration/user-self-management/user-settings/#authorize-git-access-in-codefresh)) in such cases.
+
+
+{:start="2"}
+1. Note down the following, as you will need them to create the K8s secret for the Git OAuth2 application:
+ * GitHub: Application ID from the URL, Client ID, and the client secret
+ * GitLab Cloud and Server: Application ID and Secret
+ * Bitbucket Server: Key and Secret
+
+{::nomarkdown}
+
+{:/}
+
+### Step 2: Create a K8s secret resource in the runtime cluster
+Create a K8s secret in the runtime cluster, using the example below as a guideline. You must define the application ID (`appId`), client ID (`clientId`) and the client secret (`clientSecret`) from the OAuth2 Application you created in your Git provider, and the Git URL (`url`).
+
+> All fields in the secret _must be_ encoded in `base64`.
+ To encode, use this command: `echo -n VALUE | base64`.
+
+
+**Before you begin**
+
+Make sure you have the following handy:
+* GitHub: Application ID from the URL, Client ID, and the client secret
+* GitLab Cloud and Server: Application ID and Secret
+* Bitbucket Server: Key and Secret
+
+
+**How to**
+
+1. Create the manifest for the K8s secret resource.
+
+```yaml
+apiVersion: v1
+kind: Secret
+type: Opaque
+metadata:
+ name: github-oauth2
+ namespace: # replace with the name of the runtime
+ labels:
+ codefresh_io_entity: git-pat-obtainer-sec
+data:
+ appId: # application ID of your OAuth app
+ clientId: # client ID of your OAuth app
+ clientSecret: # client secret of your OAuth app
+ url: https://github.com # Git provider URL which by default is github.com, unless self-hosted provider
+```
+
+{:start="2"}
+1. Apply the secret to the runtime cluster:
+ `kubectl apply -f `
+
+{::nomarkdown}
+
+{:/}
+
+### Step 3: Configure OAuth2 settings for Custom Application in Codefresh
+
+Configure the settings for the Custom OAuth2 Application in Codefresh. Configuring the settings creates a K8s ConfigMap that references the OAuth secret credentials. When configuring the settings, you can work in Form mode, or directly update the YAML manifest.
+
+>Important:
+ > The values for all the settings in the ConfigMap are the `keys` in the secret file.
+
+1. In the Codefresh UI, go to [Authentication](https://g.codefresh.io/2.0/account-settings/authentication?providerName=github){:target="\_blank"}.
+ The list always shows the default predefined Codefresh provider account and custom provider accounts created, organized by Runtime, Type (Codefresh or Custom) and Status.
+1. From the list, select the Git provider and the runtime to which to apply the current configuration.
+ >The runtime must be identical to the runtime to which you saved the K8s secret.
+1. Click **Edit** and then select **Use custom provider**.
+ > If you have managed clusters registered to the selected runtime, the authentication account is available to all the clusters.
+ The settings page is opened in **Form** mode.
+
+{% include
+ image.html
+ lightbox="true"
+ file="/images/authentication/oauth-custom-settings.png"
+ url="/images/authentication/oauth-custom-settings.png"
+ alt="OAuth settings for custom provider in Codefresh"
+ caption="OAuth settings for custom provider in Codefresh"
+ max-width="50%"
+ %}
+
+{:start="4"}
+1. Configure the settings for the **Git OAuth2 Application**, either in **Form** or in **YAML** modes:
+ * **Secret Name**: The name of the K8s secret file you created in the runtime cluster.
+ * **Secret Namespace**: The namespace in the runtime cluster where you created the K8s secret.
+ * **Application ID**: The `key` representing the OAuth application ID in the K8s secret. For example, `appId`.
+ * **Client ID**: The `key` representing the client ID in the K8s secret. For example, `clientId`.
+ * **Client Secret**: The `key` representing the client secret in the K8s secret. For example, `clientSecret`.
+ * **URL**: The `key` representing the Git provider URL in the K8s secret. For example, `url`.
+
+{:start="5"}
+1. Click **Commit**.
+ The Commit Changes panel shows a summary of the settings and the final version of the YAML manifest in read-only mode.
+
+{% include
+ image.html
+ lightbox="true"
+ file="/images/authentication/oauth-custom-commit-settings.png"
+ url="/images/authentication/oauth-custom-commit-settings.png"
+ alt="OAuth settings for custom provider in Codefresh"
+ caption="OAuth settings for custom provider in Codefresh"
+ max-width="50%"
+ %}
+
+{:start="6"}
+1. From the **Select Git Source** list, select the Git Source in which to store the manifest for the `ConfigMap` you are creating.
+ The list displays all the Git Sources created for the selected runtime.
+1. Optional. Enter a commit message.
+1. At the bottom-right, click **Commit** once again.
+
+You have completed the setup to authorize Codefresh as an OAuth App for your Git provider.
+
+## Select authentication mechanism for runtime
+For a Git provider and a runtime account, select the authentication mechanism: Codefresh account, Custom provider account if one exists, or token-based authentication.
+
+>Hosted GitOps runtimes support either Codefresh or token-based authentication.
+
+1. In the Codefresh UI, go to [Authentication](https://g.codefresh.io/2.0/account-settings/authentication?providerName=github){:target="\_blank"}.
+1. Select the runtime, and click **Edit**.
+1. Select the OAuth authentication provider account.
+
+
+## Related articles
+[Adding users and teams]({{site.baseurl}}/docs/administration/account-user-management/add-users/)
+[Configuring access control]({{site.baseurl}}/docs/administration/account-user-management/access-control/)
+[Codefresh IP addresses]({{site.baseurl}}/docs/administration/account-user-management/platform-ip-addresses/)
+
\ No newline at end of file
diff --git a/_docs/administration/account-user-management/pipeline-execution-context.md b/_docs/administration/account-user-management/pipeline-execution-context.md
new file mode 100644
index 000000000..39903c365
--- /dev/null
+++ b/_docs/administration/account-user-management/pipeline-execution-context.md
@@ -0,0 +1,49 @@
+---
+title: "Pipeline execution context"
+description: "A managed entity to make API calls on your behalf during pipeline execution"
+group: administration
+redirect_from:
+ - /docs/administration/pipeline-execution-context/
+toc: true
+---
+
+## Prerequisites
+
+**Account Level:** Pro and above
+
+> At this time, you will need to reach out to support to enable pipeline execution context.
+
+## About Pipeline Execution Context
+
+A pipeline execution context is an entity attached to the pipeline that makes API calls on your behalf. To create an execution context, navigate to Account Settings then Execution Context under the Security section. The execution context does not have permission at first. To control what this execution context can access, you will need to define ABAC rules. You can create multiple execution contexts in the account, but only one can be set as the default. The default execution context is there for a pipeline that does not have a specific execution context associated with it. As with all other integration contexts, you will not be able to delete an execution context if linked to a pipeline.
+
+## Permissions
+
+When a new execution context is created, it has no permissions at first. An account admin must add ABAC rules to grant permissions to that execution context. The enforcement of the execution context permissions will be based on the existing [ABAC model]({{site.baseurl}}/docs/administration/account-user-management/access-control/) that we have today on our platform. The available permissions for execution context will be the same as we have today for codefresh teams. There will be a new tab on the Permissions page for assigning ABAC rules to the execution context.
+
+In addition, there will be a new action for team rules: assigning execution context to pipelines. Account admins will be able to control which teams will be able to set execution contexts to certain pipelines by creating a rule like: “Dev team can assign execution context with tags ‘dev-context’ to pipelines that have ‘dev’ tags.”
+
+## Restrictions
+
+Pipeline execution contexts are restricted to the [pipelines](https://codefresh-io.github.io/cli/pipelines/){:target="\_blank"} and "[builds](https://codefresh-io.github.io/cli/builds/){:target="\_blank"} endpoints of the CLI. Also, there are some additional resources related to pipeline resources in the [Operate On Resources](https://codefresh-io.github.io/cli/operate-on-resources/){:target="\_blank"} section. Any other endpoints will be blocked when using the execution context. With that being said, some of Codefresh’s Steps in the Steps Marketplace will not work when using execution contexts. Some known steps to not work are argocd-rollout, argocd-sync, and launch-composition, as they use additional endpoints behind the scenes.
+
+A user can override the environment variable CF_API_KEY with their API Key to access other endpoints. Below is an example of how to do this in a single step.
+
+{% highlight yaml %}
+{% raw %}
+steps:
+ this _step_will_ succeed:
+ title: "will succeed"
+ type: "freestyle" # Run any command
+ image: "quay.io/codefresh/cli"
+ commands:
+ - "export CF_API_KEY=${{MY_API_KEY}}" # this will override the default token with my own token
+ - "codefresh create team ${{TEAM_NAME}}"
+{% endraw %}
+{% endhighlight %}
+
+You can use cf_export instead of export to make CF_API_KEY available for the following steps if needed.
+
+## Related articles
+[API Key Creation]({{site.baseurl}}/docs/administration/user-self-management/user-settings/#api-key-creation)
+
diff --git a/_docs/administration/audit-logs.md b/_docs/administration/audit-logs.md
deleted file mode 100644
index 7a8fbea51..000000000
--- a/_docs/administration/audit-logs.md
+++ /dev/null
@@ -1,109 +0,0 @@
----
-title: "Audit Logs"
-description: "Get a list of all actions in Codefresh"
-group: administration
-redirect_from:
- - /docs/enterprise/audit-logs/
-toc: true
----
-
-Codefresh keeps a log of all actions that happen at all times. The log is actually based on API calls that reach Codefresh, so it includes
-
-* GUI actions from users
-* [CLI](https://codefresh-io.github.io/cli/) invocations
-* Any [external integrations]({{site.baseurl}}/docs/integrations/codefresh-api/) you are using with Codefresh
-
-The time period offered by audit logs depends on the pricing tier of your Codefresh account.
-
-
-## Viewing Audit logs
-
-To access the Audit logs click on *Account settings* on the left sidebar and then select *Audit* under *User Management*
-
-
-{% include image.html
-lightbox="true"
-file="/images/administration/audit/audit-logs.png"
-url="/images/administration/audit/audit-logs.png"
-alt="Audit Logs view"
-caption="Audit Logs view"
-max-width="70%"
-%}
-
-This screen contains a reverse chronological list of all Codefresh events that happened on your account. For each event, the following are recorded:
-
-* `Entity ID/Name` - which entity was affected.
-* `Entity type` - types of entities are build, pipeline, project, etc.
-* `Action` - what happened to that entity.
-* `Status` - what use the result of the API call.
-* `User` - name of user that performed the action.
-* `Last` Request - time of the event.
-
-
-
-There is also a separate tab for all the triggers/webhooks that were processed by Codefresh.
-
-{% include image.html
-lightbox="true"
-file="/images/administration/audit/audit-triggers.png"
-url="/images/administration/audit/audit-triggers.png"
-alt="Audit Triggers view"
-caption="Audit Triggers view"
-max-width="70%"
-%}
-
-
-
-Both lists have built-in paging and filtering.
-
-
-### Filtering Audit events
-
-You can filter the list of events by using the filter menu on the top left.
-
-{% include image.html
-lightbox="true"
-file="/images/administration/audit/audit-filter.png"
-url="/images/administration/audit/audit-filter.png"
-alt="Filtering audit actions"
-caption="Filtering audit actions"
-max-width="40%"
-%}
-
-This allows you to focus on a specific entity or user.
-
-
-
-
-
-### Getting more details for each audit event
-
-You can get the exact API payload as it was sent to Codefresh by clicking on the *book icon* on the right of each event row.
-
-
-{% include image.html
-lightbox="true"
-file="/images/administration/audit/api-call-details.png"
-url="/images/administration/audit/api-call-details.png"
-alt="Audit Call details"
-caption="Audit Call details"
-max-width="40%"
-%}
-
-
-This dialog provides you with the URL and other call parameters that were used for that particular event.
-
-
-## Exporting the audit logs
-
-It is also possible to export all log events, by clicking on the *Download Audit* button on the top right. This will download a `CSV` file that you can further process with your own tools or view in a different application (such as Microsoft Excel).
-
-The Audit Log export also includes all the API call information (payload and parameters) that are shown in the Audit GUI screen.
-
-
-
-## What to read next
-
-* [Codefresh installation options]({{site.baseurl}}/docs/administration/installation-security/)
-* [Access Control]({{site.baseurl}}/docs/administration/access-control/)
-* [Codefresh API]({{site.baseurl}}/docs/integrations/codefresh-api/)
\ No newline at end of file
diff --git a/_docs/administration/behind-the-firewall.md b/_docs/administration/behind-the-firewall.md
deleted file mode 100644
index af5a318b5..000000000
--- a/_docs/administration/behind-the-firewall.md
+++ /dev/null
@@ -1,248 +0,0 @@
----
-title: "Codefresh Behind the Firewall"
-description: "How to run Codefresh Pipelines in your own secure Infrastructure"
-group: administration
-redirect_from:
- - /docs/enterprise/behind-the-firewall/
-toc: true
-
----
-
-As explained in the [installation page]({{site.baseurl}}/docs/administration/installation-security/) Codefresh offers three installation options; pure cloud, on-premise and Hybrid.
-In this document, we will describe the Hybrid option and all the advantages it offers.
-
-## Running Codefresh in secure environments
-
-Codefresh has an on-premise installation where the whole platform is installed on the customer premises. While
-this solution is very effective as far as security is concerned, it places a lot of overhead on the customer, as all updates
-and improvements done in the platform must also be transferred to the customer premises.
-
-This Hybrid approach places a Codefresh runner within customer premises while the UI (and management platform) stays in the Codefresh SaaS.
-
-Here is the overall architecture:
-
-{% include image.html
- lightbox="true"
- file="/images/administration/behind-the-firewall/architecture.png"
- url="/images/administration/behind-the-firewall/architecture.png"
- alt="Codefresh behind the firewall"
- caption="Codefresh behind the firewall"
- max-width="100%"
- %}
-
-The advantages for this scenario are multi-fold. Regarding platform maintenance:
-
- 1. The heavy lifting for platform maintenance is still happening by Codefresh instead of the customer.
- 1. Updates to the UI, build engine, integrations etc., are happening automatically without any customer involvement.
- 1. Actual builds are happening in the customer premises under fully controlled conditions.
- 1. The Codefresh runner is fully automated. It handles volume claims and build scheduling on its own within the Kubernetes cluster it is placed.
-
-Regarding security of services:
-
- 1. Pipelines can run in behind-the-firewall clusters with internal services.
- 1. Pipelines can use integrations (such as Docker registries) that are private and secure.
- 1. Source code does not ever leave the customer premises.
-
-Regarding firewall security:
-
- 1. Communication between the Codefresh runner and Codefresh SaaS is uni-directional. The runner is polling the Codefresh platform for jobs.
- 1. Communication between the Codefresh runner and Codefresh SaaS is only outgoing. The Codefresh SaaS never connects to the customer network. No ports need to be open in the customer firewall for the runner to work.
- 1. The Codefresh runner is fully open-sourced, so its code can by scrutinized by any stakeholder.
-
-
-
-## Using Secure services in your pipelines
-
-First make sure that you have installed the [Codefresh runner]({{site.baseurl}}/docs/administration/codefresh-runner/) on your own infrastructure (i.e., your private Kubernetes cluster).
-
-All pipelines that are executed in the private Kubernetes cluster have access to all other internal services that are network reachable. It is therefore very easy to create pipelines that:
-
- * Use databases internal to the company
- * Run integration tests against services internal to the company
- * Launch [compositions]({{site.baseurl}}/docs/codefresh-yaml/steps/composition/) that communicate with other secure services
- * Upload and download artifacts from a private artifact repository (e.g., Nexus or Artifactory)
- * Deploy to any other cluster accessible in the secure network
- * Create infrastructure such as machines, load balancers, auto-scaling groups etc.
-
- Any of these pipelines will work out the box and no extra configuration is needed. In all cases,
- all data will stay with the private local network and will never exit the firewall.
-
- >Notice that [long running compositions]({{site.baseurl}}/docs/codefresh-yaml/steps/composition/) (preview test environments) are not yet available via the Codefresh
- build runner.
-
-
-
-### Checking out code from a private GIT repository
-
-To check-out code from your private GIT repository, you need to connect first to Codefresh via the [GIT integrations]({{site.baseurl}}/docs/integrations/git-providers/). However, once you define your GIT provider as *on premise* you also
-need to mark it as *behind the firewall* as well:
-
-{% include image.html
- lightbox="true"
- file="/images/administration/behind-the-firewall/behind-the-firewall-toggle.png"
- url="/images/administration/behind-the-firewall/behind-the-firewall-toggle.png"
- alt="Behind the firewall toggle"
- caption="Behind the firewall toggle"
- max-width="100%"
- %}
-
-Once you do that save your provider and make sure that it has the correct tags. The name you used for the git provider will also be used in the pipeline. You cannot "test the connection" because
-the Codefresh SAAS doesn't have access to your on-premises GIT repository.
-
-{% include image.html
- lightbox="true"
- file="/images/administration/behind-the-firewall/behind-the-firewall-tag.png"
- url="/images/administration/behind-the-firewall/behind-the-firewall-tag.png"
- alt="Behind the firewall tags"
- caption="Behind the firewall tags"
- max-width="100%"
- %}
-
-To check out code just use a [clone step]({{site.baseurl}}/docs/codefresh-yaml/steps/git-clone/) like any other clone operation.
-The only thing to remember is that the GIT URL must be fully qualified. You need to [create a pipeline]({{site.baseurl}}/docs/configure-ci-cd-pipeline/pipelines/#pipeline-creation-modes) on it its own from the *Pipelines* section of the left sidebar (instead of one adding a git repository to Codefresh)
-
-
-
-`YAML`
-{% highlight yaml %}
-{% raw %}
-version: '1.0'
-steps:
- main_clone:
- type: git-clone
- description: Step description
- repo: https://github-internal.example.com/my-username/my-app
- git: my-internal-git-provider
- BuildingDockerImage:
- title: Building Docker Image
- type: build
- image_name: my-image
- tag: '${{CF_BRANCH_TAG_NORMALIZED}}-${{CF_SHORT_REVISION}}'
- dockerfile: Dockerfile
-{% endraw %}
-{% endhighlight %}
-
-Once you trigger the pipeline, the Codefresh builder will communicate with your private GIT instance and checkout code.
-
->Note that currently there is a limitation in regards to the location of the `codefresh.yml` file. Only the [inline mode]({{site.baseurl}}/docs/configure-ci-cd-pipeline/pipelines/#writing-codefresh-yml-in-the-gui) is supported. Soon we will allow the loading of the pipeline from the git repository itself.
-
-You can also use a [network proxy]({{site.baseurl}}/docs/codefresh-yaml/steps/git-clone/#using-git-behind-a-proxy) for the Git clone step.
-
-#### Adding triggers from private GIT repositories
-
-
-In the previous section we have seen how a pipeline can check out code from the internal git repository. We also need to setup a trigger
-so that every time a commit happens (or any other supported event), the Codefresh pipeline will be triggered automatically.
-
-If you have installed the [optional app-proxy]({{site.baseurl}}/docs/administration/codefresh-runner/#optional-installation-of-the-app-proxy), adding a trigger can be done exactly like the SAAS version of Codefresh, using only the Codefresh UI.
-
-If you haven't installed the app-proxy, then adding a Git trigger is a two-step process:
-
-1. First we setup a webhook endpoint in Codefresh.
-1. Then we create the webhook call in the side of the the GIT provider.
-
-> To support triggers based on PR (Pull Request) events, it is mandatory to install `app-proxy`.
-
-For the Codefresh side, follow the usual instructions for creating a [basic git trigger]({{site.baseurl}}/docs/configure-ci-cd-pipeline/triggers/git-triggers/).
-
-Once you select your GIT provider, you need to manually enter your username and repository that you wish to trigger the build.
-
-{% include image.html
- lightbox="true"
- file="/images/administration/behind-the-firewall/enter-repo-details.png"
- url="/images/administration/behind-the-firewall/enter-repo-details.png"
- alt="Entering repository details"
- caption="Entering repository details"
- max-width="60%"
- %}
-
-All other details (git events, branch naming, monorepo pattern, etc.) are still the same as normal SAAS GIT providers.
-Once that is done, Codefresh will show you the webhook endpoint along with a secret for triggering this pipeline. Note them down.
-
-
-{% include image.html
- lightbox="true"
- file="/images/administration/behind-the-firewall/codefresh-webhook.png"
- url="/images/administration/behind-the-firewall/codefresh-webhook.png"
- alt="Codefresh webhook details"
- caption="Codefresh webhook details"
- max-width="60%"
- %}
-
-This concludes the setup on the Codefresh side. The final step is create a webhook call on the side of your GIT provider.
-The instructions are different per GIT provider:
-
-* [GitHub webhooks](https://developer.github.com/webhooks/)
-* [GitLab webhooks](https://docs.gitlab.com/ee/user/project/integrations/webhooks.html)
-* [Stash webhooks](https://confluence.atlassian.com/bitbucketserver/managing-webhooks-in-bitbucket-server-938025878.html)
-
-In all cases make sure that the payload is JSON, because this is what Codefresh expects.
-
-* For GitHub the events monitored should be `Pull requests` and `Pushes`.
-* For GitLab the events monitored should be `Push events`,`Tag push events` and `Merge request events`.
-
-After the setup is finished, the Codefresh pipeline will be executed every time a git event happens.
-
-### Accessing an internal docker registry
-
-To access an internal registry just follow the instructions for [adding registries]({{site.baseurl}}/docs/docker-registries/external-docker-registries/) . Like GIT repositories
-you need to mark the Docker registry as *Behind the firewall*.
-
-Once that is done, use the [push step]({{site.baseurl}}/docs/codefresh-yaml/steps/push/) as usual with the name you gave to the registry during the integration setup.
-
-
-`YAML`
-{% highlight yaml %}
-{% raw %}
-version: '1.0'
-steps:
- gitClone:
- type: git-clone
- description: Step description
- repo: https://github-internal.example.com/my-username/my-app
- git: my-internal-git-repo
- BuildingDockerImage:
- title: Building Docker Image
- type: build
- image_name: my-image
- dockerfile: Dockerfile
- PushingDockerImage:
- title: Pushing a docker image
- type: push
- candidate: '${{BuildingDockerImage}}'
- tag: '${{CF_BRANCH}}'
- registry: my-internal-docker-registry
-{% endraw %}
-{% endhighlight %}
-
-
-### Deploying to an internal Kubernetes cluster
-
-To connect a cluster that is behind the firewall follow the [connecting cluster guide]({{site.baseurl}}/docs/deploy-to-kubernetes/add-kubernetes-cluster/), paying attention to the following two points:
-
-1. Your cluster should be added as a [Custom provider]({{site.baseurl}}/docs/deploy-to-kubernetes/add-kubernetes-cluster/#adding-any-other-cluster-type-not-dependent-on-any-provider)
-1. You need to mark the cluster as internal by using the toggle switch.
-
-
-
-
-{% include image.html
- lightbox="true"
- file="/images/administration/behind-the-firewall/cluster-behind-firewall.png"
- url="/images/administration/behind-the-firewall/cluster-behind-firewall.png"
- alt="Marking a Kubernetes cluster as internal"
- caption="Marking a Kubernetes cluster as internal"
- max-width="60%"
- %}
-
-The cluster where the runner works on should have network connectivity with the cluster you wish to deploy to.
-
->Notice that the service account used in the cluster configuration is completely independent from the privileges granted to the Codefresh build runner. The privileges needed by the runner are only used to launch Codefresh pipelines within your cluster. The Service account used in the "custom provider" setting should have the needed privileges for deployment.
-
-Once your cluster is connected you can use any of the familiar deployment methods such as the [dedicated deploy step]({{site.baseurl}}/docs/deploy-to-kubernetes/deployment-options-to-kubernetes/) or [custom kubectl commands]({{site.baseurl}}/docs/deploy-to-kubernetes/custom-kubectl-commands/).
-
-## What to read next
-
-* [Codefresh installation options]({{site.baseurl}}/docs/administration/installation-security/)
-* [Google marketplace integration]({{site.baseurl}}/docs/integrations/google-marketplace/)
-* [Managing your Kubernetes cluster]({{site.baseurl}}/docs/deploy-to-kubernetes/manage-kubernetes/)
diff --git a/_docs/administration/cf-ip4.txt b/_docs/administration/cf-ip4.txt
index 6052c630e..23992eb79 100644
--- a/_docs/administration/cf-ip4.txt
+++ b/_docs/administration/cf-ip4.txt
@@ -24,4 +24,4 @@
3.228.62.77/32
44.205.132.73/32
34.235.30.144/32
-54.160.88.80/32
\ No newline at end of file
+54.160.88.80/32
diff --git a/_docs/administration/codefresh-hybrid.md b/_docs/administration/codefresh-hybrid.md
deleted file mode 100644
index efc17a910..000000000
--- a/_docs/administration/codefresh-hybrid.md
+++ /dev/null
@@ -1,56 +0,0 @@
----
-title: "Codefresh Hybrid Installation (Legacy)"
-description: "Add your own Node to run/build containers"
-group: administration
-redirect_from:
- - /docs/add-your-node-to-runbuild-containers/
- - /docs/enterprise/codefresh-hybrid/
-toc: true
-old_url: /docs/add-your-node-to-runbuild-containers
----
-
->Note that this page is now describing the legacy hybrid mode. For the new version read more at [behind-the-firewall]({{site.baseurl}}/docs/administration/behind-the-firewall/).
-
-Codefresh lets you use your own host as a node to run/build containers.
-
-{:start="1"}
-1. Go to your account configurations by clicking on *Account Settings* on the left sidebar.
-
-{:start="2"}
-2. Select *Nodes* from the left sidebar.
-
-> Hybrid nodes are only available to enterprise customers. [Contact us](https://codefresh.io/contact-us/) us to enable this feature.
-
-{% include image.html
- lightbox="true"
- file="/images/administration/hybrid-node/add-hybrid-node.png"
- url="/images/administration/hybrid-node/add-hybrid-node.png"
- alt="Adding a hybrid build node"
- caption="Adding a hybrid build node"
- max-width="60%"
- %}
-
-{:start="3"}
-3. Click on *ADD YOUR NODE*
-Codefresh lets you use your own host as a build agent to run/build containers. In order to do this, you have to first install the Codefresh Agent on your machine.
-
-The following Linux distributions are supported:
-
-- Ubuntu 14.04, 15.04, 16.04
-- Debian 8
-- Centos 7+
-- RedHat Linux 7
-- Fedora 21, 22
-
-In order for Codefresh to communicate with the Docker daemon running on your node, port `tcp:2376` should be open on your node's firewall.
-
-{% include image.html
-lightbox="true"
-file="/images/ad2e504-917195e-codefresh_add_private_node.png"
-url="/images/ad2e504-917195e-codefresh_add_private_node.png"
-alt="917195e-codefresh_add_private_node.png"
-max-width="80%"
-%}
-
-**Note:** You need to provide the public IP address of the node.
-
diff --git a/_docs/administration/installation-security.md b/_docs/administration/installation-security.md
deleted file mode 100644
index 321174c58..000000000
--- a/_docs/administration/installation-security.md
+++ /dev/null
@@ -1,195 +0,0 @@
----
-title: "Codefresh Installation Options"
-description: "How to run Codefresh in the Enterprise"
-group: administration
-redirect_from:
- - /docs/enterprise/nodes/set-node-limits/
- - /docs/enterprise/installation-security/
-toc: true
----
-
-Codefresh offers 3 installation options that can cater to any size of organization:
-
-* Full cloud version that runs 100% in the cloud and is fully managed by Codefresh.
-* On-premises version where Codefresh runs inside the customer datacenter/cloud.
-* Hybrid version where the UI runs in the Codefresh cloud, but builds are running on customer premises.
-
-On-premises and Hybrid versions are available to Enterprise customers that are looking for a "behind-the-firewall" solution.
-
-
-
-## Cloud version
-
-The Cloud version is the easiest way to start using Codefresh as it is fully managed and runs 100% on the cloud. All maintenance and updates
-are executed by the Codefresh DevOps team.
-
-You can also create a [free account]({{site.baseurl}}/docs/getting-started/create-a-codefresh-account/) on the SAAS version right away. The account is forever free with some limitations
-on number of builds.
-
-The cloud version runs on multiple clouds:
-
-{% include image.html
- lightbox="true"
- file="/images/administration/installation/codefresh-saas.png"
- url="/images/administration/installation/codefresh-saas.png"
- alt="sso-diagram.png"
- max-width="60%"
- %}
-
-Codefresh Cloud is also compliant with [SOC2 - Type2](https://www.aicpa.org/SOC) showing our commitment to security and availability.
-
-{% include image.html
- lightbox="true"
- file="/images/administration/installation/soc2-type2-certified.png"
- url="/images/administration/installation/soc2-type2-certified.png"
- alt="sso-diagram.png"
- max-width="40%"
- %}
-
-The Cloud version has multi-account support with most git providers (GitLab, GitHub, Bitbucket) as well as Azure and Google.
-
-
-## Hybrid installation
-
-For organizations that don't want their source code to leave their premises, or have other security constraints, Codefresh offers the [hybrid installation]({{site.baseurl}}/docs/administration/behind-the-firewall/).
-
-The User Interface still runs on Codefresh infrastructure, while the actual builds happen in the location of the customer (Codefresh builders run on a Kubernetes cluster).
-
-{% include image.html
- lightbox="true"
- file="/images/administration/installation/hybrid-installation.png"
- url="/images/administration/installation/hybrid-installation.png"
- alt="sso-diagram.png"
- max-width="70%"
- %}
-
-
-The hybrid installation strikes the perfect balance between security, flexibility and ease of use. Codefresh still does the heavy lifting for maintaining most of the platform parts. The sensitive data (such as source code and internal services) never leave the premises of the customers.
-
-With the hybrid installation mode, Codefresh can easily connect to internal [secure services]({{site.baseurl}}/docs/enterprise/behind-the-firewall/#using-secure-services-in-your-pipelines) that have no public presence.
-The UI part is still compliant with Soc2.
-
-{% include image.html
- lightbox="true"
- file="/images/administration/installation/soc2-type2-certified.png"
- url="/images/administration/installation/soc2-type2-certified.png"
- alt="sso-diagram.png"
- max-width="40%"
- %}
-
-Here are the security implications of the hybrid solution:
-
-{: .table .table-bordered .table-hover}
-| Company Asset | Flow/Storage of data | Comments |
-| -------------- | ---------------------------- |-------------------------|
-| Source code | Stays behind the firewall | |
-| Binary artifacts | Stay behind the firewall | |
-| Build logs | Also sent to Codefresh Web application | |
-| Pipeline volumes | Stay behind the firewall | |
-| Pipeline variables | Defined in Codefresh Web application | |
-| Deployment docker images | Stay behind the firewall| Stored on your Docker registry |
-| Development docker images | Stay behind the firewall | Stored on your Docker registry|
-| Testing docker images | Stay behind the firewall| Stored on your Docker registry |
-| Inline pipeline definition | Defined in Codefresh Web application | |
-| Pipelines as YAML file | Stay behind the firewall | |
-| Test results | Stay behind the firewall | |
-| HTML Test reports | Shown on Web application | Stored in your S3 or Google bucket or Azure storage |
-| Production database data | Stays behind the firewall | |
-| Test database data | Stays behind the firewall | |
-| Other services (e.g. Queue, ESB) | Stay behind the firewall | |
-| Kubernetes deployment specs | Stay behind the firewall | |
-| Helm charts | Stay behind the firewall | |
-| Other deployment resources/script (e.g. terraform) | Stay behind the firewall | |
-| Shared configuration variables | Defined in Codefresh Web application | |
-| Deployment secrets (from git/Puppet/Vault etc) | Stay behind the firewall| |
-| Audit logs | Managed via Codefresh Web application | |
-| SSO/Idp Configuration | Managed via Codefresh Web application | |
-| User emails | Managed via Codefresh Web application | |
-| Access control rules | Managed via Codefresh Web application | |
-
-
-
-## On-premises Installation
-
-For customers that wish to have full control over everything, Codefresh also offers an on-premises option. In this case everything (UI and builds) are running on an environment (Kubernetes cluster) fully managed by the customer.
-
-While Codefresh can still help with maintenance of the on-premises platform, we would recommend trying the Hybrid solution first as it offers the most flexibility while maintaining high security.
-
-## Comparison table
-
-{: .table .table-bordered .table-hover}
-| Characteristic | Cloud | Hybrid | On Premise |
-| -------------- | ---------------------------- |-------------------------|
-| Managed by | Codefresh | Codefresh and Customer | Customer |
-| UI runs on | public cloud | public cloud | private cluster |
-| Builds run on | public cloud | private cluster | private cluster |
-| Access to secure/private services | no | yes | yes |
-| Customer maintenance effort | none | some | full |
-| Best for | most companies | companies with security constraints | Large scale installations |
-| Available to | all customers | [enterprise plans](https://codefresh.io/contact-us/) | [enterprise plans](https://codefresh.io/contact-us/) |
-
-## High level Architecture
-
-The most important components are the following:
-
-**The Codefresh VPC:** This is where all internal Codefresh services are running (analyzed in the next section). Codefresh is using internally Mongo and PostgreSQL for storing information such as users and authentication.
-
-**The Pipeline execution environment**. This is where all pipelines run. The Codefresh engine component is responsible for taking pipeline definitions and running them in managed Kubernetes clusters by automatically launching the Docker containers that each pipeline needs for its steps.
-
-**External actors**. Codefresh is offering a [public API]({{site.baseurl}}/docs/integrations/codefresh-api/) that is consumed both by the Web User interface as well as the [Codefresh CLI](https://codefresh-io.github.io/cli/). The API is also available for any custom integration with external tools or services.
-
-## Topology diagram
-
-If we zoom into the Codefresh Services platform we will see the following:
-
-{% include image.html
- lightbox="true"
- file="/images/administration/installation/topology-new.png"
- url="/images/administration/installation/topology-new.png"
- alt="Topology diagram"
- caption="Topology diagram (click to enlarge)"
- max-width="100%"
- %}
-
-### Core Components
-
-**pipeline-manager** manages all CRUD operations regarding pipelines
-
-**cfsign** signs server tls certificates for docker daemons and generates client tls certificates for hybrid pipelines
-
-**cf-api** is the central backend component. It functions as an API gateway for other services and is also responsible for authentication/authorization.
-
-**context-manager** manages all possible authentication/configuration that are used by Codefresh system and by Codefresh engine
-
-**runtime-environment-manager** is responsible for managing the different environments where pipelines can run. The Codefresh SAAS installation has runtime environment that are fully managed by the Codefresh team. In hybrid installations, customers can add their own runtime environments using private Kubernetes clusters
-
-### Trigger Components
-
-**hermes** controls [trigger management]({{site.baseurl}}/docs/configure-ci-cd-pipeline/triggers/) in Codefresh
-
-**nomios** enables [triggers from Dockerhub]({{site.baseurl}}/docs/configure-ci-cd-pipeline/triggers/dockerhub-triggers/) (when a new image/tag is pushed)
-
-**cronus** enables defining [cron like triggers]({{site.baseurl}}/docs/configure-ci-cd-pipeline/triggers/cron-triggers/) for pipelines
-
-### Log Component
-
-**cf-broadcaster** stores build logs from pipelines (the replacement for Firebase in the previous installer). The only component that the UI and CLI have access to through a web socket in order to stream logs.
-
-### Kubernetes Components
-
-**cluster-providers** provides an interface to define clusters contexts for connecting Kubernetes clusters in Codefresh
-
-**helm-repo-manager** is responsible for the Helm repository admin API and ChartMuseum proxy for managing [Helm charts it Codefresh]({{site.baseurl}}/docs/new-helm/managed-helm-repository/)
-
-**k8s-monitor** is an agent that gets installed on each Kubernetes cluster to provide information for the [Kubernetes dashboards]({{site.baseurl}}/docs/deploy-to-kubernetes/manage-kubernetes/)
-
-**charts-manager** models the [Helm chart view]({{site.baseurl}}/docs/new-helm/helm-releases-management/) in Codefresh.
-
-**kube-integration** provides an interface to retrieve all required information from a Kubernetes cluster, can be run either as a http server, or npm module
-
-**tasker-kubernetes** provides cache storage for [Kubernetes dashboards]({{site.baseurl}}/docs/deploy-to-kubernetes/manage-kubernetes/) in Codefresh
-
-## What to read next
-
-* [Codefresh Pricing](https://codefresh.io/pricing/)
-* [Codefresh features](https://codefresh.io/features/)
diff --git a/_docs/administration/invite-your-team-member.md b/_docs/administration/invite-your-team-member.md
deleted file mode 100644
index 79eca907b..000000000
--- a/_docs/administration/invite-your-team-member.md
+++ /dev/null
@@ -1,55 +0,0 @@
----
-title: "Invite your team members"
-description: "Add other Codefresh users to your account"
-group: administration
-redirect_from:
- - /docs/accounts/
- - /docs/accounts/invite-your-team-member/
-toc: true
----
-
-You can easily add additional people to a Codefresh account to work with your repositories or pipelines. You also define the level of access they have in the account resources.
-
-## Managing users in a Codefresh account
-
-On the left sidebar of the Codefresh UI choose *Account Settings* and then click on the *User & Teams* menu item under *User Management*
-
-
-{% include
- image.html
- lightbox="true"
- file="/images/administration/users/invite-users.png"
- url="/images/administration/users/invite-users.png"
- alt="Invite users"
- caption="Invite users"
- max-width="100%"
-%}
-
-
-1. In the *Username* text box, type the Codefresh username or email address of the user you want to add.
-1. Click the *Add* button.
-
-
-An email will be sent to the person that holds the email account. Once this invitation is sent, they will show as Pending until the invite is successfully accepted and the user is created
-
-
-## Setting a role for each collaborator
-
-You can also change the [role]({{site.baseurl}}/docs/administration/access-control/#users-and-administrators) of each team member by using the drop-down next to their name:
-
-* People with the **User** role will be able to work with your repositories and pipelines, but will not be able to change settings
-on clusters, docker registries, git integrations, shared configurations etc.
-* People with the **Administrator** role have full access to your account and can change all your settings, so make sure that they are trusted colleagues.
-
-You can completely remove a user from your account by clicking on the *bin* icon on the far right.
-
-## Common issues
-
-* [User is prompted to enter an organization name](https://support.codefresh.io/hc/en-us/articles/360020177959-User-is-prompted-to-enter-an-organization-name)
-* [Account invitation not permitting login](https://support.codefresh.io/hc/en-us/articles/360015251000-Account-invitation-not-permitting-login)
-
-## What to read next
-
-* [Access control]({{site.baseurl}}/docs/administration/access-control/)
-* [Single Sign on]({{site.baseurl}}/docs/administration/single-sign-on/)
-
diff --git a/_docs/administration/pipeline-execution-context.md b/_docs/administration/pipeline-execution-context.md
deleted file mode 100644
index a7004f6a2..000000000
--- a/_docs/administration/pipeline-execution-context.md
+++ /dev/null
@@ -1,48 +0,0 @@
----
-title: "Pipeline Execution Context"
-description: "A managed entity to make API calls on your behalf during pipeline execution"
-group: administration
-toc: true
----
-
-## Prerequisites
-
-**Account Level:** Pro and above
-
-> At this time, you will need to reach out to support to enable pipeline execution context.
-
-## About Pipeline Execution Context
-
-A pipeline execution context is an entity attached to the pipeline that makes API calls on your behalf. To create an execution context, navigate to Account Settings then Execution Context under the Security section. The execution context does not have permission at first. To control what this execution context can access, you will need to define ABAC rules. You can create multiple execution contexts in the account, but only one can be set as the default. The default execution context is there for a pipeline that does not have a specific execution context associated with it. As with all other integration contexts, you will not be able to delete an execution context if linked to a pipeline.
-
-## Permissions
-
-When a new execution context is created, it has no permissions at first. An account admin must add ABAC rules to grant permissions to that execution context. The enforcement of the execution context permissions will be based on the existing [ABAC model](https://codefresh.io/docs/docs/administration/access-control/) that we have today on our platform. The available permissions for execution context will be the same as we have today for codefresh teams. There will be a new tab on the Permissions page for assigning ABAC rules to the execution context.
-
-In addition, there will be a new action for team rules: assigning execution context to pipelines. Account admins will be able to control which teams will be able to set execution contexts to certain pipelines by creating a rule like: “Dev team can assign execution context with tags ‘dev-context’ to pipelines that have ‘dev’ tags.”
-
-## Restrictions
-
-Pipeline execution contexts are restricted to the "[pipelines](https://codefresh-io.github.io/cli/pipelines/)" and "[builds](https://codefresh-io.github.io/cli/builds/)" endpoints of the CLI. Also, there are some additional resources related to pipeline resources in the "[Operate On Resources](https://codefresh-io.github.io/cli/operate-on-resources/)" section. Any other endpoints will be blocked when using the execution context. With that being said, some of Codefresh’s Steps in the Steps Marketplace will not work when using execution contexts. Some known steps to not work are argocd-rollout, argocd-sync, and launch-composition, as they use additional endpoints behind the scenes.
-
-A user can override the environment variable CF_API_KEY with their API Key to access other endpoints. Below is an example of how to do this in a single step.
-
-{% highlight yaml %}
-{% raw %}
-steps:
- this _step_will_ succeed:
- title: "will succeed"
- type: "freestyle" # Run any command
- image: "quay.io/codefresh/cli"
- commands:
- - "export CF_API_KEY=${{MY_API_KEY}}" # this will override the default token with my own token
- - "codefresh create team ${{TEAM_NAME}}"
-{% endraw %}
-{% endhighlight %}
-
-You can use cf_export instead of export to make CF_API_KEY available for the following steps if needed.
-
-## What to read next
-
-* [Access Control]({{site.baseurl}}/docs/administration/access-control/)
-* [API Key Creation]({{site.baseurl}}/docs/administration/user-settings/#api-key-creation)
diff --git a/_docs/administration/pipeline-settings.md b/_docs/administration/pipeline-settings.md
deleted file mode 100644
index b98b27dd2..000000000
--- a/_docs/administration/pipeline-settings.md
+++ /dev/null
@@ -1,110 +0,0 @@
----
-title: "Pipeline Settings"
-description: "Define global options for pipeline templates, yaml sources and approval behavior"
-group: administration
-toc: true
----
-
-To access your global pipeline settings navigate to [https://g.codefresh.io/account-admin/account-conf/pipeline-settings](https://g.codefresh.io/account-admin/account-conf/pipeline-settings) or click on *Account settings* on the left sidebar and then choose *Pipeline settings* item on the next screen.
-
-On this page, you can define global parameters for the whole Codefresh account regarding pipeline options. Users can still override some of these options for individual pipelines.
-
-{% include image.html
-lightbox="true"
-file="/images/administration/pipeline-settings/pipeline-settings-ui.png"
-url="/images/administration/pipeline-settings/pipeline-settings-ui.png"
-alt="Pipeline settings"
-caption="Pipeline settings"
-max-width="80%"
-%}
-
-
-## Pause pipeline executions
-
-Pause builds for pipelines at the account level, for example, during maintenance.
-
-* **Pause build execution** is disabled by default.
-* When enabled:
- * New pipelines in the account are paused immediately.
- * Existing pipelines with running builds are paused only after the builds have completed execution.
-* Paused pipelines are set to status Pending, and remain in this status until **Pause build execution** is manually disabled for the account.
-
-{% include image.html
-lightbox="true"
-file="/images/administration/pipeline-settings/pause-pipeline-enabled.png"
-url="/images/administration/pipeline-settings/pause-pipeline-enabled.png"
-alt="Pause Build Execution pipeline setting enabled"
-caption="Pause Build Execution pipeline setting enabled"
-max-width="80%"
-%}
-
-## Template Section
-
-Here you can define global template behavior. The options are:
-
-* Enable [pipeline templates]({{site.baseurl}}/docs/configure-ci-cd-pipeline/pipelines/#using-pipeline-templates) for users. If this is enabled some pipelines can be marked as templates and users can still select them when creating a new pipeline.
-* Decide if users can clone an existing pipeline (along with its triggers and associated parameters) when [creating a new pipeline]({{site.baseurl}}/docs/configure-ci-cd-pipeline/pipelines/#creating-new-pipelines).
-
-Note that templates are simply normal pipelines “marked” as a template. There is no technical difference between templates and actual pipelines.
-
-## Enabling cluster-contexts for pipelines
-By default, all pipelines in the account can access all clusters integrated with Codefresh. Restrict pipeline access to clusters by enabling cluster-injection for individual pipelines in the account.
-
-Selectively restricting access to clusters for a pipeline:
-* Enhances security by restricting access to users from different teams.
-* Reduces the overall duration of the build by shortening the initialization phase.
- Codefresh authenticates the credentials of every cluster that the pipeline accesses during the initialization phase. This action affects build duration for accounts with large numbers of clusters.
-
-1. In the Codefresh UI, select **Account Settings**, and then [**Pipeline Settings**](https://g.codefresh.io/account-admin/account-conf/pipeline-settings){:target="\_blank"}.
-1. Toggle **Kubernetes cluster context pipeline injection** to ON.
-
-{% include image.html
-lightbox="true"
-file="/images/administration/pipeline-settings/pipeline-inject-cluster-accnt-setting.png"
-url="/images/administration/pipeline-settings/pipeline-inject-cluster-accnt-setting.png"
-alt="Enabling cluster contexts for injection into pipelines"
-caption="Enabling cluster contexts for injection into pipelines"
-max-width="60%"
-%}
-
-You can then select specific clusters for individual pipelines, through the **Kubernetes cluster** option in the [Pipeline's Policies section]({{site.baseurl}}/docs/configure-ci-cd-pipeline/pipelines/#policies).
-
-
-## Pipeline YAML Section
-
-Here you can restrict the sources of pipeline YAML that users can select. The options are:
-
-* Enable/Disable the [inline editor]({{site.baseurl}}/docs/configure-ci-cd-pipeline/pipelines/#using-the-inline-pipeline-editor) where YAML is stored in Codefresh SaaS
-* Enable/disable pipeline YAML from connected Git repositories
-* Enable/disable pipeline YAML from [external URLs]({{site.baseurl}}/docs/configure-ci-cd-pipeline/pipelines/#loading-codefreshyml-from-version-control)
-
-You need to allow at least one of these options so that users can create new pipelines. We suggest leaving the first option enabled when users are still learning about Codefresh and want to experiment.
-
-## Advanced Pipeline Options
-
-Here you can set the defaults for advanced pipeline behavior. The options are:
-
-* [Keep or discard]({{site.baseurl}}/docs/codefresh-yaml/steps/approval/#keeping-the-shared-volume-after-an-approval) the volume when a pipeline is entering approval state
-* Whether pipelines in approval state [count or not against concurrency]({{site.baseurl}}/docs/codefresh-yaml/steps/approval/#define-concurrency-limits)
-* Define the [Service Account]({{site.baseurl}}/docs/integrations/docker-registries/amazon-ec2-container-registry/#setting-up-ecr-integration---service-account) for Amazon ECR integration.
-* Set the default registry where all Public Marketplace Step images are pulled from. Registries listed are from the [Docker Registry]({{site.baseurl}}/docs/integrations/docker-registries/) integration page.
- * Example: Public Marketplace Step image is defined to use Docker Hub. If you select a quay.io integration, all Public Marketplace Step images will be pulled from quay.io instead of Docker Hub.
- * Note: This does not affect Freestyle Steps.
-
-Note that the first option affects pipeline resources and/or billing in the case of SaaS pricing. It will also affect users of existing pipelines that depend on this behavior. It is best to enable/disable this option only once at the beginning.
-
-## Default Behavior for Build Step
-
-Here you can decide if the build step will push images or not according to your organization’s needs. The options are:
-
-1. Users need to decide if an image will be pushed or not after it is built
-2. All built images are automatically pushed to the default registry
-3. All built images are NOT pushed anywhere by default
-
-Note that this behavior is simply a convenience feature for legacy pipelines. Users can still use a [push step]({{site.baseurl}}/docs/codefresh-yaml/steps/push/) in a pipeline and always push an image to a registry regardless of what was chosen in the build step.
-
-## What to read next
-
-* [Creating Pipelines]({{site.baseurl}}/docs/configure-ci-cd-pipeline/pipelines/)
-* [Codefresh YAML]({{site.baseurl}}/docs/codefresh-yaml/what-is-the-codefresh-yaml/)
-* [Git Integration]({{site.baseurl}}/docs/integrations/git-providers/)
diff --git a/_docs/administration/platform-ip-addresses.md b/_docs/administration/platform-ip-addresses.md
index 3d2e6e258..dc671aef8 100644
--- a/_docs/administration/platform-ip-addresses.md
+++ b/_docs/administration/platform-ip-addresses.md
@@ -1,17 +1,24 @@
---
-title: "Codefresh Platform IP addresses"
+title: "Codefresh IP addresses"
description: "How to allowlist the IP addresses of the Codefresh platform"
group: administration
+redirect_from:
+ - /docs/administration/platform-ip-addresses/
toc: true
---
+Access to Kubernetes clusters behind strict firewalls not accessible from the public internet is governed through authorized IP addresses.
+Codefresh provides a list of IP addresses to be configured on clusters to allow access to them.
-If you want to use Codefresh for [a Kubernetes cluster]({{site.baseurl}}/docs/deploy-to-kubernetes/add-kubernetes-cluster/) that has a strict firewall, you can only allow access to specific IP addresses
-that the Codefresh platform is using. This will allow you to deploy to your cluster even when it is not accessible from the public internet
+You can register multiple external clusters to the Codefresh Runner and GitOps Runtimes. All Runtimes require Codefresh platform IPs to be configured on the clusters.
+In addition, managed clusters registered to Hosted GitOps Runtimes must be configured with a set of specific IP addresses to authorize access.
->Note that this is for paying customers and needed only for customers that use the [SAAS version of Codefresh]({{site.baseurl}}/docs/administration/installation-security/). If you use the [Codefresh runner]({{site.baseurl}}/docs/administration/codefresh-runner/), there is no need to open any IPs and ports in your firewall.
-## Current IPs used by the Codefresh platform (updated January 2023)
+## Codefresh platform IPs (updated January 2023)
+
+All the IPs are NAT gateways, and need to enable specific IPs instead of ranges.
+
+>If you do use these IPs, we **strongly recommend** that you monitor this page on a regular basis.
- 107.21.238.215
- 18.209.185.91
@@ -39,30 +46,28 @@ that the Codefresh platform is using. This will allow you to deploy to your clus
- 3.228.62.77
- 44.205.132.73
- 34.235.30.144
-- 54.160.88.80
+- 54.160.88.80
-All the IPs are NAT gateways, and therefore you only need to enable specific IPs instead of ranges.
+> We have a [plain text version of the IP addresses]({{site.baseurl}}/docs/administration/cf-ip4.txt). Recommended for monitoring changes.
+
+## Codefresh IPs for Hosted GitOps Runtimes
-> We have a plain text version of the IP Addresses located [here]({{site.baseurl}}/docs/administration/cf-ip4.txt). Recomended if you need it for monitoring changes.
+- 34.207.5.18
+- 34.232.79.230
+- 44.193.43.5
-## Old Codefresh IPs
+## API access to IPs for clusters
+Clusters must be configured with API access to the authorized Codefresh IPs.
+If you haven't configured your clusters with the required IPs, use the links below to complete the configuration for the clusters listed:
-These IP addresses have been removed, please replace these with the IP addresses above.
+[AKS (Azure Kubernetes Service)](https://docs.microsoft.com/en-us/azure/aks/api-server-authorized-ip-ranges){:target="\_blank"}
-- 104.154.63.253
-- 104.197.160.122
-- 18.213.176.41
-- 13.59.201.170
-- 104.155.130.126
-- 147.234.23.250
-- 34.233.31.180
-- 104.154.99.188
-- 146.148.100.14
-- 34.237.229.16
+[EKS (Amazon Elastic Container Service)](https://aws.amazon.com/premiumsupport/knowledge-center/eks-lock-api-access-IP-addresses/){:target="\_blank"}
-## What to read next
+[GKE (Google Kubernetes Engine)](https://cloud.google.com/kubernetes-engine/docs/how-to/private-clusters){:target="\_blank"}
-- [Codefresh installation options]({{site.baseurl}}/docs/administration/installation-security/)
-- [Codefresh runner]({{site.baseurl}}/docs/administration/codefresh-runner/)
-- [Codefresh behind the firewall]({{site.baseurl}}/docs/administration/behind-the-firewall/)
-- [Managing your Kubernetes cluster]({{site.baseurl}}/docs/deploy-to-kubernetes/manage-kubernetes/)
+## Related articles
+[Codefresh Runner installation]({{site.baseurl}}/docs/installation/codefresh-runner/)
+[Set up a Hosted GitOps Runtime]({{site.baseurl}}/docs/installation/gitops/hosted-runtime/)
+[Install Hybrid GitOps Runtimes]({{site.baseurl}}/docs/installation/gitops/hybrid-gitops/)
+
diff --git a/_docs/administration/user-self-management.md b/_docs/administration/user-self-management.md
new file mode 100644
index 000000000..4b912e3c6
--- /dev/null
+++ b/_docs/administration/user-self-management.md
@@ -0,0 +1,14 @@
+---
+title: "User settings"
+description: "Learn how to change your personal settings in Codefresh"
+group: administration
+toc: true
+---
+
+You can change your email notifications and API keys in your [settings screen]({{site.baseurl}}/docs/administration/user-self-management/user-settings/).
+
+For GitOps integrations you can also manage [your own Git tokens]({{site.baseurl}}/docs/administration/user-self-management/manage-pats/).
+
+
+
+.
\ No newline at end of file
diff --git a/_docs/administration/user-self-management/manage-pats.md b/_docs/administration/user-self-management/manage-pats.md
new file mode 100644
index 000000000..d4fb426c7
--- /dev/null
+++ b/_docs/administration/user-self-management/manage-pats.md
@@ -0,0 +1,150 @@
+---
+title: "Managing Git PATs"
+description: ""
+group: administration
+sub_group: user-self-management
+toc: true
+---
+
+As a user in Codefresh, you must authorize access to your Git provider accounts, and authenticate Git-based actions from Codefresh clients, per provisioned runtime.
+The authorization method depends on the Git provider and on what authorization has been set up by your account admin.
+* If your admin has set up authentication with OAuth2, you can authorize access using OAuth2.
+* You can always generate a personal access token from your Git provider and then add the same to Codefresh to authorize access.
+
+> If you have access to more than one runtime, you can use the same token for multiple runtimes.
+ You must however authorize access individually for each runtime.
+
+{::nomarkdown}
+
+{:/}
+
+
+## Authorize Git access in Codefresh
+Authorize Git access with OAuth2 if your account admin has set up Codefresh as an OAuth application, or alternatively through personal access tokens from your Git provider.
+>Notes:
+ For OAuth2: The adminstrator pre-configures the permissions and expiry date. Once you supply your credentials for authorization, you are automatically directed to the Git Personal Tokens page.
+
+**Before you begin**
+
+Make sure you have:
+* For Bitbucket only, your Bitbucket account username
+* If needed, a _personal access token_ from your Git provider with the required scopes:
+ * [GitHub](#generate-github-personal-access-tokens)
+ * [GitLab](#generate-gitlab-personal-access-tokens)
+ * [Bitbucket](#generate-bitbucket-personal-access-tokens)
+
+
+**How to**
+1. In the Codefresh UI, on the toolbar, click the **Settings** icon and then select **Git Personal Access Token** (TBD(https://g.codefresh.io/account-admin/collaborators/users){:target="\_blank"}).
+1. Select the runtime, and then do one of the following:
+ * To add a token, select **Add Token**.
+ * To update an existing token by replacing it with a new token, select **Update Token**.
+1. For **OAuth2**:
+ > If the application is not registered, the button is disabled. Contact your admin for help.
+ * Click **Authorize Access to GitHub**.
+ * Enter your credentials, and select **Sign In**.
+ * Complete the verification if required, as when two-factor authentication is configured, for example.
+
+
+
+ For **Git personal access tokens**:
+ * Expand **Advanced authorization options**.
+ * For Bitbucket, enter your **Bitbucket username**.
+ * In the **Personal Access Token** field, paste the token you generated.
+
+
+
+
+{:start="4"}
+1. Click **Add Token**.
+ In the Git Personal Access Tokens list, you can see that the new token is assigned to the runtime.
+
+{::nomarkdown}
+
+{:/}
+
+### Generate GitHub personal access tokens
+
+1. Log in to your GitHub or GitHub Enterprise account.
+1. Select **Settings > Developer Settings > Personal Access Tokens > Tokens (classic)**.
+1. Define the following:
+ * Token name
+ * Expiration date
+ * Select scope: `repo`
+
+ {% include
+ image.html
+ lightbox="true"
+ file="/images/administration/manage-pats/github-pat-scopes.png"
+ url="/images/administration/manage-pats/github-pat-scopes.png"
+ alt="GitHub personal access token scopes"
+ caption="GitHub personal access token scopes"
+ max-width="50%"
+ %}
+
+{:start="4"}
+1. Copy the personal access token generated as you will need it to authorize access.
+
+{::nomarkdown}
+
+{:/}
+
+### Generate GitLab personal access tokens
+
+1. Log in to your GitLab Cloud or Server account.
+1. Select **User settings > Access tokens**.
+1. Define the following:
+ * Token name
+ * Expiration date
+ * Select these scopes: `read_api`, `read_repository`, `write_repository`
+
+ {% include
+ image.html
+ lightbox="true"
+ file="/images/administration/manage-pats/gitlab-pat-scopes.png"
+ url="/images/administration/manage-pats/gitlab-pat-scopes.png"
+ alt="GitLab personal access token scopes"
+ caption="GitLab personal access token scopes"
+ max-width="50%"
+ %}
+
+{:start="4"}
+1. Copy the personal access token generated as you will need it to authorize access.
+
+
+
+
+{::nomarkdown}
+
+{:/}
+
+### Generate Bitbucket personal access tokens
+
+
+1. Log in to your Bitbucket Cloud or Server account.
+1. Select **Personal Settings > App passwords**.
+1. Define the **Label**.
+ Select these scopes:
+ * **Permissions**: `Read`
+ * **Workspace membership**: `Read`
+ * **Repositories**: `Write`
+
+ {% include
+ image.html
+ lightbox="true"
+ file="/images/administration/manage-pats/bitbucket-pat-scopes.png"
+ url="/images/administration/manage-pats/bitbucket-pat-scopes.png"
+ alt="Bitbucket personal access token scopes"
+ caption="Bitbucket personal access token scopes"
+ max-width="50%"
+ %}
+
+{:start="4"}
+1. Copy the personal access token generated as you will need it to authorize access.
+
+{::nomarkdown}
+
+{:/}
+
+## Related articles
+[Git tokens in Codefresh]({{site.baseurl}}/docs/reference/git-tokens/)
\ No newline at end of file
diff --git a/_docs/administration/user-self-management/user-settings.md b/_docs/administration/user-self-management/user-settings.md
new file mode 100644
index 000000000..ca8d36c6c
--- /dev/null
+++ b/_docs/administration/user-self-management/user-settings.md
@@ -0,0 +1,115 @@
+---
+title: "Managing personal user settings"
+description: "Manage your personal settings"
+group: administration
+sub_group: user-self-management
+redirect_from:
+ - /docs/administration/user-settings/
+toc: true
+---
+
+As a Codefresh user, you can manage several settings in your personal account, including:
+
+* Email notifications for builds and build usage
+* Grant account access to Codefresh support
+* Grant access to private Git repositories
+* Create and manage API keys
+
+> To manage Git personal access tokens for GitOps, see [Managing PATs]({{site.baseurl}}/docs/administration/user-self-management/manage-pats).
+
+## Access user settings
+* In the Codefresh UI, on the toolbar, click the **Settings** icon and then select [**User Settings**](https://g.codefresh.io/user/settings){:target="\_blank"}.
+
+## Email notifications for pipeline builds
+
+Configure the email notifications you want to receive for builds based on the build status: only successful, only failed, or for both successful and failed builds.
+
+> By default, email notifications for builds are disabled for _all users_.
+
+* In **Notifications**, define the email address and select the notifications:
+ * Email address for the notifications. By default, it's the same address you used to [sign up]({{site.baseurl}}/docs/administration/account-user-management/create-codefresh-account/).
+* Select the build statuses for which to receive notifications.
+
+
+
+{% include image.html
+lightbox="true"
+file="/images/administration/user-settings/notifications.png"
+url="/images/administration/user-settings/notifications.png"
+alt="Email notifications for pipeline builds"
+caption="Email notifications for pipeline builds"
+max-width="50%"
+%}
+
+
+
+## Weekly updates of build usage
+
+Select to receive weekly summaries of builds across your pipelines along with other statistical data. This information can be useful if you want to understand your overall project build health and capacity usage.
+
+* In **Updates**, select or clear **Receive updates...**.
+
+
+## Enable access for Codefresh support
+
+Enable Codefresh support personnel to access your user account. Access to your account is useful for visibility during troubleshooting. If you have an issue with the Codefresh platform, our support personnel can log into your account and look at running builds, inspect Docker images, run pipelines for you etc.
+
+You can disable this security setting at any time.
+
+>Codefresh personnel takes action only after confirmation from you, and all actions are audited.
+
+* In **Security**, select **Allow Codefresh support team to log in…**..
+
+
+{% include image.html
+lightbox="true"
+file="/images/administration/user-settings/allow-support-access.png"
+url="/images/administration/user-settings/allow-support-access.png"
+alt="Allow access to Codefresh support"
+caption="Allow access to Codefresh support"
+max-width="100%"
+%}
+
+
+
+## Git provider private access
+
+When you connect your [Git provider]({{site.baseurl}}/docs/integrations/git-providers/) during sign-up, you may choose to let Codefresh access only your public Git repositories.
+
+To allow Codefresh to also add [Git triggers]({{site.baseurl}}/docs/pipelines/triggers/git-triggers/) on private repositories you need to explicitly enable it in this section.
+
+Note that options available highly depend on what Git provider you are using with Codefresh.
+
+## Create and manage API keys
+
+Generate new API keys to access Codefresh functionality from your scripts or applications, outside the Codefresh UI. Edit scopes for existing keys, or revoke them when needed.
+For details, see [Codefresh API]({{site.baseurl}}/docs/integrations/codefresh-api/#authentication-instructions).
+
+>Tokens are visible only during creation. You cannot "view" an existing token. To re-enable API access for an existing application, you must delete the old token and create a new one.
+
+ The UI shows the first few characters in the second part of the key, after the `.`, and not the characters at the beginning of the key.
+
+
+
+
+1. In **API Keys**, to generate a new API key, click **Generate**.
+1. Select the scopes for the key.
+
+
+{% include image.html
+lightbox="true"
+file="/images/integrations/api/generate-token.png"
+url="/images/integrations/api/generate-token.png"
+alt="Generating a key for the API"
+caption="Generating a key for the API"
+max-width="80%"
+%}
+
+
+
+## Related articles
+
+
+[Single Sign on]({{site.baseurl}}/docs/single-sign-on/)
+
+
diff --git a/_docs/administration/user-settings.md b/_docs/administration/user-settings.md
deleted file mode 100644
index f379141e9..000000000
--- a/_docs/administration/user-settings.md
+++ /dev/null
@@ -1,99 +0,0 @@
----
-title: "User Settings"
-description: "Manage Email Notifications and API Keys"
-group: administration
-toc: true
----
-
-To access your individual user settings navigate to [https://g.codefresh.io/user/settings](https://g.codefresh.io/user/settings) or click on *User Settings* on the left sidebar.
-
-## Email Notifications for Builds
-
-> **IMPORTANT**:
- On 26 August 2022, we switched off email notifications for all accounts.
- To re-enable email notifications, update the email notification settings for your account _after_ the above date.
-
-
-Receive email notifications for builds based on the build status: only successful, only failed, or for both successful and failed builds.
-
-> By default, email notifications are disabled for _all users_, for both successful and failed builds.
-
-**Email notification settings**
-
-* Email address for the notifications. By default it is the same address you used to [sign-up]({{site.baseurl}}/docs/getting-started/create-a-codefresh-account/).
-* Select to receive emails for successful builds
-* Select to receive emails for failed builds
-
-
-
-{% include image.html
-lightbox="true"
-file="/images/administration/user-settings/notifications.png"
-url="/images/administration/user-settings/notifications.png"
-alt="email settings"
-caption="email settings"
-max-width="50%"
-%}
-
-
-
-## Weekly Updates for Build Usage
-
-Codefresh will send you every week a summary of your builds across your pipelines along with other statistical data. This information can be useful if you want to understand your overall project build health and capacity usage.
-
-If you don't want to receive these emails, you can disable them by toggling the checkbox and clicking the *Save* button.
-
-## Enable Access for Support Personnel
-
-If you have an issue with the Codefresh platform, our support personnel can log into your account and look at running
-builds, inspect your docker images, run pipelines for you etc.
-
-To allow for this kind of access you need to enable the checkbox marked with `Allow Codefresh support team to login as my user`
-under the *Security* section.
-
-{% include image.html
-lightbox="true"
-file="/images/administration/user-settings/allow-support-access.png"
-url="/images/administration/user-settings/allow-support-access.png"
-alt="Allow access from support"
-caption="Allow access from support"
-max-width="100%"
-%}
-
-If you don't enable this checkbox, our support staff have **zero visibility** in your account. You can enable/disable this checkbox on demand at any point in time.
-
-All actions performed by Codefresh personnel on your account are audited and they will also confirm with you before performing any action with side effects (such as running a pipeline).
-
-
-## Git Provider Private Access
-
-When you connect your [Git provider]({{site.baseurl}}/docs/integrations/git-providers/) during sign-up, you may choose to let Codefresh access only your public Git repositories.
-
-To allow Codefresh to also add [Git triggers]({{site.baseurl}}/docs/configure-ci-cd-pipeline/triggers/git-triggers/) on private repositories you need to explicitly enable it in this section.
-
-Note that options available highly depend on what Git provider you are using with Codefresh.
-
-## API Key Creation
-
-In this section you can create API keys so that you can access Codefresh features from your scripts or applications outside the UI. To create a new token click the *Generate* button as described in the [API documentation page]({{site.baseurl}}/docs/integrations/codefresh-api/#authentication-instructions) and select the appropriate scopes.
-
-{% include image.html
-lightbox="true"
-file="/images/integrations/api/generate-token.png"
-url="/images/integrations/api/generate-token.png"
-alt="Generating a key for the API"
-caption="Generating a key for the API"
-max-width="80%"
-%}
-
-For each token you can also delete it or edit it and change its applicable scopes.
-
-Note that tokens are visible only during creation. You cannot "view" an existing token. If you want to re-enable API access for an existing application you need to delete the old token and create a new one.
-
-> Note: The UI shows the first few characters in the second part of the key, after the `.`, and not the characters at the beginning of the key.
-
-## What to read next
-
-* [Add users]({{site.baseurl}}/docs/administration/invite-your-team-member/)
-* [Single Sign on]({{site.baseurl}}/docs/administration/single-sign-on/)
-
diff --git a/_docs/ci-cd-guides/access-docker-registry-from-kubernetes.md b/_docs/ci-cd-guides/access-docker-registry-from-kubernetes.md
new file mode 100644
index 000000000..63c3782bb
--- /dev/null
+++ b/_docs/ci-cd-guides/access-docker-registry-from-kubernetes.md
@@ -0,0 +1,129 @@
+---
+title: "Accessing Docker registry from Kubernetes cluster"
+description: "Allow Kubernetes to pull Docker images from your registry"
+group: ci-cd-guides
+redirect_from:
+ - /docs/deploy-to-kubernetes/access-docker-registry-from-kubernetes/
+toc: true
+---
+
+Kubernetes deployments are based on a "pull" approach. When you deploy your application to a Kubernetes
+cluster, instead of uploading the application itself, as in traditional deployments, Kubernetes pulls the Docker images to its nodes on its own.
+
+
+ {% include
+image.html
+lightbox="true"
+file="/images/quick-start/quick-start-k8s/overview.png"
+url="/images/quick-start/quick-start-k8s/overview.png"
+alt="Kubernetes deployments"
+caption="Kubernetes deployments"
+max-width="80%"
+%}
+
+If your Docker images are in a public repository such as Docker Hub, Kubernetes can pull them right away. In most cases however your images are in a private Docker registry and Kubernetes must be given explicit access to it.
+
+Use [Docker registry secrets](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/){:target="\_blank"} to give Kubernetes access to private Docker registries. When there is a deployment, each Kubernetes pod can pull Docker images directly from the target registry.
+
+## Giving access to a Docker Registry via the UI
+
+Codefresh allows you to easily create and pull secrets for your cluster.
+
+1. In the Codefresh UI, set up an integration with your [Docker registry in Codefresh]({{site.baseurl}}/docs/integrations/docker-registries/).
+ Codefresh can work with any compliant Docker registry either in the cloud or behind the firewall.
+
+1. To view the Kubernetes dashboard, from the Ops section in the sidebar, select [**Kubernetes Services**](https://g.codefresh.io/kubernetes/services/){:target="\_blank"}.
+1. Click **Add Service**.
+1. Do the following:
+ * Select your **Cluster** and **Namespace** from the respective lists.
+ * From the **Image Pull Secret** dropdown with all the pull secrets for the selected namespace, select **Create Registry Pull secret**.
+ * From the list of all the connected Docker registries in Codefresh, select the registry you want.
+ Codefresh automatically creates a secret for you.
+
+ {% include
+image.html
+lightbox="true"
+file="/images/guides/kubernetes/create-secret.png"
+url="/images/guides/kubernetes/create-secret.png"
+alt="Create Pull Secret"
+caption="Create Pull Secret"
+max-width="80%"
+%}
+
+
+>The secret is created as soon as you select your Docker registry from the dropdown. There is no need to actually deploy anything from this screen for the changes to take effect.
+
+ {% include
+image.html
+lightbox="true"
+file="/images/guides/kubernetes/secret-dropdown.png"
+url="/images/guides/kubernetes/secret-dropdown.png"
+alt="Docker Registry Access"
+caption="Docker Registry Access"
+max-width="80%"
+%}
+
+From now on, the cluster in this namespace can deploy Docker images from the selected registry.
+To apply the changed secret, you don't really need to finish the deployment. Feel free to
+close the screen and go to another Codefresh page.
+
+>Codefresh automatically uses the secret you defined in all deployments that are performed via the UI by dynamically creating the correct manifests for you behind the scenes.
+If you wish to use your own manifests, you need to include the secret yourself, as explained in the next section.
+
+
+## Giving access to a Docker Registry with kubectl
+
+You can also use the `kubectl` command directly to give access to a Docker registry.
+As this method is not specific to Codefresh, read the [official kubernetes documentation](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/){:target="\_blank"}.
+
+
+### Creating the Docker registry secret
+
+The credentials depend upon the [type of registry]({{site.baseurl}}/docs/integrations/docker-registries/) you use.
+
+- The Docker server to use is a domain such `gcr.io`, `azurecr.io`
+- The username is your account username.
+- The password is a specific Docker registry password or any other kind of token. You need to check the documentation of your registry provider for the exact details.
+
+>Be sure to create the secret in the namespace in which your application will run.
+Pull secrets are specific to a namespace. If you want to deploy to multiple namespaces, you need to create a secret for each one of them.
+
+This is an example of creating a pull secret to the Azure registry. You can use the same command for any other private registry.
+
+ `Shell`
+{% highlight sh %}
+{% raw %}
+
+export DOCKER_REGISTRY_SERVER=mysampleregistry.azurecr.io
+export DOCKER_USER=myregistryname
+export DOCKER_PASSWORD=myregistrytoken
+export DOCKER_EMAIL=YOUR_EMAIL
+
+kubectl create secret docker-registry cfcr\
+ --docker-server=$DOCKER_REGISTRY_SERVER\
+ --docker-username=$DOCKER_USER\
+ --docker-password=$DOCKER_PASSWORD\
+ --docker-email=$DOCKER_EMAIL
+{% endraw %}
+{% endhighlight %}
+
+### Using the Docker registry secret
+
+To use the secret you just created, you need to include it, either in:
+
+* Your [pod manifests](https://kubernetes.io/docs/concepts/containers/#specifying-imagepullsecrets-on-a-pod){:target="\_blank"}
+* The [service account](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account){:target="\_blank"}
+
+For Docker registry secret usage, we recommend following the official Kubernetes documentation.
+
+## Giving access to a Docker Registry via the Codefresh CLI
+
+The Codefresh CLI can also create pull secrets in an automated manner.
+
+See [Image pull Secret](https://codefresh-io.github.io/cli/more/image-pull-secret/){:target="\_blank"}.
+
+## Related articles
+[Kubernetes deployment quick start]({{site.baseurl}}/docs/quick-start/ci-quick-start/deploy-to-kubernetes/)
+[Managing Kubernetes clusters]({{site.baseurl}}/docs/deployments/kubernetes/manage-kubernetes/)
+
+
diff --git a/_docs/ci-cd-guides/add-config-maps-to-your-namespaces.md b/_docs/ci-cd-guides/add-config-maps-to-your-namespaces.md
new file mode 100644
index 000000000..b04f946c3
--- /dev/null
+++ b/_docs/ci-cd-guides/add-config-maps-to-your-namespaces.md
@@ -0,0 +1,149 @@
+---
+title: "Adding config maps to namespaces"
+description: "Manage Kubernetes Config Maps with Codefresh"
+group: ci-cd-guides
+redirect_from:
+ - /docs/deploy-to-kubernetes/add-config-maps-to-your-namespaces/
+ - /docs/add-config-maps-to-your-namespaces/
+toc: true
+---
+Many applications require configuration with files, environment variables, and command line arguments. It makes applications portable and easily manageable. While this makes for easy configuration, it can become very hard to support tons of config files for different environments and hundreds of microservices.
+
+Kubernetes provides an elegant and very convenient way for application configuration, using *configuration maps*. You can find more details about config maps at [Kubernetes - Configure a Pod to Use a ConfigMap](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/){:target="_blank"}.
+
+You can manage all your cluster configuration using Codefresh.
+
+## View existing config maps
+
+1. In the Codefresh UI, from Ops in the sidebar, select [**Kubernetes Services**](https://g.codefresh.io/kubernetes/services/){:target="\_blank"}.
+1. Switch to list view.
+
+{% include
+image.html
+lightbox="true"
+file="/images/guides/config-maps/change-view.png"
+url="/images/guides/config-maps/change-view.png"
+alt="Change View"
+caption="Change View"
+max-width="50%"
+%}
+
+{:start="3"}
+1. Select a namespace and hover over it.
+1. Click the **Settings** icon which appears at the end of the row.
+ A list of all config maps within this namespace are displayed, with their date of creation and number of configuration variables.
+
+
+
+## Add a new config map
+
+1. From the list of config maps, click **Create a New Config Map**.
+
+{% include image.html
+lightbox="true"
+file="/images/guides/config-maps/manage-maps-namespace.png"
+url="/images/guides/config-maps/manage-maps-namespace.png"
+alt="Create a new config map in namespace"
+caption="Create a new config map in namespace"
+max-width="40%"
+%}
+
+{:start="2"}
+1. In the Add a New Config Map form, enter a **Name**, add variables, as described in [Managing variables in your config maps](#managing-variables-in-config-maps), and then click **Create**.
+
+{% include image.html
+lightbox="true"
+file="/images/guides/config-maps/new-config-map-settings.png"
+url="/images/guides/config-maps/new-config-map-settings.png"
+alt="Define settings for new config map"
+caption="Define settings for new config map"
+max-width="40%"
+%}
+
+### Managing variables in config maps
+There are three options to add variables to config maps:
+1. Add a single variable at a time
+1. Add multiple variables by copying and pasting from text or file
+1. Import a set of variables from an existing config map
+
+
+#### Add a single variable to config map
+
+This is the easiest way to add a variable to the config map. This method is very useful to quickly create a small configmap with 1-2 variables:
+1. Enter Key name and the Key value
+1. Click **Add Variable**.
+
+{% include image.html
+lightbox="true"
+file="/images/guides/config-maps/add-new-single-variable.png"
+url="/images/guides/config-maps/add-new-single-variable.png"
+alt="Add single variable at a time to config map"
+caption="Add single variable at a time to config map"
+max-width="40%"
+%}
+
+
+#### Import variables from text/file
+If you already have configuration variables in a `*.property` file, you can easily import it to your configmap.
+
+**Import from text**:
+
+
+1. Click **Import from text**.
+1. Copy text from file and paste it within the text area in the required format.
+1. Click **Apply**.
+
+{% include image.html
+lightbox="true"
+file="/images/guides/config-maps/import-variables-from-text.png"
+url="/images/guides/config-maps/import-variables-from-text.png"
+alt="Add multiple variables from text or file to config map"
+caption="Add multiple variables from text or file to config map"
+max-width="40%"
+%}
+
+**Import from file**:
+
+1. Click **Import from file**.
+1. Select the file from your computer, and click **Open**.
+
+
+#### Copy variables from existing config map
+
+You can easily copy the variables from an existing config map file, and use it in other namespaces.
+
+1. Click **Copy from Existing Config Map**.
+1. Select the **Cluster** and **Namespace** from which to copy the configmap.
+1. Select the configmap from the list, and click **Select**.
+
+{% include image.html
+lightbox="true"
+file="/images/guides/config-maps/select-cluster-namespace.png"
+url="/images/guides/config-maps/select-cluster-namespace.png"
+alt="Copy variables from existing config map"
+caption="Copy variables from existing config map"
+max-width="40%"
+%}
+
+### Edit/remove variables in config maps
+You can easily edit or remove variables in your config maps.
+
+1. Select the config map with the variables to modify or remove.
+1. Click the **Edit** (pencil) icon.
+1. Add new variables, as described in [Managing variables in your config maps](#managing-variables-in-config-maps).
+
+{% include image.html
+lightbox="true"
+file="/images/guides/config-maps/edit-remove-config-map-variables.png"
+url="/images/guides/config-maps/edit-remove-config-map-variables.png"
+alt="Edit/remove variables in config maps"
+caption="Edit/remove variables in config maps"
+max-width="40%"
+%}
+
+To remove a config map, click on "remove" icon in the selected row. After your confirmation, the configmap will be removed.
+
+## Related articles
+[Connect to a Kubernetes cluster]({{site.baseurl}}/docs/integrations/#connect-a-kubernetes-cluster)
+[Managing Kubernetes clusters]({{site.baseurl}}/docs/deployments/kubernetes/manage-kubernetes/)
+[Kubernetes deployment quick start]({{site.baseurl}}/docs/quick-start/ci-quick-start/deploy-to-kubernetes/)
diff --git a/_docs/ci-cd-guides/building-docker-images.md b/_docs/ci-cd-guides/building-docker-images.md
index 75ca7ff5b..a119f9562 100644
--- a/_docs/ci-cd-guides/building-docker-images.md
+++ b/_docs/ci-cd-guides/building-docker-images.md
@@ -1,50 +1,51 @@
---
title: "Building Docker images"
-description: "Learn how to create Docker images from Dockerfiles"
+description: "Create Docker images from Dockerfiles"
group: ci-cd-guides
toc: true
---
-Codefresh has first-class Docker build support. You can build Docker images in your pipeline in a declarative manner using the [build step]({{site.baseurl}}/docs/codefresh-yaml/steps/build/).
-
->If your application is not deployed as a Docker image then see the [basic compilation/packaging guide]({{site.baseurl}}/docs/ci-cd-guides/packaging-compilation/) instead.
-
-Building a Dockerfile in a pipeline works in the same way as building the Dockerfile locally on your workstation. Your Dockerfile should be valid and follow all the best practices such as:
+Codefresh has first-class Docker build support. You can build Docker images in your pipeline in a declarative manner using the [build step]({{site.baseurl}}/docs/pipelines/steps/build/).
+>If your application is not deployed as a Docker image, see the [basic compilation/packaging guide]({{site.baseurl}}/docs/ci-cd-guides/packaging-compilation/) instead.
+Building a Dockerfile in a pipeline works the same way as building the Dockerfile locally on your workstation.
+Your Dockerfile should be valid, and follow all the best practices such as:
* Dockerfiles should be self-contained
* You should not have actions with side effects inside Dockerfiles
* You should have a proper `.dockerignore` file to minimize the Docker context size
-* Dockerfile directives should be placed according to best caching practices.
+* Dockerfile directives should be placed according to best practices for caching
-For more details see also the [Docker caching guide]({{site.baseurl}}/docs/configure-ci-cd-pipeline/pipeline-caching/#distributed-docker-layer-caching).
- At the very least you should understand and use [Docker multi-stage builds](https://docs.docker.com/develop/develop-images/multistage-build/) (although Codefresh supports all kinds of Dockerfiles natively). Basically, if your Dockerfile is already optimized on your local workstation, it should also be optimized for Codefresh.
+For more details, see also the [Caching in pipelines]({{site.baseurl}}/docs/pipelines/pipeline-caching/#distributed-docker-layer-caching).
+ At the very least, you should understand and use [Docker multistage builds](https://docs.docker.com/develop/develop-images/multistage-build/){:target="\_blank"} (although Codefresh supports all kinds of Dockerfiles natively). Basically, if your Dockerfile is already optimized on your local workstation, it should also be optimized for Codefresh.
-Codefresh is using the standard Docker daemon (or optionally Buildkit) behind the scenes, so if your Dockerfile has issues when you try to build it locally, it will have the same issues in a pipeline.
+Codefresh uses the standard Docker daemon (or optionally Buildkit) behind the scenes, so if your Dockerfile has issues when you try to build it locally, it will have the same issues in a pipeline.
## Docker packaging strategies
-There are many ways to create a Dockerfile and most organizations typically follow a different path depending on the type of application they package. Brand new applications are very easy to package into multi-stage Dockerfiles, while legacy/existing applications are adapted to dockerfiles that package an existing artifact.
+There are many ways to create a Dockerfile, and most organizations typically follow a different path depending on the type of application they package.
+Brand-new applications are very easy to package into multistage Dockerfiles, while legacy/existing applications are adapted to dockerfiles that package an existing artifact.
-We suggest spending some more time and creating multi-stage builds for all applications (even legacy ones). Explaining all virtues of multi-stage Docker builds is outside the scope of this page but in summary, multi-stage builds:
+We suggest spending some more time and creating multistage builds for all applications (even legacy ones).
+Explaining all virtues of multistage Docker builds is outside the scope of this article but in summary, multistage builds:
1. Are self-contained and self-describable
-1. Result in very small Docker image
-1. Can be easily built by all project stakeholder (even non-developers)
+1. Result in a very small Docker image
+1. Can be easily built by all project stakeholders, even non-developers
1. Are very easy to understand and maintain
-1. Do not require a development environment (apart from the source code itself)
-1. Can be packaged with very simple pipelines (not only in Codefresh but in other CI systems as well)
+1. Do not require a development environment, apart from the source code itself
+1. Can be packaged with very simple pipelines, not only in Codefresh, but in other CI systems as well
-Multi-stage builds are also essential in organizations that employ multiple programming languages. The ease of building a Docker image by anybody without the need for JDK/Node/Python/etc. cannot be overstated.
+Multi-stage builds are also essential in organizations that employ multiple programming languages. The ease of building a Docker image by anyone without the need for JDK/Node/Python/etc. cannot be overstated.
-## Production-ready Docker images with multi-stage builds
+## Production-ready Docker images with multistage builds
-If you have a multi-stage Dockerfile, then the respective pipeline in Codefresh is straightforward. You only need two pipeline steps
+If you have a multistage Dockerfile, then the respective pipeline in Codefresh is straightforward. You only need two pipeline steps:
-1. A clone step to checkout the source code
-1. A build step to create the Docker image.
+1. A clone step to check out the source code
+1. A build step to create the Docker image
-For example here is a [Java dockerfile]({{site.baseurl}}/docs/learn-by-example/java/spring-boot-2/#spring-boot-2-and-docker-multi-stage-builds):
+For example, here is a [Java dockerfile]({{site.baseurl}}/docs/example-catalog/ci-examples/spring-boot-2/#spring-boot-2-and-docker-multi-stage-builds):
`Dockerfile`
{% highlight docker %}
@@ -107,12 +108,12 @@ caption="Multi-stage Docker builds"
max-width="100%"
%}
-You can find multi-stage build examples for other programming languages in the [example section]({{site.baseurl}}/docs/yaml-examples/examples/).
+You can find multistage build examples for other programming languages in the [example section]({{site.baseurl}}/docs/example-catalog/examples/).
## Creating self-contained Docker images
-Even though multi-stage Dockerfile are the optimal way to build Docker images, Codefresh still supports "plain" Dockerfiles which do not have multiple stages.
+Even though multistage Dockerfiles are the optimal way to build Docker images, Codefresh still supports "plain" Dockerfiles which do not have multiple stages.
As an example, this Dockerfile for a Python application is created from a single parent image (although we use the slim variant to make the final image size smaller).
@@ -138,7 +139,7 @@ CMD ["python", "manage.py", "runserver", "0.0.0.0:8000"]
{% endhighlight %}
-This Dockerfile can be built in the same way as a multi-stage one. We still need two pipeline steps, one to check out the code and another to build the Docker image.
+This Dockerfile can be built in the same way as a multistage one. We still need two pipeline steps, one to check out the code and another to build the Docker image.
`codefresh.yml`
{% highlight yaml %}
@@ -166,7 +167,7 @@ steps:
{% endraw %}
{% endhighlight %}
-The pipeline is similar to the previous one, so you can handle multi-stage and non-multistage builds in the same manner in Codefresh pipelines.
+The pipeline is similar to the previous one, so you can handle multistage and non-multistage builds in the same manner in Codefresh pipelines.
{% include image.html
lightbox="true"
@@ -185,9 +186,9 @@ It is important however to note that the Dockerfile is still self-contained. It
An alternative way to create Docker images is to just package an existing artifact or application which is created earlier in the CI process.
->Notice that even though this is a very popular way to create Dockerfiles, and Codefresh supports it, we do **NOT** recommend to write Dockerfiles like this. Please learn about Docker multi-stage builds if you are not familiar with them.
+>Though this is a very popular way to create Dockerfiles, and Codefresh supports it, we do **NOT** recommend writing Dockerfiles like this. Please learn about Docker multistage builds if you are not familiar with them.
-You can see this pattern in all kinds of Dockerfiles that assume the application is already there (or that dependencies are already downloaded). Here is a [Dockerfile that packages an existing JAR]({{site.baseurl}}/docs/learn-by-example/java/spring-boot-2/#spring-boot-2-and-docker-package-only) file.
+You can see this pattern in all kinds of Dockerfiles that assume the application is already there (or that dependencies are already downloaded). Here is a [Dockerfile that packages an existing JAR]({{site.baseurl}}/docs/example-catalog/ci-examples/spring-boot-2/#spring-boot-2-and-docker-package-only) file.
`Dockerfile`
{% highlight docker %}
@@ -205,16 +206,16 @@ HEALTHCHECK --interval=1m --timeout=3s CMD wget -q -T 3 -s http://localhost:8080
{% endraw %}
{% endhighlight %}
-If you have Dockerfiles like this you need to enrich the basic pipeline shown in the previous sections and run a freestyle step that prepares the artifact **BEFORE** the build of the Docker image. Read more about [freestyle steps in the basic CI process page]({{site.baseurl}}/docs/ci-cd-guides/packaging-compilation/).
+If you have Dockerfiles like this you need to enrich the basic pipeline shown in the previous sections and run a freestyle step that prepares the artifact **BEFORE** building the Docker image. Read more about [freestyle steps in the basic CI process]({{site.baseurl}}/docs/ci-cd-guides/packaging-compilation/).
-There are several disadvantages to these kind of Dockerfiles:
+There are several disadvantages to these kinds of Dockerfiles:
* The Dockerfile is not self-contained anymore. You need to manually run some other command before actually running the Docker build
-* A person that wants to build the Docker image on their workstation is also forced to have a full dev environment (e.g. the JDK or Node.js)
-* The version of a development tool is mentioned twice (one in the Dockerfile and one in the CI/CD system)
+* A person who wants to build the Docker image on their workstation is also forced to have a full dev environment (e.g. the JDK or Node.js)
+* The version of a development tool is specified twice (one in the Dockerfile and one in the CI/CD system)
-Here is the respective Codefresh pipeline
+Here is the Codefresh pipeline:
`codefresh.yml`
{% highlight yaml %}
@@ -248,7 +249,7 @@ steps:
{% endraw %}
{% endhighlight %}
-This pipeline has an intermediate [freestyle step]({{site.baseurl}}/docs/codefresh-yaml/steps/freestyle/) that runs a specific version of Maven/JDK to create the JAR file. The jar file is then available to the next step via [the Codefresh volume]({{site.baseurl}}/docs/configure-ci-cd-pipeline/introduction-to-codefresh-pipelines/#sharing-the-workspace-between-build-steps).
+This pipeline has an intermediate [freestyle step]({{site.baseurl}}/docs/pipelines/steps/freestyle/) that runs a specific version of Maven/JDK to create the JAR file. The JAR file is then available to the next step via [the Codefresh volume]({{site.baseurl}}/docs/pipelines/introduction-to-codefresh-pipelines/#sharing-the-workspace-between-build-steps).
{% include image.html
lightbox="true"
@@ -259,9 +260,9 @@ caption="Package only Docker builds"
max-width="100%"
%}
-In the example above you can see that the version of JDK/JRE is mentioned twice (one in the pipeline and one in the Dockerfile). If developers decide to upgrade to Java 11 the need to change both places (and in big companies pipelines are usually managed by operators). If this was a multistage build then a developer could simply change just the Dockerfile and be certain that the pipeline is "upgraded" as well.
+In the example above, you can see that the version of JDK/JRE is mentioned twice (one in the pipeline and one in the Dockerfile). If developers decide to upgrade to Java 11, they need to change both places (and in big companies pipelines are usually managed by operators). If this was a multistage build then a developer could simply change just the Dockerfile and be certain that the pipeline is "upgraded" as well.
-We find that workflows like this are mostly coming from legacy CI solutions that are VM based. Codefresh is a container native solution, so if you have the opportunity you should create your pipelines from scratch when switching to Docker-based pipelines.
+We find that similar workflows are from legacy CI solutions that are VM-based. Codefresh is a container-native solution, so if you have the opportunity you should create your pipelines from scratch when switching to Docker-based pipelines.
## Avoiding non-standard Dockerfiles
@@ -274,9 +275,10 @@ There are several Dockerfiles that attempt to mimic a CI/CD system and perform n
* Cleaning up or tampering with database data
* Calling other external services with POST/PUT operations
-Not only does this make the pipeline much more complex (because retrying the pipeline now has side-effects) but you also need to pass special credentials in the Dockerfile itself via the pipeline, making the pipeline even more complicated.
+Not only does this make the pipeline much more complex (because retrying the pipeline now has consequences), but you also need to pass special credentials in the Dockerfile itself via the pipeline, making the pipeline even more complicated.
-You should avoid these kinds of directives inside a Dockerfile and simplify it so that all actions inside it are repeatable and non-destructive. A Dockerfile should mainly:
+You should avoid these kinds of directives inside a Dockerfile and simplify it so that all actions inside it are repeatable and non-destructive.
+A Dockerfile should mainly:
* Clone extra source code (if needed)
* Download dependencies
@@ -284,7 +286,7 @@ You should avoid these kinds of directives inside a Dockerfile and simplify it s
* Process/Minify/Transform local resources
* Run scripts and edit files on the container filesystem only
-As an example **TO AVOID** this Dockerfile is also trying to run a SonarQube analysis
+As an example **TO AVOID**, this Dockerfile is also trying to run a SonarQube analysis
`Dockerfile`
{% highlight docker %}
@@ -302,7 +304,7 @@ RUN yarn install \
{% endraw %}
{% endhighlight %}
-This Dockerfile has the following issues
+This Dockerfile has the following issues:
* It can run only where a SonarQube installation is available
* It needs extra credentials for the SonarQube instance
@@ -323,7 +325,7 @@ RUN yarn install \
{% endraw %}
{% endhighlight %}
-And then move the SonarQube part in the actual pipeline:
+And then move the SonarQube part to the actual pipeline:
`codefresh.yml`
{% highlight yaml %}
@@ -362,11 +364,11 @@ steps:
This makes the Docker build step as simple as possible.
-For more Docker best practices see our [Docker anti-patterns blog post](https://codefresh.io/containers/docker-anti-patterns/).
+For more Docker best practices see our [Docker anti-patterns blog post](https://codefresh.io/containers/docker-anti-patterns/){:target="\_blank"}.
## Pushing Docker images
-The build step in Codefresh is very smart and it will automatically also push your Docker image to your [default Docker registry]({{site.baseurl}}/docs/docker-registries/external-docker-registries/#the-default-registry).
+The build step in Codefresh is very smart and automatically also pushes your Docker image to your [default Docker registry]({{site.baseurl}}/docs/integrations/docker-registries/#default-registry).
{% include image.html
@@ -378,7 +380,7 @@ caption="Automatic Docker push"
max-width="80%"
%}
-Thus, if you run any of the above pipelines you will see your created image in the Docker image dashboard.
+Thus, if you run any of the above pipelines you can see the image created in the Docker image dashboard.
{% include image.html
@@ -390,13 +392,13 @@ caption="Docker image dashboard"
max-width="80%"
%}
-For more details on how to push Docker images see the [working with Docker registries page]({{site.baseurl}}/docs/docker-registries/working-with-docker-registries/).
+For more details on how to push Docker images see the [working with Docker registries page]({{site.baseurl}}/docs/ci-cd-guides/working-with-docker-registries/).
## Running Docker images
You can run Docker images inside a Codefresh pipeline using freestyle steps. You can use the freestyle step to run either an existing image from a private or public registry or even a Docker image that was created in the pipeline itself.
-This is a [very common pattern in Codefresh]({{site.baseurl}}/docs/codefresh-yaml/steps/freestyle/#dynamic-freestyle-steps) and works by simply mentioning the name of the build step that created the image.
+This is a [very common pattern in Codefresh]({{site.baseurl}}/docs/pipelines/steps/freestyle/#dynamic-freestyle-steps) and works by simply mentioning the name of the build step that created the image.
`codefresh.yml`
{% highlight yaml %}
@@ -421,17 +423,16 @@ steps:
{% endraw %}
{% endhighlight %}
-For more details see the [dynamic build tools page]({{site.baseurl}}/docs/configure-ci-cd-pipeline/introduction-to-codefresh-pipelines/#creating-docker-images-dynamically-as-build-tools) and the [context variables page]({{site.baseurl}}/docs/codefresh-yaml/variables/#context-related-variables)
+For more details see [dynamic build tools]({{site.baseurl}}/docs/pipelines/introduction-to-codefresh-pipelines/#creating-docker-images-dynamically-as-build-tools), and [context variables]({{site.baseurl}}/docs/pipelines/variables/#context-related-variables)
-## What to read next
+## Related articles
+[How Codefresh pipelines work]({{site.baseurl}}/docs/pipelines/introduction-to-codefresh-pipelines/)
+[Codefresh YAML for pipeline definitions]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/)
+[Steps in pipelines]({{site.baseurl}}/docs/pipelines/steps/)
+[Build step in pipelines]({{site.baseurl}}/docs/pipelines/steps/build/)
-* [How Codefresh pipelines work]({{site.baseurl}}/docs/configure-ci-cd-pipeline/introduction-to-codefresh-pipelines/)
-* [Codefresh YAML]({{site.baseurl}}/docs/codefresh-yaml/what-is-the-codefresh-yaml/)
-* [Pipeline steps]({{site.baseurl}}/docs/codefresh-yaml/steps/)
-* [Working with Docker registries]({{site.baseurl}}/docs/docker-registries/working-with-docker-registries/)
-* [Build step]({{site.baseurl}}/docs/codefresh-yaml/steps/build/)
diff --git a/_docs/ci-cd-guides/environment-deployments.md b/_docs/ci-cd-guides/environment-deployments.md
index 376d68f77..eac84542a 100644
--- a/_docs/ci-cd-guides/environment-deployments.md
+++ b/_docs/ci-cd-guides/environment-deployments.md
@@ -1,12 +1,12 @@
---
-title: "Production and Staging deployments"
-description: "Learn how to deploy to different environments from Codefresh pipelines"
+title: "Deploying to predefined environments"
+description: "Deploy to different production and staging environments from Codefresh pipelines"
group: ci-cd-guides
toc: true
---
-With Codefresh you can deploy a single application to multiple environments (e.g. qa/staging/prod) and manage all of them with a single or multiple pipelines.
-In this guide we will see how an example application can be deployed with different configurations and various workflows for handling environment deployment.
+With Codefresh, you can deploy a single application to multiple environments, such as, qa, staging, prod, and manage all of them with single or multiple pipelines.
+This guide describes how an example application can be deployed with different configurations and various workflows for handling environment deployment.
{% include image.html
lightbox="true"
@@ -19,20 +19,18 @@ max-width="80%"
## Prerequisites
-Before starting you will need to:
-
- 1. [create a Codefresh account]({{site.baseurl}}/docs/getting-started/create-a-codefresh-account/)
+Before starting, you will need to:
+ 1. [Create a Codefresh account]({{site.baseurl}}/docs/administration/account-user-management/create-codefresh-account/)
1. Get access to a Kubernetes cluster on any cloud provider
- 1. [connect the Kubernetes cluster]({{site.baseurl}}/docs/deploy-to-kubernetes/add-kubernetes-cluster/) to your account
- 1. install [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/) and [helm](https://helm.sh/docs/intro/install/) and point them to your cluster
- 1. have [Docker](https://docs.docker.com/get-docker/) installed locally (optional)
+ 1. [Connect the Kubernetes cluster]({{site.baseurl}}/docs/integrations/kubernetes/#connect-a-kubernetes-cluster/) to your account
+ 1. Install [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/){:target="\_blank"} and [helm](https://helm.sh/docs/intro/install/){:target="\_blank"} and point them to your cluster
+ 1. Have [Docker](https://docs.docker.com/get-docker/){:target="\_blank"} installed locally (optional)
-## The example application
+## Example application
-As a running example we will use a simple application with a Helm chart. [Helm is the package manager]({{site.baseurl}}/docs/new-helm/helm-best-practices/) for Kubernetes and has built-in support for passing different
-configuration settings for each environment.
+As a running example, we will use a simple application with a Helm chart. [Helm]({{site.baseurl}}/docs/ci-cd-guides/helm-best-practices/) is the package manager for Kubernetes, and has built-in support for passing different configuration settings for each environment.
-You can find the example Helm application at [https://github.com/codefresh-contrib/helm-promotion-sample-app](https://github.com/codefresh-contrib/helm-promotion-sample-app). If you want to follow along feel free to fork it on your own account.
+You can find the example Helm application at [https://github.com/codefresh-contrib/helm-promotion-sample-app](https://github.com/codefresh-contrib/helm-promotion-sample-app){:target="\_blank"}. If you want to follow along feel free to fork it on your own account.
The application is a web page that prints out its own configuration as loaded from `/config/settings.ini`.
You can run the application locally on your own workstation with:
@@ -46,25 +44,24 @@ docker run -p 8080:8080 my-app
and then visit `http://localhost:8080` in your browser.
-Notice that in this example we use a settings file in the [INI format](https://en.wikipedia.org/wiki/INI_file), but the same things apply with other configuration methods such as env files, Java properties, YAML/JSON configurations etc.
+In this example, we use a settings file in the [INI format](https://en.wikipedia.org/wiki/INI_file){:target="\_blank"}, but the same things apply with other configuration methods such as env files, Java properties, YAML/JSON configurations etc.
### Different environment configurations
-The application includes a [Helm chart](https://github.com/codefresh-contrib/helm-promotion-sample-app/tree/master/chart/sample-app) that contains values for 3 different environments:
+The application includes a [Helm chart](https://github.com/codefresh-contrib/helm-promotion-sample-app/tree/master/chart/sample-app){:target="\_blank"} that contains values for three different environments:
-* [values-qa.yaml](https://github.com/codefresh-contrib/helm-promotion-sample-app/blob/master/chart/values-qa.yaml) for the "QA" environment
-* [values-staging.yaml](https://github.com/codefresh-contrib/helm-promotion-sample-app/blob/master/chart/values-staging.yaml) for the "Staging" environment
-* [values-prod.yaml](https://github.com/codefresh-contrib/helm-promotion-sample-app/blob/master/chart/values-prod.yaml) for the "Production" environment
+* [values-qa.yaml](https://github.com/codefresh-contrib/helm-promotion-sample-app/blob/master/chart/values-qa.yaml){:target="\_blank"} for the "QA" environment
+* [values-staging.yaml](https://github.com/codefresh-contrib/helm-promotion-sample-app/blob/master/chart/values-staging.yaml){:target="\_blank"} for the "Staging" environment
+* [values-prod.yaml](https://github.com/codefresh-contrib/helm-promotion-sample-app/blob/master/chart/values-prod.yaml){:target="\_blank"} for the "Production" environment
-The values contained in the files are both for the application (e.g. payment service URL) as well as the infrastructure level (number of replicas inside the cluster.)
-Note however that the application values are dummy and are not actually used by the application (they are simply shown in the web page). The number of replicas will take real effect on the cluster (the production configuration defines 2 replicas instead of 1).
+The values contained in the files are both for the application (e.g. payment service URL), as well as the infrastructure level (number of replicas inside the cluster).
+Note that the values for the application are dummy values that are not actually used by the application (they are simply shown in the web page). The number of replicas will take real effect on the cluster (the production configuration defines 2 replicas instead of 1).
->Note that for simplicity reasons, the chart of the application is hosted in the same Git repository as the source code. As an alternative you could also
-have a second Git repository with just the chart. Codefresh supports both ways.
+>For simplicity reasons, the chart of the application is hosted in the same Git repository as the source code. As an alternative, you could also have a second Git repository with just the chart. Codefresh supports both ways.
### Manual deployment to different environments
-First let's run the application manually in all 3 environments. Later we will automate the whole process with Codefresh pipelines. We wil create each environment as a namespace in the cluster:
+First let's run the application manually in all three environments. Later we will automate the whole process with Codefresh pipelines. We wil create each environment as a namespace in the cluster:
```
kubectl create namespace qa
@@ -82,7 +79,7 @@ helm install example-staging sample-app -n staging -f values-staging.yaml
helm install example-prod sample-app -n production -f values-prod.yaml
```
-At this point all 3 copies of the application should be up. You might need to wait some time until all the load balancers are up. You can see the running URLs with:
+At this point all three copies of the application should be up. You might need to wait some time until all the load balancers are up. You can see the running URLs with:
```
kubectl get service -A
@@ -99,7 +96,7 @@ caption="Settings per environment"
max-width="50%"
%}
-Note that the application is using a [Load Balancer](https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/) and this means extra costs on your cloud provider. When you are ready to clean up the application run the following:
+Note that the application uses a [Load Balancer](https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/){:target="\_blank"} and this means extra costs on your cloud provider. When you are ready to clean up the application run the following:
```
helm uninstall example-staging -n staging
@@ -107,11 +104,11 @@ helm uninstall example-prod -n production
helm uninstall example-qa -n qa
```
-Note that for this guide all 3 environments are running on the same cluster. In a real application you should use a separate cluster for production and never mix production and non-production workloads. Also notice that the chart refers to the `latest` tag of the application container which is **NOT** a recommended practice. In a real application the chart should specify a specific tag that is versioned.
+Note that for this guide, all three environments run on the same cluster. In a real application, you should use a separate cluster for production, and never mix production and non-production workloads. Also notice that the chart refers to the `latest` tag of the application container which is **NOT** a recommended practice. In a real application the chart should specify a specific tag that is versioned.
## Basic deployment pipeline for different environments
-Now that we have seen how manual deployment works, let's automate the whole process with Codefresh. We [will create a pipeline]({{site.baseurl}}/docs/configure-ci-cd-pipeline/pipelines/) that:
+Now that we have seen how manual deployment works, let's automate the whole process with Codefresh. We will [create a pipeline]({{site.baseurl}}/docs/pipelines/pipelines/) that:
1. Deploys all commits to the `master` branch in the production environment
1. Deploys all other commits to the staging environment
@@ -131,9 +128,9 @@ This is a very simple workflow perfect for small teams that follow Continuous De
The pipeline has the following steps
-1. A [clone step]({{site.baseurl}}/docs/codefresh-yaml/steps/git-clone/) to get the source code plus the Helm chart
-1. A [build step]({{site.baseurl}}/docs/codefresh-yaml/steps/build/) to create and push the container image to Dockerhub
-1. A [Helm step]({{site.baseurl}}/docs/new-helm/using-helm-in-codefresh-pipeline/) to perform the deployment. The step has [pipeline conditionals]({{site.baseurl}}/docs/codefresh-yaml/conditional-execution-of-steps/) to select which environment will be used.
+1. A [clone step]({{site.baseurl}}/docs/pipelines/steps/git-clone/) to get the source code plus the Helm chart
+1. A [build step]({{site.baseurl}}/docs/pipelines/steps/build/) to create and push the container image to Dockerhub
+1. A [Helm step]({{site.baseurl}}/docs/deployments/helm/using-helm-in-codefresh-pipeline/) to perform the deployment. The step has [conditions]({{site.baseurl}}/docs/pipelines/conditional-execution-of-steps/) to select which environment will be used.
Here is the full pipeline:
@@ -206,11 +203,11 @@ steps:
To test the pipeline and see how it behaves with different environments:
-1. Fork [the Git repository](https://github.com/codefresh-contrib/helm-promotion-sample-app) to your own Github account
-1. Commit a dummy change in the `master` branch and you will see a deployment to the production namespace
-1. Commit a dummy change to the `staging` branch or any other branch of your choosing and you will see a deployment to the staging namespace.
+1. Fork the [Git repository](https://github.com/codefresh-contrib/helm-promotion-sample-app){:target="\_blank"} to your own GitHub account
+1. Commit a dummy change in the `master` branch, and you will see a deployment to the production namespace
+1. Commit a dummy change to the `staging` branch or any other branch of your choosing, and you will see a deployment to the staging namespace.
-Here is how the pipeline looks when a commit happens to another branch (that is not `master`)
+Here is how the pipeline looks when a commit happens to a branch that is not `master`:
{% include image.html
lightbox="true"
@@ -225,17 +222,17 @@ As you can see the step that deploys to production is now skipped, and the step
This is a great starting point for your own workflows. Codefresh can handle more complicated scenarios as you will see in the later sections.
->Note that for brevity reasons, the pipeline deploys the Helm chart directly from the Git repo. In a real pipeline you [should also store the Helm chart
-in a Helm repository]({{site.baseurl}}/docs/new-helm/helm-best-practices/#packagepush-and-then-deploy).
+>Note that for brevity reasons, the pipeline deploys the Helm chart directly from the Git repo. In an actual pipeline, you [should also store the Helm chart
+in a Helm repository]({{site.baseurl}}/docs/ci-cd-guides/helm-best-practices/#packagepush-and-then-deploy).
-For more details on Helm deployments see our [dedicated Helm example]({{site.baseurl}}/docs/yaml-examples/examples/helm/).
+For more details on Helm deployments see our [dedicated Helm example]({{site.baseurl}}/docs/example-catalog/cd-examples/helm/).
## Viewing your Helm Releases
-The previous pipeline works great as an automation mechanism. Wouldn't it be great if you could also *see* your deployments in a visual manner?
-Codefresh include a [Helm release dashboard]({{site.baseurl}}/docs/new-helm/helm-releases-management/) that can help you understand better your deployments.
+The previous pipeline works great as an automation mechanism. Wouldn't it be great if you could also *visualize* your deployments?
+Codefresh includes a [Helm release dashboard]({{site.baseurl}}/docs/deployments/helm/helm-releases-management/) to help you understand your deployments.
-You can find the dashboard at [https://g.codefresh.io/helm/releases/releasesNew/](https://g.codefresh.io/helm/releases/releasesNew/).
+1. In the Codefresh UI, from Ops in the sidebar, select [Helm Releases](https://g.codefresh.io/helm/releases/releasesNew/){:target="\_blank"}.
{% include image.html
lightbox="true"
@@ -246,7 +243,8 @@ caption="Helm releases"
max-width="80%"
%}
-By clicking on each release you can get extra information such as the services exposed and active replicas:
+{:start="2"}
+1. To get extra information such as the services exposed and active replicas for a release, click on the release.
{% include image.html
lightbox="true"
@@ -257,7 +255,7 @@ caption="Helm service information"
max-width="80%"
%}
-..the history of deployments (and you can even [rollback]({{site.baseurl}}/docs/new-helm/helm-releases-management/#rolling-back-a-helm-release) to a previous release):
+ In the History tab, you can view the deployment history, and even [rollback]({{site.baseurl}}/docs/deployments/helm/helm-releases-management/#roll-back-a-helm-release) to a previous release:
{% include image.html
lightbox="true"
@@ -268,7 +266,8 @@ caption="Helm deployment history"
max-width="80%"
%}
-and most importantly the values applied for each release.
+ And most importantly in the Values tab, the values applied for each release.
+ This way you can also verify that the correct values are applied to the respective environment.
{% include image.html
lightbox="true"
@@ -280,24 +279,23 @@ max-width="80%"
%}
-This way you can also verify that the correct values are applied to the respective environment.
-## Using the Environment Dashboard
-Codefresh also includes [an optional environment dashboard]({{site.baseurl}}/docs/deploy-to-kubernetes/environment-dashboard/) that you can use to track down your environments and their current status. The dashboard is especially helpful if you have a large number of environments.
+## Using the Environment dashboard
+Codefresh also includes an optional [environment dashboard]({{site.baseurl}}/docs/deployments/kubernetes/environment-dashboard/) that you can use to track down your environments and their current status. The dashboard is especially helpful if you have a large number of environments.
{% include
image.html
lightbox="true"
-file="/images/codefresh-yaml/environments/environments.png"
-url="/images/codefresh-yaml/environments/environments.png"
+file="/images/guides/environments/environments.png"
+url="/images/guides/environments/environments.png"
alt="Codefresh Environment Dashboard"
caption="Codefresh Environment Dashboard"
max-width="70%"
%}
-To activate your environment dashboard you need to add an [env block]({{site.baseurl}}/docs/codefresh-yaml/deployment-environments/) to each of the deployment steps in the pipeline.
+To activate your environment dashboard you need to add an [env block]({{site.baseurl}}/docs/pipelines/deployment-environments/) to each of the deployment steps in the pipeline.
Here is the whole pipeline:
@@ -389,7 +387,7 @@ steps:
{% endhighlight %}
-Notice that we use the `CF_COMMIT_MESSAGE` [variable]({{site.baseurl}}/docs/codefresh-yaml/variables/) to annotate each environment with each build message. After your deploy at least once to each environment you should see the following in your [dashboard](https://g.codefresh.io/environments).
+Notice that we use the `CF_COMMIT_MESSAGE` [variable]({{site.baseurl}}/docs/pipelines/variables/) to annotate each environment with each build message. After you deploy at least once to each environment, you should see the following in the Codefresh UI's [Environment dashboard](https://g.codefresh.io/environments){:target="\_blank"}.
{% include image.html
lightbox="true"
@@ -401,13 +399,13 @@ max-width="80%"
%}
Just by looking at the builds of each environment, it is clear that the staging environment is one commit ahead (for feature 4689).
-If you click on each environment you will see several details such as active services, deployment history, rollback options, manifests rendered etc as in the Helm releases page.
+Clicking an environment shows several details such as active services, deployment history, rollback options, manifests rendered etc as in the Helm releases page.
## Using Approvals in a pipeline
Deploying straight to production after a commit is a worthy goal, but not all organizations want to work like this. In several cases, a human must approve a production deployment with a manual step.
-An alternative pipeline pattern is to have a single pipeline that automatically deploys to the "staging" environment but pauses before releasing in production.
+An alternative pipeline pattern is to have a single pipeline that automatically deploys to the "staging" environment but pauses before releasing to production.
{% include image.html
lightbox="true"
@@ -418,9 +416,9 @@ caption="Asking for approval before a production deployment"
max-width="80%"
%}
-Once the pipeline is paused, all project stakeholders can examine the state of the application in the staging environment (either manually or by running automated tests) and if everything looks good, promote the application to production.
+Once the pipeline is paused, all project stakeholders can examine the state of the application in the staging environment (either manually or by running automated tests), and if everything looks good, promote the application to production.
-This is easily accomplished with the [Codefresh approval step]({{site.baseurl}}/docs/codefresh-yaml/steps/approval/). The pipeline is stopped and a yes/no button is shown in the GUI. Only if the approval choice is selected the pipeline can then continue.
+This is easily accomplished through the [Codefresh approval step]({{site.baseurl}}/docs/pipelines/steps/approval/). The pipeline is stopped, and a yes/no button is shown in the UI. The pipeline can continue only if approved by selecting `yes`.
Here is the whole pipeline:
@@ -492,14 +490,14 @@ The approval step has many more options such as a timeout or even choosing a dif
## Using multiple pipelines for deployments
-Having a single pipeline that deals with all deployment environments can work great with a small team. As an organization grows and the pipeline is getting additional steps, it becomes very hard to use pipeline conditionals to enable/disable specific steps.
+Having a single pipeline that deals with all deployment environments can work great with a small team. As an organization grows, and more steps are added to the pipeline, it becomes very hard to use conditions to enable/disable specific steps in pipelines.
-With Codefresh you can create as many pipelines as you want for a single project. It is therefore very easy to employ different simple pipelines for specific purposes instead of working with a complex monolithic pipeline.
+With Codefresh, you can create as many pipelines as you want for a single project. It is therefore very easy to employ different simple pipelines for specific purposes, instead of working with a complex monolithic pipeline.
In our example we will create two pipelines:
-1. The "staging" pipeline performs linting and security scans in the source code before creating the docker image
-1. The "production" pipeline is running integration tests *after* the creation of the Docker image.
+1. The "staging" pipeline performs linting and security scans in the source code before creating the Docker image
+1. The "production" pipeline runs integration tests *after* the creation of the Docker image
Here is how the staging pipeline looks:
@@ -512,7 +510,7 @@ caption="A pipeline only for staging deployments"
max-width="80%"
%}
-This pipeline uses [parallel steps]({{site.baseurl}}/docs/codefresh-yaml/advanced-workflows/#inserting-parallel-steps-in-a-sequential-pipeline) to run linting and security scanning at the same time.
+This pipeline uses [parallel steps]({{site.baseurl}}/docs/pipelines/advanced-workflows/#inserting-parallel-steps-in-a-sequential-pipeline) to run linting and security scanning at the same time.
Here is the whole pipeline:
@@ -578,7 +576,7 @@ steps:
{% endraw %}
{% endhighlight %}
-The production pipeline assumes that the code is already scanned/validated and runs some integration tests as a final validation check before deploying the release to production:
+The production pipeline assumes that the code has been scanned/validated already, and runs some integration tests as a final validation check before deploying the release to production:
{% include image.html
lightbox="true"
@@ -589,7 +587,7 @@ caption="A pipeline only for production deployments"
max-width="80%"
%}
-This pipeline uses [service containers]({{site.baseurl}}/docs/codefresh-yaml/service-containers/) to run [integration tests]({{site.baseurl}}/docs/testing/integration-tests/).
+This pipeline uses [service containers]({{site.baseurl}}/docs/pipelines/service-containers/) to run [integration tests]({{site.baseurl}}/docs/testing/integration-tests/).
Here is the whole pipeline:
@@ -653,37 +651,36 @@ steps:
{% endraw %}
{% endhighlight %}
-Now that you have created the pipelines, you have several options on how to trigger them. Some common workflows are:
+Now that you have created the pipelines, you have several options on how to trigger them.
+Some common workflows are:
-1. Automate the staging pipeline when a commit lands in `master` and only launch the production pipeline in a manual manner
-1. Automate the staging pipeline when a commit lands in `master` and use an [approval step]({{site.baseurl}}/docs/codefresh-yaml/steps/approval/) to call the production pipeline as a [child pipeline]({{site.baseurl}}/docs/yaml-examples/examples/call-child-pipelines/).
-1. Set the [trigger]({{site.baseurl}}/docs/configure-ci-cd-pipeline/triggers/git-triggers/) of the production pipeline to [launch only]({{site.baseurl}}/docs/ci-cd-guides/pull-request-branches/#restricting-which-branches-to-build) on `master` and the trigger of the staging pipeline to launch only for non-master branches
-1. Set the production pipeline to launch only for commits on `master` and the staging pipeline only for Pull requests.
+1. Automate the staging pipeline when a commit lands in `master`, and only launch the production pipeline manually.
+1. Automate the staging pipeline when a commit lands in `master`, and use an [approval step]({{site.baseurl}}/docs/pipelines/steps/approval/) to call the production pipeline as a [child pipeline]({{site.baseurl}}/docs/example-catalog/ci-examples/call-child-pipelines/).
+1. Set the [trigger]({{site.baseurl}}/docs/pipelines/triggers/git-triggers/) of the production pipeline to [launch only]({{site.baseurl}}/docs/ci-cd-guides/pull-request-branches/#restricting-which-branches-to-build) on `master`, and the trigger of the staging pipeline to launch only for `non-master` branches.
+1. Set the production pipeline to launch only for commits on `master`, and the staging pipeline only for pull requests (PRs).
-The exact mechanism depends on what your team workflow is. For more information see [the guide on branches and pull requests]({{site.baseurl}}/docs/ci-cd-guides/pull-request-branches/) and especially the [trunk based development section]({{site.baseurl}}/docs/ci-cd-guides/pull-request-branches/#trunk-based-development) for a good starting point.
+The exact mechanism depends on the workflow of your team. For more information, see the guide on [Pull Requests and branches]({{site.baseurl}}/docs/ci-cd-guides/pull-request-branches/), and [trunk based development]({{site.baseurl}}/docs/ci-cd-guides/pull-request-branches/#trunk-based-development), as a good starting point.
## Promoting releases between environments
-If you have a large number of environments we also suggest looking at the Helm promotion board provided by Codefresh.
+If you have a large number of environments, we also suggest looking at the Helm promotion board provided by Codefresh.
+For more details, see [Helm promotion board]({{site.baseurl}}/docs/deployments/helm/helm-environment-promotion/).
+
{% include
image.html
lightbox="true"
-file="/images/kubernetes-helm/promotion/board.png"
-url="/images/kubernetes-helm/promotion/board.png"
+file="/images/guides/environments/board.png"
+url="/images/guides/environments/board.png"
alt="Helm Promotion Dashboard"
caption="Helm Promotion Dashboard"
max-width="80%"
%}
-See the [Helm promotion board]({{site.baseurl}}/docs/new-helm/helm-environment-promotion/) documentation page for more details.
-
-## What to read next
-* [Codefresh YAML]({{site.baseurl}}/docs/codefresh-yaml/what-is-the-codefresh-yaml/)
-* [Pull Requests and branches]({{site.baseurl}}/docs/ci-cd-guides/pull-request-branches/)
-* [Environment dashboard]({{site.baseurl}}/docs/deploy-to-kubernetes/environment-dashboard/)
-* [Helm promotions]({{site.baseurl}}/docs/new-helm/helm-environment-promotion/)
+## Related articles
+[Codefresh YAML for pipeline definitions]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/)
+[Environment dashboard]({{site.baseurl}}/docs/deployments/kubernetes/environment-dashboard/)
diff --git a/_docs/ci-cd-guides/gitops-deployments.md b/_docs/ci-cd-guides/gitops-deployments.md
index 7297f54ab..e9c96e864 100644
--- a/_docs/ci-cd-guides/gitops-deployments.md
+++ b/_docs/ci-cd-guides/gitops-deployments.md
@@ -1,68 +1,73 @@
---
-title: "GitOps Deployments"
-description: "Learn how to deploy with Codefresh and ArgoCD"
+title: "GitOps deployments"
+description: "Deploy with Codefresh and ArgoCD"
group: ci-cd-guides
toc: true
---
-Apart from traditional push-based Helm deployments, Codefresh can also be used for [GitOps deployments](https://codefresh.io/gitops/).
+Apart from traditional push-based Helm deployments, you can use Codefresh for [GitOps deployments](https://codefresh.io/gitops/){:target="\_blank"} powered by Argo CD.
+For an overview on GitOps, Argo CD, and how Codefresh implements both, see [Codefresh and GitOps]({{site.baseurl}}docs/getting-started/gitops-codefresh/).
-## What is GitOps
-GitOps is the practice of performing Operations via Git only. The main principles of GitOps are the following:
+Even though GitOps is not specific to Kubernetes, current GitOps tools work great with Kubernetes in the form of cluster controllers. The GitOps controller monitors the state of the Git repository, and when there is a commit, instructs the cluster to match the same state.
-* The state of the system/application is always stored in Git.
-* Git is always the source of truth for what happens in the system.
-* If you want to change the state of the system you need to perform a Git operation such as creating a commit or opening a pull request. Deployments, tests, and rollbacks controlled through git flow.
-* Once the Git state is changed, then the cluster (or whatever your deployment target is) state should match what is described in the Git repository.
-* No hand rolled deployments, no ad-hoc cluster changes, no live configuration changes are allowed. If a change needs to happen, it must be committed to Git first.
-GitOps deployments have several advantages compared to traditional imperative deployments. The main one is that the Git repo represents the state of the system, and Git history
-is essentially the same thing as deployment history. Rollbacks are very easy to perform by simply using a previous Git hash.
+Codefresh has native support for GitOps, from creating GitOps applications, deploying them, and monitoring and managing the deployments with dedicated dashboards optimized for GitOps.
-Even though GitOps is not specific to Kubernetes, current GitOps tools work great with Kubernetes in the form of cluster controllers. The GitOps controller monitors the state of the Git repository and when a commit happens, the cluster is instructed to match the same state.
-
-Codefresh has native support for GitOps including a graphical dashboard for handling your GitOps deployments:
{% include image.html
lightbox="true"
- file="/images/guides/gitops/gitops-dashboard.png"
- url="/images/guides/gitops/gitops-dashboard.png"
- alt="The GitOps dashboard"
- caption="The GitOps dashboard"
- max-width="100%"
+ file="/images/guides/gitops/app-dashboard.png"
+ url="/images/guides/gitops/app-dashboard.png"
+ alt="GitOps Apps dashboard"
+ caption="GitOps Apps dashboard"
+ max-width="60%"
%}
-This guide will explain how you can use GitOps for your own applications.
+Starting with pointers on setting up Git repos, this guide takes you through the process of a GitOps deployment in Codefresh:
+* Connecting Argo CD and Codefresh
+* Creating a CI pipeline for GitOps
+* Creating an Argo CD application for GitOps
+* Deploying the application
+* Working with the GitOps Apps dashboard, and a look at the insights from the GitOps Overview and DORA dashboards
-## Setting up your Git Repositories
-One of the central ideas around GitOps is the usage of Git for ALL project resources. Even though developers are familiar with using Git for the source code of the application, adopting GitOps means that you need to store in Git every other resource of the application (and not just the source code).
-In the case of Kubernetes, this means that all Kubernetes manifests should be stored in a Git repository as well. In the most simple scenario you have the main repository of your application (this is mostly interesting to developers) and [a second Git repository with Kubernetes manifests](https://argoproj.github.io/argo-cd/user-guide/best_practices/#separating-config-vs-source-code-repositories) (this is more relevant to operators/SREs).
+## Setting up your Git repositories
-As a running example you can use:
+One of the central ideas of GitOps is to use Git for _ALL_ project resources. Meaning that you need to store every resource of the application in Git, and not just the source code as most developers using Git are familiar with.
-* The [https://github.com/codefresh-contrib/gitops-app-source-code](https://github.com/codefresh-contrib/gitops-app-source-code) repository for the application code
-* The [https://github.com/codefresh-contrib/gitops-kubernetes-configuration](https://github.com/codefresh-contrib/gitops-kubernetes-configuration) repository for the Kubernetes configuration
-* The [https://github.com/codefresh-contrib/gitops-pipelines](https://github.com/codefresh-contrib/gitops-pipelines) repository that holds the pipelines
+In the case of Kubernetes, this means that you should store all Kubernetes manifests in a Git repository as well. With the most simple scenario, you have the main repository of your application (mostly interesting to developers), and [a second Git repository with Kubernetes manifests](https://argoproj.github.io/argo-cd/user-guide/best_practices/#separating-config-vs-source-code-repositories){:target="\_blank"} (more relevant to operators/SREs).
-The application code repository contains the source code plus a dockerfile. You can use any Git workflow for this repository. We will set a pipeline in Codefresh that creates a container image on each commit.
+As a live example you can use:
-The configuration repository holds the kubernetes manifests. This is one of the critical points of GitOps
+* The [https://github.com/codefresh-contrib/gitops-app-source-code](https://github.com/codefresh-contrib/gitops-app-source-code){:target="\_blank"} repository for the application code.
+ The repository with the application code contains the source code plus a Dockerfile. You can use any Git workflow for this repository. We will create a pipeline in Codefresh that creates a container image on each commit.
-* The configuration repository holds the manifests that are also present in the Kubernetes cluster
-* Every time a commit happens to the configuration repository the cluster will be notified to deploy the new version of the files (we will setup a pipeline for this)
-* Every subsequent configuration change should become a Git commit. Ad-hoc changes to the cluster (i.e. with `kubectl` commands) are **NOT** allowed
+* The [https://github.com/codefresh-contrib/gitops-kubernetes-configuration](https://github.com/codefresh-contrib/gitops-kubernetes-configuration){:target="\_blank"} repository for the Kubernetes configuration.
+ The configuration repository holds the kubernetes manifests. This is one of the critical points of GitOps:
+ * The configuration repository holds the manifests that are also present in the Kubernetes cluster
+ * Whenever there is a commit to the configuration repository, the cluster is notified to deploy the new version of the files (we will set up a pipeline for this)
+ * Every subsequent configuration change should become a Git commit. Ad-hoc changes to the cluster with `kubectl` commands are **NOT** allowed
-We also have a third Git repository for pipelines, because pipelines are also part of the application.
+* The [https://github.com/codefresh-contrib/gitops-pipelines](https://github.com/codefresh-contrib/gitops-pipelines){:target="\_blank"} repository that holds the pipelines.
+ The third Git repository house pipelines because pipelines are also part of the application.
-Before continuing fork all 3 repositories in your own GitHub account if don't have already your own example application.
+**Fork repositories**
+
+* Before continuing, if don't have already your own example application, fork all three repositories into your own GitHub account.
## Connecting ArgoCD and Codefresh
-GitOps deployments are powered by [ArgoCD](https://argoproj.github.io/argo-cd/) so you need an active ArgoCD installation in your cluster to take advantage of the GitOps dashboard in Codefresh.
+GitOps deployments are powered by [ArgoCD](https://argoproj.github.io/argo-cd/){:target="\_blank"}, so you need an active ArgoCD installation in your cluster.
+
+This is easy with our GitOps Runtimes. Argo CD is installed automatically when you install a GitOps runtime, either the Hosted or Hybrid versions. See:
+[Hosted GitOps runtime]({{site.baseurl}}/docs/installation/gitops/hosted-runtime/)
+[Hybrid GitOps runtime]({{site.baseurl}}/docs/installation/gitops/hybrid-gitops/)
+If you don't have a runtime installed already, for this guide, install the Hosted GitOps runtime.
+
+
-For a sample application you can use the [https://github.com/codefresh-contrib/gitops-kubernetes-configuration](https://github.com/codefresh-contrib/gitops-kubernetes-configuration) repository. Fork the project in your own GitHub account and use that link in the *Source repository* section.
+## Creating a CI Pipeline for GitOps
-Once you connect your application you will see it under in the GitOps application screen in the Codefresh UI.
+Creating a CI pipeline for GitOps is no different from creating a standard pipeline. The only difference is that as the final action for the pipeline, you should add the report image action provided by Codefresh. The report image action correlates the Docker image with the Git repository details, Jira issues associated with it, and additional information from the registry that stores the image.
-## Creating a basic CI Pipeline for GitOps
+Follow these steps to create a CI pipeline for GitOps:
-Creating a CI pipeline for GitOps is no different than a [standard pipeline]({{site.baseurl}}/docs/configure-ci-cd-pipeline/pipelines/) that [packages your Docker images]({{site.baseurl}}/docs/ci-cd-guides/building-docker-images/), runs [tests]({{site.baseurl}}/docs/testing/unit-tests/), performs [security scans]({{site.baseurl}}/docs/testing/security-scanning/) etc.
-
- {% include image.html
- lightbox="true"
- file="/images/guides/gitops/basic-ci-pipeline.png"
- url="/images/guides/gitops/basic-ci-pipeline.png"
- alt="Basic CI pipeline"
- caption="Basic CI pipeline"
- max-width="100%"
- %}
+1. Set up Jira, and registry integrations for GitOps
+ You need to connect Jira and your container registry to Codefresh. These integrations are specific to GitOps, and differ from the pipeline integrations that you may have already set up.
+ Once you set up the GitOps integrations, you can reference them in the CI pipeline's report image step for Codefresh to retrieve the necessary information.
+1. Set up Codefresh pipeline integration for GitOps
+1. Create your Codefresh pipeline as you usually do:
+ 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 Codefresh report image
+1. When the pipeline completes execution, Codefresh retrieves the information on the image that was built and its metadata through the integration names specified.
+1. View the image in Codefresh’s Images dashboard, and in any application in which it is used.
-To take advantage of the GitOps dashboard facilities you also need to setup the correlation between the Docker image and the Pull Requests/issues associated with it. This correlation happens via [annotations]({{site.baseurl}}/docs/codefresh-yaml/annotations/). The easiest way to annotate your image is by using the [pipeline plugins](https://codefresh.io/steps/) offered by Codefresh for this purpose. Currently we offer the following plugins:
+### Example CI pipeline for GitOps
-* [Record Pull Request information](https://codefresh.io/steps/step/image-enricher)
-* [Record Jira Issue information](https://codefresh.io/steps/step/jira-issue-extractor)
+Below is an example of a CI pipeline for GitOps.
-Here is an example Pipeline definition:
+The pipeline:
+* [Packages your Docker images]({{site.baseurl}}/docs/ci-cd-guides/building-docker-images/)
+* Runs [tests]({{site.baseurl}}/docs/testing/unit-tests/)
+* Performs [security scans]({{site.baseurl}}/docs/testing/security-scanning/)
+* Reports image information to Codefresh
`codefresh.yml`
{% highlight yaml %}
{% raw %}
+
version: "1.0"
stages:
- "clone"
- "build"
- - "metadata"
+ - "report"
steps:
clone:
title: "Cloning repository"
type: "git-clone"
- repo: "my-github-username/gitops-app-source-code"
- revision: '${{CF_REVISION}}'
+ repo: "${{CF_REPO_OWNER}}/${{CF_REPO_NAME}}"
+ revision: "${{CF_BRANCH}}"
stage: "clone"
+
build:
title: "Building Docker image"
type: "build"
- image_name: "kostiscodefresh/simple-web-app"
+ image_name: "${{CF_REPO_OWNER}}/color"
working_directory: "${{clone}}"
- tags:
- - "latest"
- - '${{CF_SHORT_REVISION}}'
+ tag: "${{CF_SHORT_REVISION}}"
dockerfile: "Dockerfile"
+ registry: docker-lr
stage: "build"
- registry: dockerhub
- enrich-image:
- title: Add PR info
- type: image-enricher
- stage: "metadata"
- arguments:
- IMAGE: docker.io/kostiscodefresh/simple-web-app:latest
- BRANCH: '${{CF_BRANCH}}'
- REPO: 'kostis-codefresh/simple-web-app'
- GIT_PROVIDER_NAME: github-1
- jira-issue-extractor:
- title: Enrich image with jira issues
- type: jira-issue-extractor
- stage: "metadata"
- fail_fast: false
+
+ ReportImageMetadataAll:
+ title: Report image to Codefresh CD
+ type: codefresh-report-image
+ working_directory: /code
+ stage: "report"
arguments:
- IMAGE: docker.io/kostiscodefresh/simple-web-app:latest
- JIRA_PROJECT_PREFIX: 'SAAS'
- MESSAGE: SAAS-8431
- JIRA_HOST: codefresh-io.atlassian.net
- JIRA_EMAIL: kostis@codefresh.io
- JIRA_API_TOKEN: '${{JIRA_TOKEN}}'
+ CF_API_KEY: '${{CF_API_KEY}}'
+ CF_IMAGE: 'docker.io/${{CF_REPO_OWNER}}/color:${{CF_SHORT_REVISION}}'
+ CF_CONTAINER_REGISTRY_INTEGRATION: docker
+ CF_RUNTIME_NAME: "codefresh-hosted"
+ CF_GITHUB_TOKEN: '${{GITHUB_TOKEN}}'
+ CF_GIT_PROVIDER: github
+ CF_GIT_REPO: '${{CF_REPO_OWNER}}/${{CF_REPO_NAME}}'
+ CF_GIT_BRANCH: '${{CF_BRANCH}}'
+ CF_ISSUE_TRACKING_INTEGRATION: jira
+ CF_JIRA_MESSAGE: "${{CF_COMMIT_MESSAGE}}"
+ CF_JIRA_PROJECT_PREFIX: CR
+
{% endraw %}
-{% endhighlight %}
+{% endhighlight yaml %}
-This pipeline:
-1. Checks out the source code of an application with the [git-clone step]({{site.baseurl}}/docs/codefresh-yaml/steps/git-clone/)
-1. [Builds]({{site.baseurl}}/docs/codefresh-yaml/steps/build/) a docker image
-1. Annotates the Docker image with the Pull Request information provided by Github
-1. Annotates the Docker image with a specific Jira issue ticket
+Pipeline steps:
+1. [git-clone step]({{site.baseurl}}/docs/pipelines/steps/git-clone/): Checks out the source code of an application
+1. [Build step]({{site.baseurl}}/docs/pipelines/steps/build/): Builds a Docker image
+1. `codefresh-report-image`: Reports the Jira and registry information to Codefresh. Populates the values of the Codefresh Git variables whose from those you defined in the respec
-You can see the associated metadata in your [Docker image dashboard](https://g.codefresh.io/images/)
+
+You can see the associated metadata in the [Images dashboard](https://g.codefresh.io/images/){:target="\_blank"}.
{% include image.html
lightbox="true"
@@ -181,412 +175,302 @@ You can see the associated metadata in your [Docker image dashboard](https://g.c
max-width="80%"
%}
-Codefresh is using this information to fill the deployment history in the GitOps dashboard.
+Codefresh uses information to fill the deployment history in the GitOps dashboard.
-## Creating a basic CD Pipeline for GitOps
-To create a CD pipeline in Codefresh that is responsible for GitOps deployments you must first disable the auto-sync behavior of ArgoCD. You can disable auto-sync either from the GUI or via the [command line](https://argoproj.github.io/argo-cd/user-guide/auto_sync/):
- {% include image.html
- lightbox="true"
- file="/images/guides/gitops/disable-auto-sync.png"
- url="/images/guides/gitops/disable-auto-sync.png"
- alt="Basic CD pipeline"
- caption="Basic CD pipeline"
- max-width="80%"
- %}
+### Set up Jira and Docker Hub integrations for GitOps image enrichment
+GitOps integration for Atlassian Jira allows you to both enrich images with information from Jira, and report the deployment information back to Jira. For this guide, you need to select the image enrichment option.
+
+Codefresh GitOps can integrate with popular container registries such as Docker Hub, JFrog Artifactory, and more. See [GitOps container registry integrations]({{site.baseurl}}/docs/gitops-integrations/container-registries/).
+For this guide, we'll connect Docker Hub to Codefresh as the container registry for GitOps.
+
+1. In the Codefresh UI, on the toolbar, click the **Settings** icon.
+1. From Configuration in the sidebar, select **GitOps Integrations**.
+1. For Jira:
+ * Filter by **Issue Tracking**, select **Atlassian Jira** and click **Configure**.
+ * From the **Add Integration** dropdown, select **Image enrichment**.
+ * Define the [integration settings for Jira]({{site.baseurl}}/docs/gitops-integrations/issue-tracking/jira/#jira-gitops-integration-settings-in-codefresh).
+ The **Integration name** must be unique.
+1. For Docker Hub:
+ * Complete the [prerequisites]({{site.baseurl}}/docs/gitops-integrations/container-registries/dockerhub/#prerequisites)
+ * Filter by **Container Registry**, select **Docker Hub**, and click **Configure**.
+ * Define the [integration settings for Docker Hub]({{site.baseurl}}/docs/docs/gitops-integrations/container-registries/dockerhub/#docker-hub-gitops-integration-settings-in-codefresh).
- With the auto-sync behavior disabled, all Git pushes that happen on the GitOps repo will be ignored by ArgoCD (however ArgoCD will still mark your application as out-of-sync).
- You can now [create a new pipeline]({{site.baseurl}}/docs/configure-ci-cd-pipeline/pipelines/) in Codefresh using a [standard Git trigger]({{site.baseurl}}/docs/configure-ci-cd-pipeline/triggers/git-triggers/) that will monitor the GitOps repository for updates. This way Codefresh is responsible for the GitOps process instead of Argo.
+Don't forget to click **Commit**. It may take a few moments for the new integration to be synced to the cluster before it appears in the list of **Active** integrations.
+
{% include image.html
lightbox="true"
- file="/images/guides/gitops/argo-sync-pipeline.png"
- url="/images/guides/gitops/argo-sync-pipeline.png"
- alt="Basic CD pipeline"
- caption="Basic CD pipeline"
- max-width="80%"
+ file="/images/guides/gitops/gitops-deploy-active-integrations.png"
+ url="/images/guides/gitops/gitops-deploy-active-integrations.png"
+ alt="Active Jira and DockerHub integrations for GitOps"
+ caption="Active Jira and DockerHub integrations for GitOps"
+ max-width="60%"
%}
-The big advantage here is that you can construct a full pipeline over the sync process with multiple steps before or after the sync. For example you could run some smoke tests after the deployment takes place. Here is an example pipeline:
+### Set up Codefresh pipeline integration for GitOps
+After completing the Jira and Docker Hub integrations, we can set up the pipeline integration for GitOps.
+Why would you do this? When you create the CI pipeline as you usually do, you'll see that the final report image step references several Codefresh variables to report image information to Codefresh and enrich the image.
- `codefresh.yml`
-{% highlight yaml %}
-{% raw %}
-version: "1.0"
-stages:
- - "pre sync"
- - "sync app"
- - "post sync"
+Read more in [GitOps CI integrations]({{site.baseurl}}/docs/gitops-integrations/ci-integrations/), and make sure to also review [Templatization examples for CF arguments]({{site.baseurl}}/docs/gitops-integrations/ci-integrations/codefresh-classic/#templatization-examples-for-cf-arguments).
-steps:
- pre_sync:
- title: "Pre sync commands"
- type: "freestyle" # Run any command
- image: "alpine:3.9" # The image in which command will be executed
- commands:
- - echo "Sending a metrics marker"
- stage: "pre sync"
- sync_and_wait:
- title: Sync ArgoCD app and wait
- type: argocd-sync
- arguments:
- context: "argo-cd"
- app_name: "${{ARGOCD_APP_NAME}}"
- wait_healthy: true
- stage: "sync app"
- post_sync:
- title: "Post sync commands"
- type: "freestyle" # Run any command
- image: "alpine:3.9" # The image in which command will be executed
- commands:
- - echo "running smoke tests"
- stage: "post sync"
-{% endraw %}
-{% endhighlight %}
-The pipeline is using the [argo-sync plugin](https://codefresh.io/steps/step/argocd-sync) that can be used by Codefresh to start the sync process of an application from the Git repo to the cluster.
+1. In the Codefresh UI, on the toolbar, click the **Settings** icon.
+1. From Configuration in the sidebar, select **GitOps Integrations**.
+1. Filter by **CI tools**, select **Codefresh** and click **Add**.
+1. Define the i[ntegration settings for Codefresh pipelines]({{site.baseurl}}/docs/docs/gitops-integrations/codefresh-classic/#ci-pipeline-gitops-integration-settings).
-The name of the `context` parameter should be the same name you used for your [ArgoCD integration]({{site.baseurl}}/docs/integrations/argocd/).
- {% include image.html
- lightbox="true"
- file="/images/guides/gitops/argo-context.png"
- url="/images/guides/gitops/argo-context.png"
- alt="Using the Argo integration name as a context"
- caption="Using the Argo integration name as a context"
- max-width="80%"
- %}
-The name of the application should be the same name as the ArgoCD Application.
- {% include image.html
- lightbox="true"
- file="/images/guides/gitops/argo-application-name.png"
- url="/images/guides/gitops/argo-application-name.png"
- alt="Argo Application name"
- caption="Argo Application name"
- max-width="80%"
- %}
- You can use pipeline variables or any other familiar Codefresh mechanism such as [shared configuration]({{site.baseurl}}/docs/configure-ci-cd-pipeline/shared-configuration/).
+## Creating an Argo CD application for GitOps
- Once the pipeline has finished running the sync status will updated in your GitOps dashboard to reflect the current state.
+Codefresh provides an easy-to-use editor to create GitOps-compatible applications.
-## Working with the GitOps Dashboard
+* In the Codefresh UI, from Ops in the sidebar, select [**GitOps Apps**](https://g.codefresh.io/2.0/applications-dashboard/list){:target="\_blank"}.
+* Click **New Application** on the top-right.
-After you create an ArgoCD application, you can click on it in the [GitOps environment overview](https://g.codefresh.io/gitops) and see the respective GitOps screen.
-{% include image.html
- lightbox="true"
- file="/images/guides/gitops/real-dashboard.png"
- url="/images/guides/gitops/real-dashboard.png"
- alt="GitOps Dashboard"
- caption="GitOps Dashboard"
- max-width="100%"
- %}
+A GitOps application includes:
-This dashboard is the central place for monitoring your application and contains the following information:
+* Application definitions
+ Application definitions include the name, runtime, and the location of the YAML manifest. You can define subfolders by adding / to the path.
-1. Current health and sync status
-1. Deployment graph that shows successful/failed deployments on the selected time period
-1. Complete history of deployments according to Git hash. For each deployment you can also see which Pull Request was used for the commit, who was the committer and which JIRA issues this Pull request is solving (provided that the image was built by a Codefresh pipeline)
-1. The Kubernetes services that belong to this application (on the services tab)
-1. What services and replicas were updated with each deployment.
+* General configuration settings
+ General configuration settings define the source, destination, and sync policies for the application. These options are identical to those in the Argo CD UI. We recommend selecting automated sync for your application.
-The deployment status is fetched from your ArgoCD integration in a live manner. If, at any point, the deployment is not synced with GIT, you will instantly see the out-of-sync status. You will get the number of resources that are out of sync. When you click the out-of-sync status, you will get a list of all resources in that status.
+* Advanced configuration settings
+ Advanced settings define the tool used to create the application, and related tool-specific settings.
-{% include image.html
- lightbox="true"
- file="/images/guides/gitops/out-of-sync.png"
- url="/images/guides/gitops/out-of-sync.png"
- alt="Out of sync status"
- caption="Out of sync status"
- max-width="60%"
- %}
-For each Git hash Codefresh associates the respective Pull Request and Jira issue(s) that affected deployment. To achieve this correlation, Codefresh is enriching the Docker image(s) of the service during the CI process.
-You can manually create these annotations with the [standard Codefresh annotation support]({{site.baseurl}}/docs/codefresh-yaml/annotations/) or via the built-in pipeline steps that we will see in the next section.
+When creating the application, you can use the Form mode or the YAML editor, and toggle between the two. For detailed information on the settings and options, see [Creating GitOps applications]({{site.baseurl}}/docs/deployments/gitops/create-application/).
-You can find helpful tips if you hover your mouse on the PR number, the issue, the Git commiter and so on.
+On selecting **Commit**, Codefresh validates the settings, and alerts you to empty or invalid fields.
+Once validated, you can see the Commit form with the application's definition on the left, and the read-only version of the manifest with the configuration settings you defined on the right.
+Enter the path to the **Git Source** to which to commit the application configuration manifest.
-{% include image.html
- lightbox="true"
- file="/images/guides/gitops/tooltips.png"
- url="/images/guides/gitops/tooltips.png"
- alt="Extra tooltip information"
- caption="Extra tooltip information"
- max-width="80%"
- %}
+It may take a few minutes to until it is synced to the cluster.
-For each deployment you can also see a before/after view of the pods/replicas that were affected.
+## Deploy the GitOps application
+The next step after creating the GitOps application is to deploy it. To deploy the GitOps application you created, you need to create and commit the following resources:
+* A folder in Git to save resources for the application
+* `Rollout` resource defining the deployment strategy
+* `Service` resource to expose the application to external traffic
-{% include image.html
- lightbox="true"
- file="/images/guides/gitops/updated-services.png"
- url="/images/guides/gitops/updated-services.png"
- alt="Updated services"
- caption="Updated services"
- max-width="100%"
- %}
+You will also need to [install Argo Rollouts]({{site.baseurl}}/docs/deployments/gitops/install-argo-rollouts) on the cluster to which you are deploying the application.
-### Filtering the Deployment History
+### Create rollout.yaml
-You can add filters on the deployment history by using the multi-select field on the top left of the screen.
+Create a `rollout` resource for the application you want to deploy.
-{% include image.html
- lightbox="true"
- file="/images/guides/gitops/filter.png"
- url="/images/guides/gitops/filter.png"
- alt="Filtering options"
- caption="Filtering options"
- max-width="40%"
- %}
+To leverage Argo Rollouts' deployment capabilities, we use 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"}.
- You can add filters for:
+* In the Git repository create the `rollout.yaml` file, as in the example below.
-* Git committer(s)
-* Pull Request number(s)
-* Jira issue(s)
- If you define multiple options they work in an OR manner.
+```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}
+```
-### Searching the Deployment History
+### Create a service resource
+Create a service resource to expose your application to external traffic.
-For advanced filtering options, the search field on the top right allows you to view only the subset of deployments that match your custom criteria.
+* 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`.
-Apart from direct text search, the text field also supports a simple query language with the following keywords:
+```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
+```
+Once you create and commit the `rollout` and `service` resources, return to the GitOps Apps dashboard. See the following section, [Working with the GitOps Apps dashboard](#working-with-the-gitops-app-dashboard) for detailed information on all aspects of monitoring your app and deployments.
-* `issues`
-* `issue`
-* `prs`
-* `pr`
-* `committer`
-* `committers`
-* `service`
-* `services`
-* `image`
-* `images`
-* `status`
-* `statuses`
+## Working with the GitOps Apps dashboard
-The following characters serve as delimiters
+After you create an ArgoCD application in Codefresh, you can track and monitor the application's deployments, resources, and more in the [GitOps Apps](https://g.codefresh.io/2.0/applications-dashboard/list){:target="\_blank"} dashboard.
-* `:` define the value for a keyword
-* `,` define multiple values for a single keyword
-* `;` define multiple criteria
{% include image.html
lightbox="true"
- file="/images/guides/gitops/search.png"
- url="/images/guides/gitops/search.png"
- alt="Searching deployment history"
- caption="Searching deployment history"
+ file="/images/guides/gitops/app-dashboard.png"
+ url="/images/guides/gitops/app-dashboard.png"
+ alt="GitOps Apps dashboard"
+ caption="GitOps Apps dashboard"
max-width="80%"
- %}
+ %}
+
+Let's review the important features
+
+### Customize the dashboard view
+
+ * View format: Select the view format for the GitOps Apps dashboard as List or Card.
-Some examples are:
+ * Filters: Customize the scope through the global filters to display the information you need.
-* `pr:2` - filter the deployment history to show only a specific Pull request
-* `issues: SAAS-2111, SAAS-2222` - show only specific issues
-* `issue: SAAS-2111; pr:3 ; service: my-app` - searching for multiple criteria in OR behavior
+ * Detailed info on application: To get detailed information on an application, either select the option/action from the app's context menu, or simply click the application.
-Using the search field allows you to quickly find a specific Git commit in the history of the application (and even rollback the deployment as explained in the next sections).
+For more information, see [Applications dashboard information]({{site.baseurl}}/docs/deployments/gitops/applications-dashboard/#applications-dashboard-information).
-## Current State of Application
-The current state tab shows a hierarchical view of your cluster resource for your application.
+### Application header
+When you select an application, the application header displayed at the top provides a wealth of useful information at a glance.
{% include image.html
lightbox="true"
- file="/images/guides/gitops/currentstate.png"
- url="/images/guides/gitops/currentstate.png"
- alt="Current State tab"
- caption="Current State tab"
- max-width="80%"
+ file="/images/guides/gitops/application-header.png"
+ url="/images/guides/gitops/application-header.png"
+ alt="GitOps Apps: Application header"
+ caption="GitOps Apps: Application header"
+ max-width="100%"
%}
-At the top of the screen you have several filters available:
+Here you can see:
+* Application health status
+* Current sync status and previous sync result
+* Auto-Sync as enabled or disabled
-* Kind - choose a specific type of Kubernetes resource
-* Health - status of the resource
-* Sync state - GitOps status of the resource
-* Free search - search any resource by name
-## Tagging GitOps Application
+### Monitor application resources in Current State
-1. Navigate to the GitOps dashboard.
-2. To the application's right (next to the Health Column), click the three dots to open the More Action Dropdown.
-3. Select Add/Edit Tags.
-4. Click the +tags to add tags.
-5. Alternatively, click the "x" next to the tag to remove it.
-6. Click Save.
+Monitor the resources deployed in the current version of the selected application in the Current State tab.
+This is the tab displayed when you select the application from the GitOps Apps dashboard.
-## Rolling Back Git Versions
-In the GitOps dashboard you will also see a complete history of all past deployments as recorded in Git. You can select any of the previous versions and rollback your application to the respective version.
+{% include
+image.html
+lightbox="true"
+file="/images/guides/gitops/app-current-state.png"
+url="/images/guides/gitops/app-current-state.png"
+alt="Application resources in Current State tab"
+caption="Application resources in Current State tab"
+max-width="50%"
+%}
- {% include image.html
- lightbox="true"
- file="/images/guides/gitops/rollback.png"
- url="/images/guides/gitops/rollback.png"
- alt="Rolling back to a previous version"
- caption="Rolling back to a previous version"
- max-width="80%"
- %}
+Here you can view the live state of the application's resources (Kubernetes objects) on the cluster in List or Tree views, set filters, and monitor for each resource:
+* Health status
+* Sync status
+* Manifests
+* Logs
+* Events
+
+>To quickly filter by resource type, click the type in the Resource Inventory (bottom-left).
-The Rollback simply informs the cluster to use a different git hash for the sync process. It doesn't affect your Git repository and ArgoCD will now show your application as out-of-sync (because the last Git commit no longer matches the status of the cluster).
+For detailed information, see [Monitor resources for selected application]({{site.baseurl}}/docs/deployments/gitops/applications-dashboard/#monitor-resources-for-selected-application).
-This rollback behavior is best used as an emergency measure after a failed deployment where you want to bring the cluster back to a previous state in a temporary manner. If you wish to keep the current rollback status as a permanent status it is best to use the standard `git reset/revert` commands and change the GitOps repository to its desired state.
-## Gitops ABAC Support For Rollback Action
+### Monitor deployments in Timeline
+The Timeline tab (next to the Current State), displays the history of deployments for the selected application. Here's where to monitor an ongoing deployment and review historical deployments. The deployments are sorted by the most recent one, labeled Current Version at the top.
-1. Go to Account Settings > Permissions > Teams Tab > Gitops.
-2. Select the Team.
-3. Chose what the Team can do and click apply.
-4. Select the tags of the applications and click apply.
-5. Click Add Rule when done.
+To view day-to-day deployment information for the selected time period, mouse over the dot on the deployment chart
-## Performing Automatic Git Commits
+{% include
+image.html
+lightbox="true"
+file="/images/guides/gitops/app-timeline.png"
+url="/images/guides/gitops/app-timeline.png"
+alt="Application deployments in Timeline tab"
+caption="Application deployments in Timeline tab"
+max-width="50%"
+%}
-Usually the Pull Requests that take part in a GitOps workflow are created and approved in a manual way (after code review). You have the option however to fully automate the whole process and rather than opening a Pull Request on both the application repository and the manifest repository, commit automatically the manifest changes inside the pipeline that creates the artifact.
+You can see the:
+1. Complete history of deployments according to Git hash. For each deployment you can also the Pull Request (PR) used for the commit, the committer, and the Jira issues resolved by the PR
+1. The Kubernetes services added or modified during the deployment
-{% include image.html
- lightbox="true"
- file="/images/guides/gitops/gitops-workflow.png"
- url="/images/guides/gitops/gitops-workflow.png"
- alt="Full GitOps workflow"
- caption="Full GitOps workflow"
- max-width="100%"
- %}
-Here is an example pipeline that creates a Docker image and also commits a version change in the Kubernetes manifest to denote the new Docker tag of the application:
+
-{% include image.html
- lightbox="true"
- file="/images/guides/gitops/ci-cd-pipeline.png"
- url="/images/guides/gitops/ci-cd-pipeline.png"
- alt="Pipeline that commits manifests"
- caption="Pipeline that commits manifests"
- max-width="80%"
- %}
-There are many ways to change a Kubernetes manifest in a programmatic way, and for brevity reasons we use the [yq](https://github.com/mikefarah/yq) command line tool.
- `codefresh.yml`
-{% highlight yaml %}
-{% raw %}
-version: "1.0"
-stages:
- - "clone"
- - "build"
- - "metadata"
- - "gitops"
+### Review and update application Configuration
+The Configuration tab displays the definitions for the application. Apart from the application name and runtime, you can change any setting, and commit the changes.
-steps:
- clone:
- title: "Cloning repository"
- type: "git-clone"
- repo: "my-github-username//gitops-app-source-code"
- revision: '${{CF_REVISION}}'
- stage: "clone"
+For more information on application definitions, see [Creating GitOps applications]({{site.baseurl}}/docs/deployments/gitops/create-application).
- build:
- title: "Building Docker image"
- type: "build"
- image_name: "kostiscodefresh/simple-web-app"
- working_directory: "${{clone}}"
- tags:
- - "latest"
- - '${{CF_SHORT_REVISION}}'
- dockerfile: "Dockerfile"
- stage: "build"
- registry: dockerhub
- enrich-image:
- title: Add PR info
- type: image-enricher
- stage: "metadata"
- arguments:
- IMAGE: docker.io/kostiscodefresh/simple-web-app:${{CF_SHORT_REVISION}}
- BRANCH: '${{CF_BRANCH}}'
- REPO: 'kostis-codefresh/simple-web-app'
- GIT_PROVIDER_NAME: github-1
- jira-issue-extractor:
- title: Enrich image with jira issues
- type: jira-issue-extractor
- stage: "metadata"
- fail_fast: false
- arguments:
- IMAGE: docker.io/kostiscodefresh/simple-web-app:${{CF_SHORT_REVISION}}
- JIRA_PROJECT_PREFIX: 'SAAS'
- MESSAGE: SAAS-8842
- JIRA_HOST: codefresh-io.atlassian.net
- JIRA_EMAIL: kostis@codefresh.io
- JIRA_API_TOKEN: '${{JIRA_TOKEN}}'
- clone_gitops:
- title: cloning gitops repo
- type: git-clone
- arguments:
- repo: 'my-github-username//gitops-kubernetes-configuration'
- revision: 'master'
- stage: "gitops"
- when:
- branch:
- only:
- - master
- change_manifest:
- title: "Update k8s manifest"
- image: "mikefarah/yq:3" # The image in which command will be executed
- commands:
- - yq w -i deployment.yml spec.template.spec.containers[0].image docker.io/kostiscodefresh/simple-web-app:${{CF_SHORT_REVISION}}
- - cat deployment.yml
- working_directory: "${{clone_gitops}}"
- stage: "gitops"
- when:
- branch:
- only:
- - master
- commit_and_push:
- title: Commit manifest
- type: git-commit
- stage: "gitops"
- arguments:
- repo: 'my-github-username//gitops-kubernetes-configuration'
- git: github-1
- working_directory: '/codefresh/volume/gitops-kubernetes-configuration'
- commit_message: Updated manifest
- git_user_name: ${{CF_COMMIT_AUTHOR}}
- git_user_email: ${{CF_COMMIT_AUTHOR}}@acme-inc.com
- when:
- branch:
- only:
- - master
-{% endraw %}
-{% endhighlight %}
+## GitOps Overview and DORA dashboards
-This pipeline:
+If you have several applications and deployments, the GitOps Overview and the DORA metrics dashboards are particularly useful, to managers and developers alike.
-1. Checks out the Git repository that contains the source code
-1. Builds a Docker image and tags it with the Git hash
-1. Enriches the image with the Pull request and ticket information as explained in the previous sections
-1. Checks out the Git repository that contains the Kubernetes manifests
-1. Performs a text replacement on the manifest updating the `containers` segment with the new Docker image
-1. Commits the change back using the [Git commit plugin](https://codefresh.io/steps/step/git-commit) to the Git repository that contains the manifests.
+The GitOps Overview offers a global view of runtimes, managed clusters, and deployments. For system-wide visualization in real-time, this is your dashboard of choice in Codefresh.
+Go to [GitOps Overview](https://g.codefresh.io/2.0/?time=LAST_7_DAYS){:target="\_blank"}.
+For information on the GitOps Overview dashboard, see [GitOps Overview dashboard]({{site.baseurl}}/docs/dashboards/home-dashboard).
+
+{% include
+image.html
+lightbox="true"
+file="/images/guides/gitops/gitops-overview-dashboard.png"
+url="/images/guides/gitops/gitops-overview-dashboard.png"
+alt="GitOps Overview dashboard"
+caption="GitOps Overview dashboard"
+max-width="50%"
+%}
+
+Monitoring DORA metrics can help identify delivery issues in your organization by detecting bottlenecks among teams, and help to optimize your deployments, at technical or organizational levels. Codefresh offers support for DORA metrics out of the box.
+For more information, see [DORA metrics]({{site.baseurl}}/docs/dashboards/dora-metrics).
+
+
+{% include
+image.html
+lightbox="true"
+file="/images/guides/gitops/dora-metrics.png"
+url="/images/guides/gitops/dora-metrics.png"
+alt="DORA metrics dashboard"
+caption="DORA metrics dashboard"
+max-width="50%"
+%}
-The CD pipeline (described in the previous section) will detect that commit and use the [sync plugin](https://codefresh.io/steps/step/argocd-sync) to instruct ArgoCD to deploy the new tag. Alternatively you can setup the ArgoCD project to auto-sync on its own if it detects changes in the Git repository with the manifests.
## Using the App-of-Apps pattern
-The GitOps dashboard has native support for the [app-of-apps pattern](https://argo-cd.readthedocs.io/en/stable/operator-manual/cluster-bootstrapping/). If you have a number of applications that are related and you always
-install them as a set in your cluster you can group them in a single Application. The parent application can be defined using [declarative Argo Resources](https://argo-cd.readthedocs.io/en/stable/operator-manual/declarative-setup/).
+The GitOps Apps dashboard has native support for the [app-of-apps pattern](https://argo-cd.readthedocs.io/en/stable/operator-manual/cluster-bootstrapping/){:target="\_blank"}. If you have a number of applications that are related and you always install them as a set in your cluster you can group them in a single Application. The parent application can be defined using [declarative Argo Resources](https://argo-cd.readthedocs.io/en/stable/operator-manual/declarative-setup/){:target="\_blank"}.
As an example, you might find that you always install in your cluster Linkerd, Prometheus and Ambassador. You can group all of them in a single Application and deploy them all at once.
-You can find an existing example of app-of-apps at [https://github.com/argoproj/argocd-example-apps/tree/master/apps](https://github.com/argoproj/argocd-example-apps/tree/master/apps). It is using [Helm]({{site.baseurl}}/docs/yaml-examples/examples/helm/), but you can use any other Kubernetes templating mechanism such as [Kustomize]({{site.baseurl}}/docs/yaml-examples/examples/deploy-with-kustomize/) (or even plain manifests).
+You can find an existing example of app-of-apps at [https://github.com/argoproj/argocd-example-apps/tree/master/apps](https://github.com/argoproj/argocd-example-apps/tree/master/apps){:target="\_blank"}. It uses [Helm]({{site.baseurl}}/docs/example-catalog/cd-examples/helm/), but you can use any other Kubernetes templating mechanism such as [Kustomize]({{site.baseurl}}/docs/example-catalog/cd-examples/deploy-with-kustomize/) (or even plain manifests).
-Once you deploy the application with Codefresh, you will see the parent app in the dashboard with a small arrow:
+Once you deploy the application with Codefresh, you will see the parent app in the GitOps Apps dashboard with a small arrow:
{% include image.html
lightbox="true"
@@ -608,7 +492,7 @@ You can expand the application by clicking on the arrow to inspect its child app
max-width="90%"
%}
- Then you can either click on the parent application or any of the children to visit the respective dashboard. In the dashboard of the parent application, you will also be notified for its components after each deployment under the "Updated Applications" header:
+Clicking the parent application or the Then you can either click on the parent application or any of the children to visit the respective dashboard. In the dashboard of the parent application, you will also be notified for its components after each deployment under the "Updated Applications" header:
{% include image.html
lightbox="true"
@@ -621,68 +505,6 @@ You can expand the application by clicking on the arrow to inspect its child app
Note that the app of apps pattern is best used for related but not interdependent applications. If you have applications that depend on each other (e.g. frontend that needs backend and backend that needs a DB) we suggest you use the standard [Helm dependency mechanism](https://helm.sh/docs/helm/helm_dependency/).
-## Integrating Codefresh and Jira
-
-> Note that Codefresh currently has to provide you with access to use the Jira Marketplace App. Please get in touch for more information.
-
-Setting up the Codefresh Jira integration provides
-
-* Higher observability of deployments within your GitOps Dashboard
-* Higher observability of deployments within your Jira Account
-
-[Our integration section]({{site.baseurl}}/docs/integrations/jira) provides further details on ways to set-up the connection.
-
-Once set-up, you will be able to view information from Jira in the Codefresh GitOps Dashboard. Additionally, Jira will display
-
-* The build status across environments
-* The deployment history
-* Tickets and how they correlate to deployments
-
-The following screenshots show examples of the provided information. Here is the deployments details for a ticket in JIRA:
-
-{% include image.html
-lightbox="true"
-file="/images/integrations/jira/jira-integration-one.png"
-url="/images/integrations/jira/jira-integration-one.png"
-alt="Ticket deployment history"
-caption="Ticket deployment history"
-max-width="90%"
-%}
-
-And here is a complete timeline of your deployments and the feature they contain.
-
-{% include image.html
-lightbox="true"
-file="/images/integrations/jira/jira-integration-two.png"
-url="/images/integrations/jira/jira-integration-two.png"
-alt="Jira Deployment timeline"
-caption="Jira Deployment timeline"
-max-width="90%"
-%}
-
-For more information see the [Atlassian Codefresh page](https://www.atlassian.com/solutions/devops/integrations/codefresh) and the [integration documentation]({{site.baseurl}}/docs/integrations/jira/).
-
-## Using a Git repository for the pipelines
-
-Remember that according to GitOps we should place *all* application resources on Git. This means that the pipelines themselves must also be present in a Git repository and any change on them should pass from source control.
-
-Even though Codefresh has a [powerful inline editor]({{site.baseurl}}/docs/configure-ci-cd-pipeline/pipelines/#using-the-inline-pipeline-editor) for editing pipelines, as soon as you finish with your pipelines you [should commit them in Git](https://github.com/codefresh-contrib/gitops-pipelines)
-and load them from the repository.
-
-{% include image.html
- lightbox="true"
- file="/images/guides/gitops/pipeline-from-git.png"
- url="/images/guides/gitops/pipeline-from-git.png"
- alt="Loading a pipeline from GIT"
- caption="Loading a pipeline from GIT"
- max-width="80%"
- %}
-
- Once the pipeline is in Git, you should switch the online editor to [load the pipeline from the repository]({{site.baseurl}}/docs/configure-ci-cd-pipeline/pipelines/#loading-codefreshyml-from-version-control) instead of the inline text.
-
-## What to read next
-* [Codefresh YAML]({{site.baseurl}}/docs/codefresh-yaml/what-is-the-codefresh-yaml/)
-* [ArgoCD integration]({{site.baseurl}}/docs/integrations/argocd/)
-* [Environment dashboard]({{site.baseurl}}/docs/deploy-to-kubernetes/environment-dashboard/)
-* [Helm promotions]({{site.baseurl}}/docs/new-helm/helm-environment-promotion/)
+## Related articles
+[Progressive delivery with Argo Rollouts]({{site.baseurl}}/docs/ci-cd-guides/progressive-delivery/)
\ No newline at end of file
diff --git a/_docs/ci-cd-guides/helm-best-practices.md b/_docs/ci-cd-guides/helm-best-practices.md
new file mode 100644
index 000000000..838ace17c
--- /dev/null
+++ b/_docs/ci-cd-guides/helm-best-practices.md
@@ -0,0 +1,367 @@
+---
+title: "Helm best practices"
+description: "High-level overview of Helm workflows"
+group: ci-cd-guides
+redirect_from:
+ - /docs/new-helm/helm-best-practices/
+ - /docs/new-helm/best-practices/
+toc: true
+---
+
+[Helm](https://helm.sh){:target="\_blank"} is a package manager for Kubernetes (think `apt` or `yum`). It works by combining several manifests into a single package called [a chart](https://helm.sh/docs/developing_charts/){:target="\_blank"}.
+Helm also supports storing charts in remote or local Helm repositories that function as package registries, such as Maven Central, Ruby Gems, NPM registry, etc.
+
+Helm is currently the only solution that supports:
+
+* Grouping related Kubernetes manifests in a single entity (the chart)
+* Basic templating and values for Kubernetes manifests
+* Dependency declaration between applications (chart of charts)
+* A registry of available applications to be deployed (Helm repository)
+* A view of a Kubernetes cluster at the application/chart level
+* Managing of chart installation/upgrades as a whole
+* Built-in rollback of a chart to a previous version without running a CI/CD pipeline again
+
+You can find a list of public curated charts in the default [Helm repository](https://github.com/helm/charts/tree/master/stable){:target="\_blank"}.
+
+Several third-party tools support Helm chart creation such as [Draft](https://draft.sh/){:target="\_blank"}. Local Helm development
+is also supported by [garden.io](https://docs.garden.io/using-garden/using-helm-charts){:target="\_blank"}, and/or [skaffold](https://skaffold.dev/docs/how-tos/deployers/#deploying-with-helm){:target="\_blank"}. Check your favorite tool for native Helm support.
+
+Codefresh also has built-in support for Helm:
+* [Packages]({{site.baseurl}}/docs/deployments/helm/helm-releases-management/)
+* [Deployments]({{site.baseurl}}/docs/deployments/helm/using-helm-in-codefresh-pipeline/)
+* [Repositories]({{site.baseurl}}/docs/deployments/helm/managed-helm-repository/)
+* [Environments]({{site.baseurl}}/docs/deployments/helm/helm-environment-promotion/)
+
+## Helm concepts
+
+The [official docs](https://helm.sh/docs/using_helm/){:target="\_blank"} do a good job of explaining the basic concepts.
+The table below focuses on some important points.
+
+Helm Concept|Description| Important point
+---|--- | ---
+Chart (unpackaged) | A folder with files that follow the Helm chart guidelines. | Can be deployed directly to a cluster |
+Chart (packaged) | A `tar.gz` archive of the above. | Can be deployed directly to a cluster |
+Chart name | Name of the package as defined in `Chart.yaml` | Part of package identification |
+Templates | A set of Kubernetes manifests that form an application. | `Go` templates can be used |
+Values | Settings that can be parameterized in Kubernetes manifests. | Used for templating of manifests |
+Chart version | The version of the package/chart. | Part of package identification |
+App version | The version of the application contained in the chart. | **Independent from chart version** |
+Release | A deployed package in a Kubernetes cluster. | **Multiple releases of the same chart can be active**|
+Release name | An arbitrary name given to the release. | **Independent from name of chart** |
+Release Revision | A number that gets incremented each time an application is deployed/upgraded.| **Unrelated to chart version**|
+Repository | A file structure (HTTP server) with packages and an `index.yaml` file. | Helm charts can be deployed **without** being first fetched from a repository |
+Installing | Creating a brand-new release from a Helm chart (either unpackaged, packaged or from a repo). | |
+Upgrading | Changing an existing release in a cluster | Can be upgraded to any version (even the same) |
+Rolling back | Going back to a previous revision of a release. | Helm handles the rollback, no need to rerun pipeline |
+Pushing | Storing a Helm package on a repository. | Chart will be automatically packaged |
+Fetching | Downloading a Helm package from a repository to the local filesystem. | |
+
+## Common Helm misconceptions
+
+Any new technology requires training on how to use it effectively. If you have already worked with any type of package manager, you should be familiar with how Helm works.
+
+Here is a list of important Helm points that are often controversial between teams.
+
+### Helm repositories are optional
+
+Using Helm repositories is a recommended practice, but completely optional. You can deploy a Helm chart to a Kubernetes cluster directly from the filesystem. The [Helm deployment quick start]({{site.baseurl}}/docs/quick-start/ci-quick-start/deploy-with-helm/) describes this scenario.
+
+Helm can install a chart either in the package (`.tgz`) or unpackaged (tree of files) to a Kubernetes cluster right away. Thus, the most minimal Helm pipeline has only two steps:
+
+1. Check out from Git a Helm chart described in uncompressed files.
+1. Install this chart to a Kubernetes cluster.
+
+{% include image.html
+lightbox="true"
+file="/images/guides/helm-best-practices/helm-direct-deployment.png"
+url="/images/guides/helm-best-practices/helm-direct-deployment.png"
+alt="Simplest Helm pipeline"
+caption="Simplest Helm pipeline"
+max-width="70%"
+%}
+
+You will see in the next section more efficient workflows, but the fact remains that Helm repositories are optional. There is **no** technical requirement that a Helm chart must be uploaded to a Helm repository before being deployed to a cluster.
+
+### Chart versions and appVersions
+
+Each Helm chart has the ability to define two separate versions:
+
+1. The version of the chart itself (`version` field in `Chart.yaml`).
+1. The version of the application contained in the chart (`appVersion` field in `Chart.yaml`).
+
+These are unrelated and can be bumped up in any manner that you see fit. You can sync them together or have them increase independently. There is no right or wrong practice here as long as you stick into one. We will see some versioning strategies in the next section.
+
+### Charts and sub-charts
+
+The most basic way to use Helm is by having a single chart that holds a single application. The single chart will contain all the resources needed by your application such as deployments, services, config-maps etc.
+
+However, you can also create a chart with dependencies to other charts (a.k.a. umbrella chart), which are completely external using the `requirements.yaml` file. Using this strategy is optional and can work well in several organizations. Again, there is no definitive answer on right and wrong here, it depends on your team process.
+
+{% include image.html
+lightbox="true"
+file="/images/guides/helm-best-practices/chart-structure.png"
+url="/images/guides/helm-best-practices/chart-structure.png"
+alt="Possible Helm structures"
+caption="Possible Helm structures"
+max-width="70%"
+%}
+
+We will see some scenarios in the next sections on why you would want to use umbrella charts.
+
+
+### Helm vs K8s templates
+
+Helm is a package manager that also happens to include templating capabilities. Unfortunately, a lot of people focus only on the usage of Helm as a template manager and nothing else.
+
+Technically Helm can be used as only a templating engine by stopping the deployment process in the manifest level. It is perfectly possible to use Helm only to [create plain Kubernetes manifests](https://helm.sh/docs/helm/#helm-template){:target="\_blank"} and then install them on the cluster using the standard methods (such as `kubectl`). But then you miss all the advantages of Helm (especially the application registry aspect).
+
+At the time of writing Helm is the only package manager for Kubernetes, so if you want a way to group your manifests and a registry of your running applications, there are no off-the-shelf alternative apart from Helm.
+
+Here is a table that highlights the comparison:
+
+Helm Feature|Alternative|
+---|---
+Templating | Kustomize, k8comp, kdeploy, ktmpl, kuku, jinja, sed, awk, etc.
+Manifest grouping (entity/package) | None
+Application/package dependencies | None
+Runtime view of cluster packages | None
+Registry of applications | None
+Direct rollbacks and Upgrades | None
+
+
+
+
+## Helm pipelines
+
+With the basics out of the way, we can now see some typical Helm usage patterns. Depending on the size of your company and your level of involvement with Helm you need to decide which practice is best for you.
+
+
+### Deploy from an unpackaged chart
+
+This is the simplest pipeline for Helm. The Helm chart is in the same Git repository as the source code of the application.
+
+{% include image.html
+lightbox="true"
+file="/images/guides/helm-best-practices/helm-no-repo.png"
+url="/images/guides/helm-best-practices/helm-no-repo.png"
+alt="Using Helm without a Helm repository"
+caption="Using Helm without a Helm repository"
+max-width="70%"
+%}
+
+The steps are the following:
+
+1. Code/Dockerfile/Chart is checked out from Git
+1. Docker image is built (and pushed to [default Docker registry]({{site.baseurl}}/docs/integrations/docker-registries/#default-registry))
+1. Chart is [deployed directly]({{site.baseurl}}/docs/deployments/helm/using-helm-in-codefresh-pipeline/#example-installing-a-chart) to a Kubernetes Cluster
+
+Notice that in this pipeline there is no Helm repository involved.
+
+> We recommend this workflow only while you are learning Helm. Storing your Helm charts in a Helm repository is a better practice as described in the next section.
+
+### Package/push and then deploy
+
+This is the recommended approach when using Helm. First, you package and push the Helm chart into a repository, and then you deploy it to your cluster.
+This way your Helm repository shows a registry of the applications that run on your cluster. You can also reuse the charts to deploy to other environments (described later in this page).
+
+{% include image.html
+lightbox="true"
+file="/images/guides/helm-best-practices/basic-helm-pipeline.png"
+url="/images/guides/helm-best-practices/basic-helm-pipeline.png"
+alt="Basic Helm application pipeline"
+caption="Basic Helm application pipeline"
+max-width="70%"
+%}
+
+The Helm chart can be either in the same Git repository as the source code (as shown above) or in a different one.
+Note that this workflow assumes that you [have attached a Helm repository]({{site.baseurl}}/docs/deployments/helm/using-helm-in-codefresh-pipeline/#step-4-optional---import-the-helm-configuration-in-your-pipeline-definition) configuration in the pipeline.
+
+If you use the [Codefresh Helm repository]({{site.baseurl}}/docs/deployments/helm/managed-helm-repository/) you can see all your releases in the Codefresh UI.
+
+{% include image.html
+lightbox="true"
+file="/images/guides/helm-best-practices/helm-catalog.png"
+url="/images/guides/helm-best-practices/helm-catalog.png"
+alt="Helm application catalog"
+caption="Helm application catalog"
+max-width="70%"
+%}
+
+
+This approach allows you also to reuse Helm charts. After you publish a Helm chart, in the Helm repository you can deploy it to another environment (with a pipeline or manually) using different values.
+
+
+### Separate Helm pipelines
+
+Even though packaging and deploying a release in a single pipeline is the recommended approach, several companies have two different processes for packaging and releasing.
+
+In this case, you can create two pipelines. One that packages the Helm chart and uploads it to a Helm repository, and another one that deploys to a cluster from the Helm chart.
+
+{% include image.html
+lightbox="true"
+file="/images/guides/helm-best-practices/push-and-deploy.png"
+url="/images/guides/helm-best-practices/push-and-deploy.png"
+alt="Push and deploy in different pipelines"
+caption="Push and deploy in different pipelines"
+max-width="70%"
+%}
+
+While this approach offers flexible releases (as one can choose exactly what is released and what is not), it also raises the complexity of deployments. You need to pass parameters on the deployment pipeline to decide which chart version will be deployed.
+
+In Codefresh, you can also have the two pipelines automatically [linked together]({{site.baseurl}}/docs/integrations/codefresh-api/#using-codefresh-from-within-codefresh).
+
+### Using Helm rollbacks
+
+Helm has the native capability of [rolling back](https://helm.sh/docs/helm/#helm-rollback){:target="\_blank"} a *release* to any previous *revision*. This can be done
+manually or via the [Codefresh UI]({{site.baseurl}}/docs/deployments/helm/helm-releases-management/#helm-releases-overview
+).
+
+A more advanced usage would be to automatically rollback a release if it "fails".
+
+{% include image.html
+lightbox="true"
+file="/images/guides/helm-best-practices/helm-rollback.png"
+url="/images/guides/helm-best-practices/helm-rollback.png"
+alt="Automatic Helm rollback"
+caption="Automatic Helm rollback"
+max-width="70%"
+%}
+
+In the example pipeline above, after deployment, we run some smoke tests/health checks. If they fail,
+then the rollback step is executed using [pipeline conditionals]({{site.baseurl}}/docs/pipelines/conditional-execution-of-steps/).
+
+Alternatively, you can run any other [freestyle step]({{site.baseurl}}/docs/pipelines/steps/freestyle/) after a deployment such as health checks, metric collection, load testing, etc. that decides if a deployment if a Helm rollback is needed or not.
+
+Integrating automatic Helm rollbacks can be used in all kinds of Helm workflows that were described in this section.
+
+
+## Helm packaging strategies
+
+As mentioned before a Helm chart version is completely different than the application version it contains. This means that you can track versions on the Helm chart itself separately from the applications it defines.
+
+### Simple 1-1 versioning
+
+This is the most basic versioning approach, and it is the suggested one if you are starting out with Helm.
+Don't use the `appVersion` field at all (it is optional anyway) and just keep the chart version in sync with your actual application.
+
+{% include image.html
+lightbox="true"
+file="/images/guides/helm-best-practices/chart-version-single.png"
+url="/images/guides/helm-best-practices/chart-version-single.png"
+alt="Synced versions in Helm"
+caption="Synced versions in Helm"
+max-width="60%"
+%}
+
+This approach makes version bumping very easy (you bump everything up) and also allows you to quickly track
+what application version is deployed on your cluster (same as chart version).
+
+The downside of this approach is that you can't track chart changes separately.
+
+### Chart versus application versioning
+
+This is an advanced approach which you should adopt if changes are happening in the charts themselves all the time (i.e. in the templates) and you want to track them separately from the application.
+
+{% include image.html
+lightbox="true"
+file="/images/guides/helm-best-practices/chart-version-multiple.png"
+url="/images/guides/helm-best-practices/chart-version-multiple.png"
+alt="Independent Helm versioning"
+caption="Independent Helm versioning"
+max-width="90%"
+%}
+
+An important point here is that you need to adopt a policy in your team on what a "chart change" means. Helm does not enforce chart version changes. You can deploy a different chart with the same version as the previous one. So, if this is something that you want to do, you need to make sure that all teams are on the same page for versioning practices.
+
+On the plus side, this workflow allows you to individually version charts and applications and is very flexible for companies with teams that manage separately the charts from the application source code.
+
+
+### Umbrella charts
+
+Umbrella charts are charts of charts. They add an extra layer of complexity on both previous approaches.
+You can follow the same paradigms in umbrella charts. Either the parent chart has the same version as everything else (first approach) or it has a version on its own.
+
+In the second case, you need to agree with your team on when exactly the parent chart version should be bumped. Is it only when a child chart changes? Only when an application changes? or both?
+
+The answer does not really matter as long as your team follows the same rules.
+
+## Helm promotion strategies
+
+A Helm chart (like a Docker image) should be promoted between environments. It should start with testing and staging environments and gradually move to production ones.
+
+### Single repository with multiple environments
+
+This is the most basic deployment workflow. You have a single Helm chart (which is exactly the same across all environments).
+It is deployed to multiple targets using a different set of values.
+
+{% include image.html
+lightbox="true"
+file="/images/guides/helm-best-practices/multiple-environments.png"
+url="/images/guides/helm-best-practices/multiple-environments.png"
+alt="Deploy to multiple environments with Helm"
+caption="Deploy to multiple environments with Helm"
+max-width="90%"
+%}
+
+Codefresh has several ways to override the values for each environment within a [pipeline]({{site.baseurl}}/docs/deployments/helm/using-helm-in-codefresh-pipeline/#helm-values).
+
+
+### Chart promotion between environments
+
+This is the recommended deployment workflow. Codefresh can store different Helm values per environment in the [shared configuration]({{site.baseurl}}/docs/pipelines/configuration/shared-configuration/#using-shared-helm-values) mechanism.
+Then you view and manage releases from the [Helm environments dashboard]({{site.baseurl}}/docs/deployments/helm/helm-environment-promotion/).
+
+{% include
+image.html
+lightbox="true"
+file="/images/guides/helm-best-practices/board.png"
+url="//images/guides/helm-best-practices/board.png"
+alt="Helm Environment Dashboard"
+caption="Helm Environment Dashboard"
+max-width="80%"
+%}
+
+Then once you promote a Helm release either from the GUI, or the pipeline you can select exactly which configuration set of parameters you want to use:
+
+{% include
+image.html
+lightbox="true"
+file="/images/guides/helm-best-practices/value-options.png"
+url="/images/guides/helm-best-practices/value-options.png"
+alt="Changing deployment values"
+caption="Changing deployment values"
+max-width="40%"
+%}
+
+This workflow has two big advantages:
+
+1. You get a visual overview on what and where each Helm release is installed on
+1. You can promote releases without running the initial CI/CD pipeline (that created the chart)
+
+### Chart promotion between repositories and environments
+
+A more advanced workflow (useful in organizations with multi-location deployments) is the promotion of Helm releases between both [repositories]({{site.baseurl}}/docs/deployments/helm/helm-charts-and-repositories/) and environments.
+
+{% include
+image.html
+lightbox="true"
+file="/images/guides/helm-best-practices/advanced-promote.png"
+url="/images/guides/helm-best-practices/advanced-promote.png"
+alt="Advanced Helm promotion"
+caption="Advanced Helm promotion"
+max-width="90%"
+%}
+
+There are different pipelines for:
+
+1. Creating the Helm chart and storing it to a staging Helm repository (i.e. the Codefresh Helm repository)
+1. Deployment of the Helm chart to a staging environment. After it is tested *the chart* is promoted to one or more "production" Helm repositories
+1. Deployment of the promoted Helm chart happens to one of the production environments
+
+While this workflow is very flexible, it adds complexity on the number of Helm charts available (since they exist in multiple Helm repositories). You also need to set up the parameters between the different pipelines so that Helm charts to be deployed can be indeed found in the expected Helm repository.
+
+## Related articles
+[Helm quick start guide]({{site.baseurl}}/docs/quick-start/ci-quick-start/deploy-with-helm/)
+[Using Helm in a Codefresh pipeline]({{site.baseurl}}/docs/deployments/helm/using-helm-in-codefresh-pipeline/)
+[Helm Dashboard]({{site.baseurl}}/docs/deployments/helm/helm-releases-management)
+[Helm Promotion boards]({{site.baseurl}}/docs/deployments/helm/helm-environment-promotion)
diff --git a/_docs/ci-cd-guides/image-enrichment.md b/_docs/ci-cd-guides/image-enrichment.md
new file mode 100644
index 000000000..ad268c496
--- /dev/null
+++ b/_docs/ci-cd-guides/image-enrichment.md
@@ -0,0 +1,56 @@
+---
+title: "Image enrichment"
+description: "Enrich images with metadata"
+group: ci-cd-guides
+toc: true
+---
+
+Building Docker images is one of the most basic requirements of Codefresh pipelines and Argo Workflows.
+Once you create an image, push the image to a registry, and report it to Codefresh, image information is continually updated in the Images page.
+
+By default, each container registry has very basic information for a Docker image, such as timestamp, hash, size etc.
+
+With Codefresh, you can enrich the basic information reported with the image with issue-tracking metadata and annotations.
+For example, information such as:
+* Which Pull Request created this image
+* What tests and code coverage this image has
+* What security scans have run on it (and their results)
+
+## Codefresh pipelines image reporting and enrichment flow
+
+Complete these steps to view enriched image information in the Images dashboard for Codefresh pipelines.
+
+1. (Mandatory) Build and push the Docker image
+ Use the `build` step to build a Docker image declaratively in simple or multi-stage Dockerfiles. See [Build step in pipelines]({{site.baseurl}}/docs/pipelines/steps/build/).
+ The pipeline pushes the image to the default Docker registry.
+ You can also push the image to any external Docker registry that you integrate with Codefresh. See [Docker Registries for pipeline integrations]({{site.baseurl}}/docs/integrations/docker-registries/).
+
+ Review different scenarios for building and pushing Docker images in our [Build/push examples]({{site.baseurl}}/docs/example-catalog/examples/#buildpush-examples).
+
+1. (Optional) Enrich image with annotations and metadata
+ Enrich the image with metadata such as feature requests, pull requests from issue-tracking tools such as Jira for visibility into all aspects of the deployment.
+ See [Docker image metadata]({{site.baseurl}}/docs/pipelines/docker-image-metadata/)
+ * GitOps
+ See [GitOps issue tracking integrations]({{site.baseurl}}/docs/gitops-integrations/issue-tracking) and [Jira]({{site.baseurl}}/docs/gitops-integrations/issue-tracking/jira) integration.
+
+
+## Codefresh GitOps image reporting and enrichment flow
+
+Complete these steps to view enriched image information in the Images dashboard for Codefresh GitOps deployments.
+
+1. (Mandatory) Connect to Docker registries
+ Connect Docker registries to Codefresh to store Docker images.
+ See [GitOps container registry integrations]({{site.baseurl}}/docs/gitops-integrations/container-registries).
+
+1. (Mandatory) Report image information to Codefresh
+ This is the equivalent to pushing the image in Codefresh pipelines.
+ Use 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"} DAG template to report image information to Codefresh.
+
+ > If you are using an external platform or tool for your CI pipelines such as GitHub Actions or Jenkins, or even Codefresh pipelines, we have a new template that combines image reporting and enrichment. See [GitOps CI integrations]({{site.baseurl}}/docs/gitops-integrations/ci-integrations) for details.
+
+1. (Optional) Enrich image with annotations and metadata
+ Enrich the image with metadata such as feature requests, pull requests from issue-tracking tools such as Jira for visibility into all aspects of the deployment.
+ See [GitOps issue tracking integrations]({{site.baseurl}}/docs/gitops-integrations/issue-tracking) and [Jira]({{site.baseurl}}/docs/gitops-integrations/issue-tracking/jira) integration.
+
+## Related articles
+Images in Codefresh
\ No newline at end of file
diff --git a/_docs/ci-cd-guides/kubernetes-templating.md b/_docs/ci-cd-guides/kubernetes-templating.md
new file mode 100644
index 000000000..e56a14dfa
--- /dev/null
+++ b/_docs/ci-cd-guides/kubernetes-templating.md
@@ -0,0 +1,216 @@
+---
+title: "Simple Kubernetes templating"
+description: "Use templates in your Kubernetes manifests"
+group: ci-cd-guides
+redirect_from:
+ - /docs/deploy-to-kubernetes/kubernetes-templating/
+toc: true
+---
+
+Once you start working with Kubernetes you will see the need for using templates in Kubernetes manifests for common parameters such as:
+
+* The docker image name of a deployment
+* The docker image tag of a deployment
+* Number of replicas
+* Service labels
+* Configmaps and other settings
+
+Kubernetes does not provide any templating mechanism on its own. Deployed manifests are expected to be static yaml files. An external solution is needed if you want to pass parameters in your manifests.
+
+The proper way to handle templates is within [Helm]({{site.baseurl}}/docs/quick-start/ci-quick-start/deploy-with-helm/) . Helm is the package manager for Kubernetes and also includes templating capabilities.
+
+To use templates without using Helm, there are several templating solutions available including [Kustomize](https://github.com/kubernetes-sigs/kustomize){:target="\_blank"} from Google.
+
+Codefresh also includes its own simple templating mechanism that has built-in integration with all [pipeline variables]({{site.baseurl}}/docs/pipelines/variables/) as we will explain in this page.
+
+## Using the Codefresh deploy image
+
+Codefresh offers a public docker image at [https://hub.docker.com/r/codefresh/cf-deploy-kubernetes/tags/](https://hub.docker.com/r/codefresh/cf-deploy-kubernetes/tags/){:target="\_blank"} for easy templating of Kubernetes manifests. The source code of the image is at [https://github.com/codefresh-io/cf-deploy-kubernetes](https://github.com/codefresh-io/cf-deploy-kubernetes){:target="\_blank"}. This image can be used in a freestyle step like this:
+
+`YAML`
+{% highlight yaml %}
+{% raw %}
+ MyDeploy:
+ title: K8s Deploy
+ image: codefresh/cf-deploy-kubernetes:master
+ commands:
+ - /cf-deploy-kubernetes deployment.yml
+ environment:
+ - KUBECONTEXT=my-cluster-name
+ - KUBERNETES_NAMESPACE=my-namespace
+{% endraw %}
+{% endhighlight %}
+
+The step accepts the following environment variables:
+
+* `KUBECONTEXT`: Corresponds to the name of a cluster added to codefresh.
+* `KUBERNETES_NAMESPACE`: The namespace to which to deploy.
+* `KUBECTL_ACTION`: An action for `kubectl `. Valid values are `apply|create|replace` (default is `apply`).
+* `KUBERNETES_DEPLOYMENT_TIMEOUT`: The duration to wait for a successful deployment before failing the build (defaults to 120 secs).
+
+The step will deploy your deployment to the cluster specified by the context and namespace given. The name of the context is the name of your cluster as seen in the [Kubernetes dashboard]({{site.baseurl}}/docs/deployments/kubernetes/manage-kubernetes/).
+
+Before the deployment takes place, all Codefresh variables found in the `deployment.yml` file in the form of {% raw %}`{{MY_VARIABLE}}`{% endraw %} will be automatically replaced with their current values.
+
+Here is an example manifest:
+
+`Kubernetes manifest`
+{% highlight yaml %}
+{% raw %}
+apiVersion: extensions/v1beta1
+kind: Deployment
+metadata:
+ name: my-demo-app
+ annotations:
+ branch: {{CF_BRANCH_TAG_NORMALIZED}}
+ source-repository: {{CF_REPO_NAME}}
+spec:
+ replicas: 4
+ template:
+ metadata:
+ labels:
+ name: my-demo-app
+ app: my-demo-app
+ spec:
+ containers:
+ - name: my-demo-app
+ image: r.cfcr.io/{{CF_ACCOUNT}}/my-sample-application:{{CF_SHORT_REVISION}}
+ imagePullPolicy: Always
+ ports:
+ - name: http
+ containerPort: 8080
+ protocol: TCP
+{% endraw %}
+{% endhighlight %}
+
+In this case the image will get the replacement for your Codefresh account name and the tag will use the git revision. Metadata annotations are also defined with value from the branch name and the git repository name.
+
+Notice that the variables are declared as {% raw %}`{{MY_VARIABLE}}`{% endraw %} form and **NOT** {% raw %}`${{MY_VARIABLE}}`{% endraw %} which is how they are used inside the [Codefresh yaml]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/) definition.
+
+
+## Creating custom manifest replacements
+
+Apart from the built-in [Codefresh variables]({{site.baseurl}}/docs/pipelines/variables/) you can also create any variable on your own using the same replacement syntax.
+
+Here is an example manifest.
+
+`Kubernetes manifest`
+{% highlight yaml %}
+{% raw %}
+apiVersion: extensions/v1beta1
+kind: Deployment
+metadata:
+ name: my-demo-app
+ annotations:
+ source-repository: {{CF_REPO_NAME}}
+ branch: {{CF_BRANCH_TAG_NORMALIZED}}
+ custom-label: {{MY_CUSTOM_LABEL}}
+spec:
+ replicas: {{MY_REPLICA_NUMBER}}
+ template:
+ metadata:
+ labels:
+ name: my-demo-app
+ app: my-demo-app
+ spec:
+ containers:
+ - name: my-demo-app
+ image: r.cfcr.io/{{CF_ACCOUNT}}/my-sample-application:{{CF_SHORT_REVISION}}
+ imagePullPolicy: Always
+ ports:
+ - name: http
+ containerPort: 8080
+ protocol: TCP
+ imagePullSecrets:
+ - name: {{PULL_SECRET}}
+{% endraw %}
+{% endhighlight %}
+
+Here you can see custom variables for an annotation, the replica number and the pull secret (in addition with the standard variables).
+You can provide the values for your custom variables as environment parameters in the freestyle step.
+
+`codefresh.yaml`
+{% highlight yaml %}
+{% raw %}
+version: '1.0'
+steps:
+ BuildingDockerImage:
+ title: Building Docker Image
+ type: build
+ image_name: my-sample-application
+ tag: '${{CF_SHORT_REVISION}}'
+ dockerfile: Dockerfile
+ MyDeploy:
+ title: K8s Deploy
+ image: codefresh/cf-deploy-kubernetes:master
+ commands:
+ - /cf-deploy-kubernetes deployment.yml
+ environment:
+ - KUBECONTEXT=k8s-demo@Google
+ - KUBERNETES_NAMESPACE=my-namespace
+ - MY_CUSTOM_LABEL=build-id-${{CF_BUILD_ID}}
+ - MY_REPLICA_NUMBER=3
+ - PULL_SECRET=codefresh-generated-r.cfcr.io-cfcr-my-namespace
+{% endraw %}
+{% endhighlight %}
+
+In the environment section you can see the values for the custom variables. We set the replica number to 3, a full string for the pull secret and a concatenated string for the annotation.
+
+## Using replacements in multiple manifests
+
+By default, the deploy step will only do replacements in a single manifest. If you have multiple Kubernetes manifests you can merge all of them in a single file, or use multiple times the deploy commands like this:
+
+`codefresh.yml`
+{% highlight yaml %}
+{% raw %}
+ MyDeploy:
+ title: K8s Deploy
+ image: codefresh/cf-deploy-kubernetes:master
+ commands:
+ - /cf-deploy-kubernetes deployment.yml
+ - /cf-deploy-kubernetes service.yml
+ - /cf-deploy-kubernetes config-map.yml
+ environment:
+ - KUBECONTEXT=my-cluster-name
+ - KUBERNETES_NAMESPACE=my-namespace
+ - MY_REPLICA_NUMBER=3
+ - KUBERNETES_DEPLOYMENT_TIMEOUT=360
+{% endraw %}
+{% endhighlight %}
+
+Variable replacements will happen in all manifests before they are deployed.
+
+
+## Using Unix command line tools for templates
+
+It is also perfectly possible to use any Unix templating or text editing tool such as `sed` or `awk` to perform text replacements in Kubernetes manifests.
+
+As a very simple example you could a replacement with the following [freestyle step]({{site.baseurl}}/docs/pipelines/steps/freestyle/) in your Codefresh pipeline.
+
+`YAML`
+{% highlight yaml %}
+{% raw %}
+version: '1.0'
+steps:
+ my_replacement:
+ image: alpine
+ commands:
+ # replace every ${TAG} with current TAG variable value
+ - sed -i 's/${TAG}/${{TAG}}/g' my-k8s-deployment.yaml
+{% endraw %}
+{% endhighlight %}
+
+## Related articles
+[Kubernetes integrations]({{site.baseurl}}/docs/deployments/kubernetes/#connect-a-kubernetes-cluster)
+[Managing Kubernetes clusters]({{site.baseurl}}/docs/deployments/kubernetes/manage-kubernetes/)
+[Accessing a docker registry]({{site.baseurl}}/docs/ci-cd-guides/access-docker-registry-from-kubernetes/)
+[Custom kubectl commands]({{site.baseurl}}/docs/deployments/kubernetes/custom-kubectl-commands/)
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/_docs/ci-cd-guides/microservices.md b/_docs/ci-cd-guides/microservices.md
index 8306d2d0f..0e960f246 100644
--- a/_docs/ci-cd-guides/microservices.md
+++ b/_docs/ci-cd-guides/microservices.md
@@ -1,15 +1,15 @@
---
-title: "Building Microservices"
-description: "Learn how to create pipelines specifically for microservice applications"
+title: "Building microservices"
+description: "Create pipelines specifically for microservice applications"
group: ci-cd-guides
toc: true
---
-Now that you know how to [build your app]({{site.baseurl}}/docs/ci-cd-guides/packaging-compilation/) and [create Docker images]({{site.baseurl}}/docs/ci-cd-guides/building-docker-images/), we can see how Codefresh works with Microservice applications.
+Now that you know how to [build your app]({{site.baseurl}}/docs/ci-cd-guides/packaging-compilation/) and [create Docker images]({{site.baseurl}}/docs/ci-cd-guides/building-docker-images/), we can see how Codefresh works with microservice applications.
## Organizing pipelines for monolithic applications
-In the past, pipelines for monolithic applications tended to share the same characteristics of the application they were building. Each project had a single pipeline which was fairly complex and different projects had completely different pipelines. Each pipeline was almost always connected to a single GIT repository.
+In the past, pipelines for monolithic applications tended to share the same characteristics of the application they were building. Each project had a single pipeline which was fairly complex, and different projects had completely different pipelines. Each pipeline was almost always connected to a single Git repository.
{% include image.html
lightbox="true"
@@ -20,11 +20,11 @@ caption="Monolithic pipelines"
max-width="80%"
%}
-The complexity of each pipeline was detrimental to easy maintenance. Pipelines were typically controlled by a small team of gurus who are familiar with both the internals of the application as well as the deployment environment.
+The complexity of each pipeline was detrimental to easy maintenance. Pipelines were typically controlled by a small team of gurus, familiar with both the internals of the application as well as the deployment environment.
-For each software project, operators are taking care of the pipeline structure while the developers are only working with the source code (going against the DevOps paradigm where all teams should share responsibility for common infrastructure and collaborate on shared problems).
+For each software project, operators handle the pipeline structure, while developers only work with the source code (going against the DevOps paradigm where all teams should share responsibility for common infrastructure and collaborate on shared problems).
-Pipeline size and complexity is often a huge pain point. Even though several tools exist for the continuous integration part of a monolithic application, continuous deployment is a different matter completely which forced a lot of companies to create their own custom in-house scripts for taking care of deployment.
+Pipeline size and complexity is often a huge pain point. Even though several tools exist for the continuous integration part of a monolithic application, continuous deployment being a different matter completely, forced a lot of companies to create their own custom in-house scripts to take care of deployment.
## Scalability issues with microservice pipelines
@@ -43,7 +43,7 @@ caption="Number of pipelines is exploding"
max-width="80%"
%}
-This sudden explosion in numbers prohibits working manually with pipelines anymore. Several CI solutions are not even prepared to work with such a high number of pipelines.
+This sudden explosion in numbers prohibits working manually with pipelines anymore. Several CI solutions do not have the capacity to work with such a high number of pipelines.
**Here is where we reach the biggest pitfall regarding pipeline management in the era of microservices**. Several companies tried to solve the problem of microservice pipelines using shared pipeline segments.
@@ -58,14 +58,14 @@ max-width="80%"
In theory, this sounds like a good idea:
-1. Operators are locating the common parts of pipelines with applications
-1. A shared pipeline segment registry is created that holds all those common parts
+1. Operators locate the common parts of pipelines with applications
+1. A shared pipeline segment registry is created to hold all those common parts
1. Pipelines in existing projects are re-engineered to depend on the common segments
1. New projects must first examine the library of common pipeline segments and choose what is already there
-The final result is that a single pipeline is actually composed of two types of steps, those common to other pipelines and those that are specific to that project only.
+The final result is that a single pipeline is actually composed of two types of steps, those common to other pipelines, and those that are specific to that project only.
-This has lead to the development of several solutions which attempt to centralized common pipeline parts and re-use them in the form of “libraries” within software projects. The issue here is that this approach requires a very large time investment as well as a disciplined team that can communicate and cooperates on the following factors:
+This has lead to the development of several solutions which attempt to centralize common pipeline parts and re-use them in the form of “libraries” within software projects. The issue here is that this approach requires a very large time investment as well as a disciplined team that can communicate and cooperates on the following factors:
1. Detecting which pipeline segments are indeed common,
1. Keeping the library of common pipeline segments up-to-date,
@@ -75,11 +75,11 @@ This has lead to the development of several solutions which attempt to centraliz
Unfortunately, in practice, as the number of microservice applications grows, teams find it very hard to keep all these principles in mind when creating new projects.
-## Reusing pipelines for Microservice applications
+## Reusing pipelines for microservice applications
Codefresh is the first CI/CD solution for microservices and containers. Because we are not burdened with any legacy decisions, we are free to define a new model for Codefresh pipelines which is focused on microservices.
-The basic idea is that all microservices of a single application have almost always the same life- cycle. They are compiled, packaged and deployed in a similar manner. Once this realization is in place we can see that instead of having multiple pipelines for each microservice (where each one is tied to a GIT repository), we have instead a single pipeline shared by all microservices.
+The basic idea is that all microservices of a single application have almost always the same lifecycle. They are compiled, packaged, and deployed in a similar manner. Once this realization is in place, we can see that instead of having multiple pipelines for each microservice, where each one is tied to a Git repository, we have instead a single pipeline shared by all microservices.
{% include image.html
lightbox="true"
@@ -94,7 +94,7 @@ The impact of this design cannot be understated. First of all, it should be clea
This makes pipeline construction very simple.
-The biggest advantage, however, is the way new projects are created. When a new microservice is added in an application, the pipeline is already there and only a new trigger is added for that microservice. Notice that the pipeline is not connected to any specific git repository anymore. All information for a repository is coming from the git trigger that started this pipeline.
+The biggest advantage, however, is the way new projects are created. When a new microservice is added in an application, the pipeline is already there and only a new trigger is added for that microservice. Notice that the pipeline is not connected to any specific Git repository anymore. All information for a repository is coming from the git trigger that started this pipeline.
As an operator you can bootstrap a new project by quickly adding a new trigger on an existing pipeline:
@@ -111,14 +111,14 @@ This is the fastest way possible to bootstrap a new project. As the number of mi
## Creating reusable pipelines
-When working with microservices you need to remember that
+When working with microservices you need to remember that:
-1. In Codefresh a pipeline can stand on its own. It is **not** connected by default to any git repository.
+1. In Codefresh a pipeline can stand on its own. It is **not** connected by default to any Git repository.
1. You can write Codefresh pipelines in a generic manner so that they can work with multiple applications.
-1. If you connect multiple triggers to a single pipeline, all microservices will share that pipeline
+1. If you connect multiple triggers to a single pipeline, all microservices will share that pipeline.
1. You can create multiple pipelines for each project if you have microservices with slightly different architecture.
-To create a reusable pipeline use the [generic form of the clone step]({{site.baseurl}}/docs/codefresh-yaml/steps/git-clone/):
+To create a reusable pipeline use the [generic form of the clone step]({{site.baseurl}}/docs/pipelines/steps/git-clone/):
`codefresh.yml`
{% highlight yaml %}
@@ -140,7 +140,7 @@ steps:
{% endraw %}
{% endhighlight %}
-This pipeline is using variables in the clone step. These variables will automatically be filled by the [respective trigger]({{site.baseurl}}/docs/configure-ci-cd-pipeline/triggers/git-triggers/). So you can connect this pipeline to any number of Java repositories and it will work on all of them (assuming they use Maven.)
+This pipeline uses variables in the clone step. These variables are automatically populated by the [respective trigger]({{site.baseurl}}/docs/pipelines/triggers/git-triggers/). So you can connect this pipeline to any number of Java repositories and it will work on all of them (assuming they use Maven).
{% include image.html
lightbox="true"
@@ -168,9 +168,9 @@ You can follow the same pattern for any other kind of application (NodeJS, Pytho
## Adding a new microservice to an existing application
-As an example, let's say that you have an application with 5 microservices. Two of them use Java and 3 use NodeJs. You can easily create 2 pipelines for the whole application (one for each programming language).
+As an example, let's say that you have an application with five microservices. Two of them use Java and three use NodeJs. You can easily create two pipelines for the whole application, one for each programming language.
-However, if you take advantage of [multi-stage Docker builds]({{site.baseurl}}/docs/ci-cd-guides/building-docker-images/#production-ready-docker-images-with-multi-stage-builds) you could even have a single pipeline for all 5 services:
+However, if you take advantage of [multistage Docker builds]({{site.baseurl}}/docs/ci-cd-guides/building-docker-images/#production-ready-docker-images-with-multi-stage-builds), you could even have a single pipeline for all five services:
`codefresh.yml`
{% highlight yaml %}
@@ -202,14 +202,14 @@ steps:
{% endraw %}
{% endhighlight %}
-This pipeline
+This pipeline:
1. Checks out source code from any connected trigger
-1. Creates a Docker image (assumes a multi-stage Dockerfile)
+1. Creates a Docker image (assumes a multistage Dockerfile)
1. Deploys the image to a Kubernetes cluster
-Now, if you add another microservice to the application you can simply add a new trigger making the addition as easy as possible:
+Now, if you add another microservice to the application, you can simply add a new trigger making the addition as easy as possible:
{% include image.html
lightbox="true"
@@ -223,12 +223,11 @@ max-width="80%"
This is just an example pipeline. You might have another generic pipeline for Helm deployments, FTP uploads, VM images and so on.
-## What to read next
-
-* [Creating pipelines]({{site.baseurl}}/docs/configure-ci-cd-pipeline/pipelines/)
-* [Git triggers]({{site.baseurl}}/docs/configure-ci-cd-pipeline/triggers/git-triggers/)
-* [Codefresh YAML]({{site.baseurl}}/docs/codefresh-yaml/what-is-the-codefresh-yaml/)
-* [Pipeline steps]({{site.baseurl}}/docs/codefresh-yaml/steps/)
+## Related articles
+[Creating pipelines]({{site.baseurl}}/docs/pipelines/pipelines/)
+[Git triggers in pipelines]({{site.baseurl}}/docs/pipelines/triggers/git-triggers/)
+[Codefresh YAML for pipeline definitions]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/)
+[Steps in pipelines]({{site.baseurl}}/docs/pipelines/steps/)
diff --git a/_docs/ci-cd-guides/packaging-compilation.md b/_docs/ci-cd-guides/packaging-compilation.md
index 292f95e39..c1767ba96 100644
--- a/_docs/ci-cd-guides/packaging-compilation.md
+++ b/_docs/ci-cd-guides/packaging-compilation.md
@@ -1,39 +1,43 @@
---
-title: "Build your app"
-description: "Learn how to compile and package traditional (non-Docker) artifacts"
+title: "Building your app"
+description: "Compile and package traditional (non-Docker) artifacts"
group: ci-cd-guides
toc: true
---
-When you use Codefresh for Continuous Integration, one of the most basic tasks is compiling and packaging applications. Even though Codefresh has native support for Docker artifacts, it still works great with traditional (non-dockerized) applications that don't use a Dockerfile for the actual build.
+When you use Codefresh for continuous integration (CI), one of the most basic tasks is compiling and packaging applications. Though Codefresh has native support for Docker artifacts, it still works great with traditional (non-Dockerized) applications that don't use a Dockerfile for the actual build.
->If your application is deployed as a Docker image then see the [Building Docker images guide]({{site.baseurl}}/docs/ci-cd-guides/building-docker-images/) instead.
+>If your application is deployed as a Docker image, see [building Docker images]({{site.baseurl}}/docs/ci-cd-guides/building-docker-images/) instead.
-## Using supporting Docker images in a CI/CD environment
+## Using supporting Docker images in CI/CD environment
-Unlike other CI solutions that you might be familiar with, Codefresh build nodes are very simple. They have only Docker installed and nothing else. When you run a Codefresh pipeline you choose the Docker images that will be used as a CI/CD environment. Once the pipeline runs, the Docker images are automatically launched by Codefresh and thus you have access to all the tools that they contain. Once the pipeline finishes, all Docker images that were used for the pipeline are discarded and the build machine reverts back to the original state.
+Unlike other CI solutions that you might be familiar with, Codefresh build nodes are very simple. They have only Docker installed and nothing else.
-So even if your application is not itself packaged as a Docker image, Codefresh pipelines are always "Docker-based" in the sense that Docker is used for the tools that take part in the pipeline.
+When you run a Codefresh pipeline, you choose the Docker images to be used in the CI/CD environment. Once the pipeline runs, the Docker images are automatically launched by Codefresh, and you have access to all the tools the images contain. When the pipeline completes its run, all Docker images used for the pipeline are discarded, and the build machine reverts to its original state.
+
+Even if your application is not itself packaged as a Docker image, Codefresh pipelines are always "Docker-based" in the sense that Docker is used for the tools that take part in the pipeline.
This approach has a lot of advantages:
- * There is no maintenance effort for build nodes. They only have Docker and nothing else.
- * You can use any tool in your pipeline that you want without actually installing it first
- * All public Docker images in Docker Hub are potential pipeline steps
- * You can use different versions of the same tool in the same pipeline
+ * No maintenance effort for build nodes, as they only have Docker and nothing else.
+ * You can use any tool in your pipeline that you want without actually installing it first.
+ * All public Docker images in Docker Hub are potential pipeline steps.
+ * You can use different versions of the same tool in the same pipeline.
* It is very easy to upgrade a tool to a new version (just change the tag of the Docker container used)
Notice also that unlike some other CI solutions:
-1. You can use multiple Docker images in the same pipeline (even if they contain the same tool) with no version conflicts
-1. You can use *any* Docker image. Docker images used in Codefresh pipelines have no special requirements so any public or private Docker image can be used in your pipeline.
+1. You can use multiple Docker images in the same pipeline, even if they contain the same tool, with no version conflicts
+1. As Docker images in Codefresh pipelines have no special requirements, you can use *any* private or public Docker image.
-All [pipeline steps]({{site.baseurl}}/docs/codefresh-yaml/steps/) in Codefresh are in fact Docker images.
+All [pipeline steps]({{site.baseurl}}/docs/pipelines/steps/) in Codefresh are in fact Docker images.
## Choosing programming tools as Docker images
-In practice this means that if you have a Node application, you need to use a [Node image]({{site.baseurl}}/docs/learn-by-example/nodejs) to package your application, a [Maven image]({{site.baseurl}}/docs/learn-by-example/java/spring-boot-2/) if you are working with Java, a [Python]({{site.baseurl}}/docs/learn-by-example/python/) image for python applications, and so on. You launch the image using the Codefresh freestyle step. Here is an example for Node:
+In practice, this means that if you have a Node application, you need to use a [Node image]({{site.baseurl}}/docs/example-catalog/#ci-examples) to package your application, a [Maven image]({{site.baseurl}}/docs/example-catalog/ci-examples/spring-boot-2/) if you are working with Java, a [Python]({{site.baseurl}}/docs/example-catalog/ci-examples/python/) image for Python applications, and so on.
+
+You launch the image using the Codefresh freestyle step. Here is an example for Node:
`codefresh.yml`
{% highlight yaml %}
@@ -47,9 +51,9 @@ steps:
- npm run test
{% endhighlight %}
-This pipeline will download the `node:11` image on the Codefresh build machine, launch it, and pass it your source code. Then it will run the commands `npm install` and `npm run test`. The result is that your source code can be packaged without actually installing Node.js on the build machine beforehand.
+This pipeline downloads the `node:11` image to the Codefresh build machine, launches it, and passes it to your source code. It then runs the commands `npm install` and `npm run test`. The result is that your source code can be packaged without actually installing Node.js on the build machine beforehand.
-You can mix and max different images on the same pipeline. Let's say for example that you have a single repository that contains a front-end in Node.js and a back-end in Java. You can easily create a pipeline that deals with both:
+You can mix and match different images in the same pipeline. Let's say for example that you have a single repository that contains a front-end in Node.js and a back-end in Java. You can easily create a pipeline that deals with both:
`codefresh.yml`
{% highlight yaml %}
@@ -70,11 +74,12 @@ steps:
- mvn -Dmaven.repo.local=/codefresh/volume/m2_repository package
{% endhighlight %}
-This pipeline will compile the Java code under the `back-end` folder and the Javascript Web application found in the `front-end` folder. Note that both Docker images have access to the same workspace via [the automatic Codefresh volume]({{site.baseurl}}/docs/configure-ci-cd-pipeline/introduction-to-codefresh-pipelines/#sharing-the-workspace-between-build-steps).
+This pipeline compiles the Java code under the `back-end` folder, and the Javascript Web application found in the `front-end` folder. Both Docker images have access to the same workspace via [the shared Codefresh volume]({{site.baseurl}}/docs/pipelines/introduction-to-codefresh-pipelines/#sharing-the-workspace-between-build-steps).
-Therefore if you want to use Codefresh as fast as possible you can simply search Dockerhub for an existing image that uses the tool that you need. Top- level DockerHub images are curated by the Docker team and are considered safe. So for most popular programming languages, there is already a Docker image that you can use in your pipeline.
+To get up and running with Codefresh as quickly as possible, you can simply search DockerHub for an existing image that uses the tool you need. Top-level DockerHub images are curated by the Docker team and are considered safe. So most popular programming languages already have a Docker image that you can use in your pipeline.
-Of course, you can also [create your private Docker image or use any existing image]({{site.baseurl}}/docs/docker-registries/working-with-docker-registries/) from a private or public Registry. In that case, you need to write the full name to the image used. For example, if you use an image from GCR or another private registry you mention it like this:
+Of course, you can also [create your private Docker image or use any existing image]({{site.baseurl}}/docs/ci-cd-guides/working-with-docker-registries/) from a private or public registry. In that case, you need to write the full name of the image used.
+If you use an image from GCR (Google Container Registry), or another private registry, you would specify it as in the example below.
`codefresh.yml`
{% highlight yaml %}
@@ -92,7 +97,7 @@ steps:
- jasmine init
{% endhighlight %}
-In this pipeline Docker images have a full prefix, so they are pulled by the respective registry instead of DockerHub.
+In this pipeline, Docker images have a full prefix, so they are pulled by the respective registry instead of DockerHub.
In this manner, you can run any tool in any Codefresh pipeline as long as it is offered in a Docker image. This means that Codefresh pipelines can work with any programming language and any tool that you can use on your workstation.
@@ -101,9 +106,10 @@ Unlike other CI solutions, you don't need to wait for the Codefresh team to add
## Using multiple Docker images in a single pipeline
-Notice that unlike other CI solutions, there is no limit on the Docker images that you can use in a single pipeline. Also, all Docker images that take part in the same pipeline, have access to the same project workspace via the [shared Codefresh volume]({{site.baseurl}}/docs/configure-ci-cd-pipeline/introduction-to-codefresh-pipelines/#sharing-the-workspace-between-build-steps).
+Unlike other CI solutions, there is no limit on the number of Docker images that you can use in a single pipeline. Also, all Docker images included in the same pipeline have access to the same project workspace via the [shared Codefresh volume]({{site.baseurl}}/docs/pipelines/introduction-to-codefresh-pipelines/#sharing-the-workspace-between-build-steps).
+This means that you have maximum flexibility on what tools you use in a single project.
-This means that you have maximum flexibility on what tools you use in a single project. As an example, let's see a pipeline that is using 4 different images for a single project.
+As an example, let's see a pipeline that uses four different images for a single project.
`codefresh.yml`
@@ -143,20 +149,20 @@ steps:
- aws s3 sync ./target/app.jar s3://my-bucket/my-jar --delete
{% endhighlight %}
-This pipeline is doing the following:
+This pipeline does the following:
-1. Checking out source code
-1. Packaging a Jar file (from the source code)
-1. Running Sonar analysis (taking into account both source code and compiled classes)
-1. Creating a storage bucket in AWS
-1. Uploading the JAR that was packaged in the bucket.
+1. Checks out source code
+1. Packages a Jar file (from the source code)
+1. Runs Sonar analysis (taking into account both source code and compiled classes)
+1. Creates a storage bucket in AWS (Amazon Web Services)
+1. Uploads the JAR that was packaged in the bucket
Notice how all Docker images use the same workspace without any extra configuration on your part.
## Using different tool versions in the same pipeline
The corollary to Docker-based pipelines is that you can use the same tool but with a different version in the **same** pipeline.
-As an example here is a pipeline that runs both Python 2.x and Python 3.x in the same pipeline and it just works.
+As an example, here is a pipeline that runs both Python 2.x and Python 3.x, and it just works.
`codefresh.yml`
{% highlight yaml %}
@@ -175,8 +181,11 @@ steps:
- pytest
{% endhighlight %}
-This means that you can easily choose the specific version that matches each of your projects. Here is another example
-where two different applications use Node.js 11 and Node.js 9 in the same pipeline.
+You can easily choose the specific version that matches each of your projects.
+
+
+
+Here is another example where two different applications use Node.js 11 and Node.js 9 in the same pipeline.
`codefresh.yml`
{% highlight yaml %}
@@ -205,10 +214,9 @@ steps:
- npm install
{% endhighlight %}
-Notice that these versions are per pipeline. So you can have each team using the versions they like for their projects
-without affecting each other.
+> These versions are per pipeline. So each team can use the versions they need for their projects without affecting the other teams.
-So one team in your company might use terraform 0.10 in their pipelines
+So one team in your company might use Terraform 0.10 in their pipelines:
{% highlight yaml %}
@@ -220,7 +228,7 @@ So one team in your company might use terraform 0.10 in their pipelines
- terraform plan
{% endhighlight %}
-...while another team is using terraform 0.12 just by changing the YAML of their codefresh.yml
+Another team can use Terraform 0.12 just by changing the YAML of their `codefresh.yml`:
{% highlight yaml %}
DeployWithTerraform:
@@ -232,16 +240,15 @@ So one team in your company might use terraform 0.10 in their pipelines
{% endhighlight %}
-In summary, it is very easy to use any version of any programming tool in a Codefresh pipeline without the fear of breaking
+To summarize, you can easily use any version of any programming tool in a Codefresh pipeline without the fear of breaking
another unrelated pipeline.
-## What to read next
-
-* [How pipelines work]({{site.baseurl}}/docs/configure-ci-cd-pipeline/introduction-to-codefresh-pipelines/)
-* [Creating pipelines]({{site.baseurl}}/docs/configure-ci-cd-pipeline/pipelines/)
-* [Codefresh YAML]({{site.baseurl}}/docs/codefresh-yaml/what-is-the-codefresh-yaml/)
-* [Pipeline steps]({{site.baseurl}}/docs/codefresh-yaml/steps/)
+## Related articles
+[Introduction to Codefresh pipelines]({{site.baseurl}}/docs/pipelines/introduction-to-codefresh-pipelines/)
+[Creating Codefresh pipelines]({{site.baseurl}}/docs/pipelines/pipelines/)
+[Codefresh YAML for pipeline definitions]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/)
+[Steps in pipelines]({{site.baseurl}}/docs/pipelines/steps/)
diff --git a/_docs/ci-cd-guides/preview-environments.md b/_docs/ci-cd-guides/preview-environments.md
index 4097d557a..d8cdb2824 100644
--- a/_docs/ci-cd-guides/preview-environments.md
+++ b/_docs/ci-cd-guides/preview-environments.md
@@ -1,14 +1,13 @@
---
-title: "Preview Environments"
-description: "Deploy Pull Requests to cluster namespaces"
+title: "Previewing dynamic environments"
+description: "Deploy pull requests to cluster namespaces"
group: ci-cd-guides
toc: true
---
-In the [previous guide]({{site.baseurl}}/docs/ci-cd-guides/environment-deployments/) we have seen how you can handle deployments to predefined environments (QA/Staging/production).
-Another type of environments that you should manage is dynamic temporary environments for each pull request. For this type
-of environments it is best if you create dynamically an environment when a Pull Request is created and tear it down when the Pull Request is closed.
+In addition to deploying to [predefined environments]({{site.baseurl}}/docs/ci-cd-guides/environment-deployments/), for each pull request (PR), you may also need to deploy to dynamic environments, which are temporary, testing environments. For these types of environments, it is best to dynamically create an environment when a PR is created, and tear it down when the same PR is closed.
+
{% include image.html
lightbox="true"
@@ -19,7 +18,7 @@ caption="Dynamic Test environments"
max-width="90%"
%}
-This way each developer is working in isolation and can test their feature on its own. This pattern comes in contrast with the traditional way of reusing static preexisting environments.
+Each developer works in isolation to test their features. This pattern contrasts with the traditional way of reusing static preexisting environments.
{% include image.html
lightbox="true"
@@ -35,35 +34,34 @@ be handled in a transient way.
## Preview environments with Kubernetes
-There are many ways to create temporary environments with Kubernetes, but the simplest one is to use
-different namespaces, one for each pull request. So a pull request with name `fix-db-query` will
-be deployed to a namespace called `fix-db-query`, a pull request with name `JIRA-1434` will be deployed to a namespace called
-`JIRA-1434` and so on.
-
-The second aspect is exposing the environment URL so that developers and testers can actually preview the application
-deployment either manually or via automated tests.
+There are many options to create temporary environments with Kubernetes.
-The two major approaches here are with host-based URLs or path based URLs.
+* Namespaces for each PR
+ The simplest option is to use different namespaces, one for each PR. So, a PR with name `fix-db-query` is deployed to a namespace called `fix-db-query`, and a PR with name `JIRA-1434`, is deployed to a namespace called `JIRA-1434` and so on.
-* In host based urls, the test environments are named `pr1.example.com`, `pr2.example.com` and so on
-* with path based URLs, the test environments are named `example.com/pr1` , `example.com/pr2` and so on
+* Expose the environment URL
+ The second option is to expose the environment URL so that developers and testers can actually preview the application
+deployment either manually or via automated tests.
+ The two major approaches here are with host-based and path-based URLs:
+ * For host-based URLs, the test environments are named `pr1.example.com`, `pr2.example.com` and so on
+ * For path-based URLs, the test environments are named `example.com/pr1`, `example.com/pr2` and so on
-Both approaches have advantages and disadvantages. Path based URLs are easier to setup but may not work with all applications (since they change the web context). Host based URLs are more robust but need extra
-DNS configuration for the full effect.
+ Both approaches have advantages and disadvantages. Path-based URLs are easier to set up, but may not work with all applications, as they change the web context. Host-based URLs are more robust but need extra DNS configuration for the full effect.
-In Kubernetes clusters, both ways can be setup via [an Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/).
+ In Kubernetes clusters, you can set up types of URLs via [an Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/){:target="\_blank"}.
-## The example application
+## Example application
-The application we will use can be found at [https://github.com/codefresh-contrib/unlimited-test-environments-source-code](https://github.com/codefresh-contrib/unlimited-test-environments-source-code). It is a standard Java/Spring boot application with the following characteristics.
+You can find the application we will use at [https://github.com/codefresh-contrib/unlimited-test-environments-source-code](https://github.com/codefresh-contrib/unlimited-test-environments-source-code){:target="\_blank"}.
+It is a standard Java/Spring boot application, that includes the following characteristics:
* It has [integration tests]({{site.baseurl}}/docs/testing/integration-tests/) that can be targeted at any host/port. We will use those tests as smoke test that will verify the preview environment after it is deployed
-* It comes bundled in [a Helm chart](https://github.com/codefresh-contrib/unlimited-test-environments-manifests)
-* It has an ingress configuration ready for path based URLs
+* It comes bundled in a [Helm chart](https://github.com/codefresh-contrib/unlimited-test-environments-manifests){:target="\_blank"}
+* It has an ingress configuration ready for path-based URLs
-We are using [the Ambassador gateway](https://www.getambassador.io/) as an ingress for this example, but you can use any other compliant Kubernetes Ingress.
+We are using the [Ambassador gateway](https://www.getambassador.io/){:target="\_blank"} as an ingress for this example, but you can use any Kubernetes-compliant ingress.
-Here is the [ingress manifest](https://github.com/codefresh-contrib/unlimited-test-environments-manifests/blob/main/simple-java-app/templates/ingress.yaml)
+Here is the [ingress manifest](https://github.com/codefresh-contrib/unlimited-test-environments-manifests/blob/main/simple-java-app/templates/ingress.yaml){:target="\_blank"}.
{% highlight yaml %}
{% raw %}
@@ -87,14 +85,13 @@ spec:
The path of the application is configurable and can be set at deploy time.
-## Creating preview environments for each pull request
+## Creating preview environments for each PR
-Each time a Pull Request is created we want to perform the following tasks:
+Each time a PR is created, we want to perform the following tasks:
-1. Compile the application and run unit tests
-1. Run security scans, quality checks and everything else we need to decided if the Pull request is valid
-1. Create a namespace with the same name as the pull request branch. Deploy the pull Request and expose it as a URL
-that has the same name as the branch as well
+1. Compile the application and run unit tests.
+1. Run security scans, quality checks, and everything else we need to decide if the PR is valid.
+1. Create a namespace with the same name as the PR branch. Deploy the PR and expose it as a URL that has the same name as the branch.
Here is an example pipeline that does all these tasks:
@@ -107,23 +104,23 @@ caption="Pull Request preview pipeline"
max-width="100%"
%}
-This pipeline has the following steps
+This pipeline has the following steps:
-1. A [clone step]({{site.baseurl}}/docs/codefresh-yaml/steps/git-clone/) to fetch the source code of the application
-1. A [freestyle step]({{site.baseurl}}/docs/codefresh-yaml/steps/freestyle/) that runs Maven for compilation and unit tests
-1. A [build step]({{site.baseurl}}/docs/codefresh-yaml/steps/build/) to create the docker image of the application
-1. A step that scans the source code for security issues with [Snyk](https://snyk.io/)
-1. A step that scans the container image [for security issues]({{site.baseurl}}/docs/testing/security-scanning/) with [trivy](https://github.com/aquasecurity/trivy)
-1. A step that runs [integration tests]({{site.baseurl}}/docs/testing/integration-tests/) by launching the app in a [service container]({{site.baseurl}}/docs/codefresh-yaml/service-containers/)
-1. A step for [Sonar analysis]({{site.baseurl}}/docs/testing/sonarqube-integration/)
-1. A step that clones [a second Git repository](https://github.com/codefresh-contrib/unlimited-test-environments-manifests) that has the [Helm chart]({{site.baseurl}}/docs/new-helm/using-helm-in-codefresh-pipeline/) of the app
+1. A [clone step]({{site.baseurl}}/docs/pipelines/steps/git-clone/) to fetch the source code of the application.
+1. A [freestyle step]({{site.baseurl}}/docs/pipelines/steps/freestyle/) that runs Maven for compilation and unit tests.
+1. A [build step]({{site.baseurl}}/docs/pipelines/steps/build/) to create the Docker image of the application.
+1. A step that scans the source code for security issues with [Snyk](https://snyk.io/){:target="\_blank"}.
+1. A step that scans the container image [for security issues]({{site.baseurl}}/docs/testing/security-scanning/) with [trivy](https://github.com/aquasecurity/trivy){:target="\_blank"}.
+1. A step that runs [integration tests]({{site.baseurl}}/docs/testing/integration-tests/) by launching the app in a [service container]({{site.baseurl}}/docs/pipelines/service-containers/).
+1. A step for [Sonar analysis]({{site.baseurl}}/docs/testing/sonarqube-integration/).
+1. A step that clones [a second Git repository](https://github.com/codefresh-contrib/unlimited-test-environments-manifests){:target="\_blank"} with the [Helm chart]({{site.baseurl}}/docs/deployments/helm/using-helm-in-codefresh-pipeline/) of the application.
1. A step that deploys the source code to a new namespace.
-1. A step that [adds a comment on the Pull Request](https://codefresh.io/steps/step/kostis-codefresh%2Fgithub-pr-comment) with the URL of the temporary environment
-1. A step that runs smoke tests against the temporary test environment
+1. A step that [adds a comment on the PR](https://codefresh.io/steps/step/kostis-codefresh%2Fgithub-pr-comment){:target="\_blank"} with the URL of the temporary environment.
+1. A step that runs smoke tests against the temporary test environment.
-Note that the integration tests and security scans are just examples of what you can do before the Pull Request is deployed. You can insert your own steps that check the contents of a Pull Request.
+Note that the integration tests and security scans are just examples of what you can do before the PR is deployed. You can insert your own steps that check the content of a PR.
-Here is the whole YAML definition
+Here is the complete YAML definition:
`codefresh.yml`
{% highlight yaml %}
@@ -234,8 +231,8 @@ steps:
{% endraw %}
{% endhighlight %}
-The end result of the pipeline is a deployment on the path that has the same name as the pull request branch. For
-example if my branch is named `demo` then a demo namespace is created on the cluster and the application
+The end result of the pipeline is a deployment to the path that has the same name as the PR branch. For
+example, if my branch is named `demo`, then a `demo` namespace is created on the cluster and the application
is exposed on the `/demo/` context:
{% include image.html
@@ -247,7 +244,7 @@ caption="Temporary environment"
max-width="100%"
%}
-The environment is also mentioned as a comment in the Pull Request UI in Github:
+The environment is also mentioned as a comment in the PR UI in GitHub:
{% include image.html
lightbox="true"
@@ -258,8 +255,8 @@ caption="Pull Request comment"
max-width="100%"
%}
-As explained it the [previous guide for Pull Requests]({{site.baseurl}}/docs/ci-cd-guides/pull-request-branches/), we want to make this pipeline applicable only
-to PR open event and PR sync events (which capture commits that happen on an existing pull request).
+As explained in [Pull Requests and branches guide]({{site.baseurl}}/docs/ci-cd-guides/pull-request-branches/), we want to make this pipeline applicable only
+to a PR-open event and PR-sync events that capture commits on an existing pull request.
{% include image.html
lightbox="true"
@@ -270,14 +267,14 @@ caption="Git events for a Pull Request preview pipeline"
max-width="100%"
%}
-Therefore you need to setup your [triggers]({{site.baseurl}}/docs/configure-ci-cd-pipeline/triggers/git-triggers/) with the same checkboxes shown in the picture above.
+Therefore, you need to set up your [Git triggers]({{site.baseurl}}/docs/pipelines/triggers/git-triggers/) with the same options selected as shown in the picture above.
## Cleaning up temporary environments
-Creating temporary environments is very convenient for developers but can be very costly for your infrastructure if you use a cloud
-provider for your cluster. For cost reasons and better resource utilization it is best if temporary environments are destroyed if they are no longer used.
+Creating temporary environments is very convenient for developers, but can be very costly for your infrastructure if you use a cloud
+provider for your cluster. For cost reasons and better resource utilization, it is best to destroy temporary environments that are no longer used.
-While you can run a batch job, that automatically deletes old temporary environments, the optimal approach is to delete them as soon as the respective Pull Request is closed.
+While you can run a batch job that automatically deletes old temporary environments, the optimal approach is to delete them as soon as the respective PR is closed.
We can do that with a very simple pipeline that has only one step:
@@ -311,9 +308,9 @@ steps:
{% endraw %}
{% endhighlight %}
-The pipeline just uninstalls the Helm release for that namespace and then deletes the namespace itself.
+The pipeline just uninstalls the Helm release for that namespace, and then deletes the namespace itself.
-To have this pipeline run only when a Pull Request is closed here is how your [trigger]({{site.baseurl}}/docs/configure-ci-cd-pipeline/triggers/git-triggers/) should look:
+To have this pipeline run only when a PR is closed, here are the triggers to select:
{% include image.html
lightbox="true"
@@ -324,24 +321,25 @@ caption="Git events for a Pull Request close pipeline"
max-width="100%"
%}
-Notice that with this setup the pipeline will run when the pull request was closed regardless of whether it was merged or not (which is exactly what you want as in both cases the test environment is not needed anymore).
+With this setup, the pipeline runs when the PR is closed, regardless of whether it was merged or not (which is exactly what you want as in both cases the test environment is not needed anymore).
-## Seeing all environments in the Codefresh GUI
+## Viewing all environments in the Codefresh UI
-You can combine the pipeline above with any Codefresh GUI dashboard
-if you want to see all your temporary environments in a single view.
+You can combine the pipeline above with any Codefresh UI dashboard if you want to see all your temporary environments in a single view.
-For more information see the documentation on dashboards such as the [Environment dashboard]({{site.baseurl}}/docs/deploy-to-kubernetes/environment-dashboard/), the [Helm promotion dashboard]({{site.baseurl}}/docs/new-helm/helm-environment-promotion/) and the [GitOps dashboard]({{site.baseurl}}/docs/ci-cd-guides/gitops-deployments/#working-with-the-gitops-dashboard)
+For more information, see:
+* [Environment dashboard]({{site.baseurl}}/docs/deployments/kubernetes/environment-dashboard/)
+* [Helm promotion dashboard]({{site.baseurl}}/docs/deployments/helm/helm-environment-promotion/)
+* [GitOps dashboard]({{site.baseurl}}/docs/ci-cd-guides/gitops-deployments/#working-with-the-gitops-dashboard)
-## What to read next
+## Related articles
+[How Codefresh pipelines work]({{site.baseurl}}/docs/pipelines/introduction-to-codefresh-pipelines/)
+[Codefresh YAML for pipeline definitions]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/)
+[Steps in pipelines]({{site.baseurl}}/docs/pipelines/steps/)
+[Docker registry integrations for pipelines]({{site.baseurl}}/docs/integrations/docker-registries/)
-* [How Codefresh pipelines work]({{site.baseurl}}/docs/configure-ci-cd-pipeline/introduction-to-codefresh-pipelines/)
-* [Codefresh YAML]({{site.baseurl}}/docs/codefresh-yaml/what-is-the-codefresh-yaml/)
-* [Pipeline steps]({{site.baseurl}}/docs/codefresh-yaml/steps/)
-* [Working with Docker registries]({{site.baseurl}}/docs/docker-registries/working-with-docker-registries/)
-* [Build step]({{site.baseurl}}/docs/codefresh-yaml/steps/build/)
diff --git a/_docs/ci-cd-guides/progressive-delivery.md b/_docs/ci-cd-guides/progressive-delivery.md
index b32e13671..58445f9d6 100644
--- a/_docs/ci-cd-guides/progressive-delivery.md
+++ b/_docs/ci-cd-guides/progressive-delivery.md
@@ -1,32 +1,32 @@
---
title: "Progressive Delivery"
-description: "Learn how to perform zero downtime deployments with Argo Rollouts"
+description: "Perform zero downtime deployments with Argo Rollouts"
group: ci-cd-guides
redirect_from:
+ - /docs/ci-cd-guides/progressive-delivery/
- /docs/how-to-guides/implementing-canary-release-with-kubernetes/
toc: true
---
-Progressive Delivery is the practice of deploying an application in a gradual manner allowing for minimum downtime and easy rollbacks. There are several forms of progressive delivery such as blue/green, canary, a/b and feature flags.
+Progressive Delivery is the practice of deploying an application in a gradual manner, allowing for minimum downtime and easy rollbacks. There are several forms of progressive delivery such as blue/green, canary, a/b, and feature flags.
-Codefresh can easily integrate with [Argo Rollouts](https://argoproj.github.io/argo-rollouts/), a Kubernetes operator that natively covers progressive delivery deployment practices.
+Codefresh can easily integrate with [Argo Rollouts](https://argoproj.github.io/argo-rollouts/){:target="\_blank"}, a Kubernetes operator that natively supports deployment practices for progressive delivery.
## Installing the Argo Rollouts operator to your cluster
-To install Argo Rollouts follow the [installation instructions](https://argoproj.github.io/argo-rollouts/installation/). Essentially you need a terminal with `kubectl` access to your cluster.
+To install Argo Rollouts, follow the [installation instructions](https://argoproj.github.io/argo-rollouts/installation/){:target="\_blank"}. Essentially, you need a terminal with `kubectl` access to your cluster.
```
kubectl create namespace argo-rollouts
kubectl apply -n argo-rollouts -f https://raw.githubusercontent.com/argoproj/argo-rollouts/stable/manifests/install.yaml
```
-You can optionally install the [CLI locally](https://github.com/argoproj/argo-rollouts/releases/latest) if you want to have more visibility in your deployments.
+You can optionally install the [CLI locally](https://github.com/argoproj/argo-rollouts/releases/latest){:target="\_blank"}, if you want to have more visibility in your deployments.
-## Blue Green deployments
+## Blue/Green deployments
-Blue/Green deployments are one of the simplest ways to minimize deployment downtime. Blue/Green deployments are not specific to Kubernetes and can be used
-even for traditional applications that reside on Virtual Machines.
+Blue/Green deployments are one of the simplest ways to minimize deployment downtime. Blue/Green deployments are not specific to Kubernetes, and can be used even for traditional applications that reside on Virtual Machines.
{% include image.html
lightbox="true"
@@ -37,26 +37,23 @@ caption="Blue/Green Deployments"
max-width="50%"
%}
-1. In the beginning all users of the application are routed to the current version (shown as blue color). A key point is that all traffic passes from a load balancer
-1. A new version is deployed (shown as green color). This version does not receive any live traffic so all users are still served by the previous/stable version
-1. Developers can test internally the new color and verify its correctness. If it is valid, traffic is switched to that new version
-1. If everything goes well the old version is discarded completely. We are back to initial state (order of colors does not matter)
+1. At first all users of the application are routed to the current version (shown in blue). A key point is that all traffic passes from a load balancer.
+1. A new version is deployed (shown in green). As this version does not receive any live traffic, all users are still served by the previous/stable version.
+1. Developers can test internally the new green version, and verify its validity. If it is valid, traffic is switched to that new version.
+1. If everything goes well, the old version is completely discarded. We are back to the initial state (order of colors does not matter).
-The major benefit of this pattern is that if at any point in time the new version has issues, all users can be switched back to the previous version (via the load balancer). Switching the load balancer is much faster than redeploying a new version, resulting in minimum disruption for existing users.
+The major benefit of this pattern is that if at any point in time the new version has issues, all users can be switched back to the previous version (via the load balancer). Switching via the load balancer is much faster than redeploying a new version, resulting in minimum disruption for existing users.
-There are several variations of this pattern. In some cases the old color is never destroyed but keeps running in the background. You can also
-keep even older versions online (maybe with a smaller footprint) allowing for easy switching to any previous application revision.
+There are several variations of this pattern. In some cases, the old color is never destroyed but keeps running in the background. You can also retain even older versions online, maybe with a smaller footprint, allowing for easy switching to any previous application revision.
### Blue/Green Kubernetes Deployment with Argo Rollouts
-
-
-Even though Argo Rollouts supports the basic blue/green pattern described in the previous section, it also offers a wealth of [customization options](https://argoproj.github.io/argo-rollouts/features/bluegreen/). One of the most important
-additions is the ability to "test" the upcoming color by introducing a "preview" [Kubernetes service](https://kubernetes.io/docs/concepts/services-networking/service/), in addition to the service used for live traffic.
+Even though Argo Rollouts supports the basic blue/green pattern described in the previous section, it also offers a wealth of [customization options](https://argoproj.github.io/argo-rollouts/features/bluegreen/){:target="\_blank"}.
+One of the most important additions is the ability to "test" the upcoming color by introducing a "preview" [Kubernetes service](https://kubernetes.io/docs/concepts/services-networking/service/){:target="\_blank"}, in addition to the service used for live traffic.
This preview service can be used by the team that performs the deployment to verify the new version before actually switching the traffic.
-Here is the initial state of a deployment. The example uses 2 pods (shown as `xnsdx` and `jftql` in the diagram).
+Here is the initial state of a deployment. The example uses two pods (shown as `xnsdx` and `jftql` in the diagram).
{% include image.html
lightbox="true"
@@ -67,11 +64,12 @@ caption="Initial deployment. All services point to active version"
max-width="90%"
%}
-There are two Kubernetes services . The `rollout-blue-gree-active` is capturing all live traffic from actual users of the application (internet traffic coming from `51.141.221.40`). There is also a secondary service
-called `rollout-bluegreen-preview`. Under normal circumstances it also points to the same live version.
+There are two Kubernetes services:
+* A `rollout-blue-gree-active` service that captures all live traffic from actual users of the application (internet traffic coming from `51.141.221.40`).
+* A secondary service called `rollout-bluegreen-preview`. Under normal circumstances it also points to the same live version.
-Once a deployment starts a new "color" is created. In the example we have 2 new pods that represent the next version of the application to be deployed (shown as `9t67t` and `7vs2m`).
+Once a deployment starts, a new "color" is created. In the example we have two new pods that represent the next version of the application to be deployed (shown as `9t67t` and `7vs2m`).
{% include image.html
lightbox="true"
@@ -82,7 +80,7 @@ caption="Deployment in progress. Active users see old version. Internal users pr
max-width="90%"
%}
-The important point here is the fact that the normal "active" service still points to the old version while the "preview" service points to the new pods. This means that all active users are still on the old/stable deployment while internal teams can use the "preview" service to test the new deployment.
+The important point here is the fact that the normal "active" service still points to the old version, while the "preview" service points to the new pods. This means that all active users are still on the old/stable deployment, while internal teams can use the "preview" service to test the new deployment.
If everything goes well, the next version is promoted to be the active version.
@@ -95,7 +93,7 @@ caption="Next application version is promoted. All users see new version"
max-width="90%"
%}
-Here both services point to the new version. This is also the critical moment for all real users of the application, as they are now switched to use the new version of the application. The old version is still around but no traffic is sent to it.
+Here both services point to the new version. This is also the critical moment for all actual users of the application, as they are now switched to use the new version of the application. The old version is still around but no traffic is sent to it.
Having the old version around is a great failsafe, as one can abort the deployment process and switch back all active users to the old deployment in the fastest way possible.
@@ -108,16 +106,15 @@ caption="Old application version is discarded. Only new version remains."
max-width="90%"
%}
-After some time (the exact amount is [configurable in Argo Rollouts](https://argoproj.github.io/argo-rollouts/features/bluegreen/#scaledowndelayseconds)) the old version is scaled down completely (to preserve resources). We are now back
+After the configured duration, as [defined in Argo Rollouts](https://argoproj.github.io/argo-rollouts/features/bluegreen/#scaledowndelayseconds){:target="\_blank"}, the old version is scaled down completely to preserve resources. We are now back
to the same configuration as the initial state, and the next deployment will follow the same sequence of events.
-### The example application
+### Example application
-You can find an example application at [https://github.com/codefresh-contrib/argo-rollout-blue-green-sample-app](https://github.com/codefresh-contrib/argo-rollout-blue-green-sample-app) that also includes simple integration tests.
+You can find an example application at [https://github.com/codefresh-contrib/argo-rollout-blue-green-sample-app](https://github.com/codefresh-contrib/argo-rollout-blue-green-sample-app){:target="\_blank"}, that also includes simple integration tests.
-Notice that the first deployment of your application will NOT follow the blue/green deployment process as there is no "previous" color. So you need to deploy it at least
-once.
+Notice that the first deployment of your application will NOT follow the blue/green deployment process as there is no "previous" color. So you need to deploy it at least once.
```
git clone https://github.com/codefresh-contrib/argo-rollout-blue-green-sample-app.git
@@ -126,7 +123,7 @@ kubectl create ns blue-green
kubectl apply -f ./blue-green-manual-approval -n blue-green
```
-You can then monitor what argo rollouts is doing with the following command:
+You can then monitor what Argo Rollouts is doing with the following command:
```
kubectl argo rollouts get rollout spring-sample-app-deployment --watch -n blue-green
@@ -134,8 +131,8 @@ kubectl argo rollouts get rollout spring-sample-app-deployment --watch -n blue-g
### Blue/Green deployment with manual approval
-A quick way to use blue/green deployments is by simply inserting [an approval step]({{site.baseurl}}/docs/codefresh-yaml/steps/approval/) before the traffic switch step.
-This will pause the pipeline and the developers or QA can test the next version on their own before any real users are redirected to it.
+A quick way to use blue/green deployments is by simply inserting [an approval step]({{site.baseurl}}/docs/pipelines/steps/approval/) before the traffic switch step.
+This will pause the pipeline and the developers or QA can test the next version on their own before any live users are redirected to it.
Here is an example pipeline:
@@ -150,14 +147,14 @@ max-width="100%"
This pipeline does the following:
-1. [Clones]({{site.baseurl}}/docs/yaml-examples/examples/git-checkout/) the source code of the application
-1. [Builds]({{site.baseurl}}/docs/ci-cd-guides/building-docker-images/) a docker image
-1. [Deploys]({{site.baseurl}}/docs/deploy-to-kubernetes/kubernetes-templating/) the application by updating the Kubernetes manifests. Argo Rollouts sees the new manifest and creates a new "color" for the next version
-1. The pipeline is paused and waits for an [approval/rejection]({{site.baseurl}}/docs/codefresh-yaml/steps/approval/#getting-the-approval-result) by a human user.
-1. If the pipeline is approved the new color is promoted and becomes the new active version
-1. If the pipeline is rejected the new color is discarded the all live users are not affected in any way
+1. [Clones]({{site.baseurl}}/docs/example-catalog/ci-examples/git-checkout/) the source code of the application.
+1. [Builds]({{site.baseurl}}/docs/ci-cd-guides/building-docker-images/) a Docker image.
+1. [Deploys]({{site.baseurl}}/docs/ci-cd-guides/kubernetes-templating/) the application by updating the Kubernetes manifests. Argo Rollouts sees the new manifest, and creates a new "color" for the next version
+1. The pipeline is paused and waits for an [approval/rejection]({{site.baseurl}}/docs/pipelines/steps/approval/#getting-the-approval-result) by a human user.
+1. If the pipeline is approved, the new color is promoted, and becomes the new active version.
+1. If the pipeline is rejected, the new color is discarded, and all live users are not affected in any way.
-Here is the [pipeline definition]({{site.baseurl}}/docs/codefresh-yaml/what-is-the-codefresh-yaml/):
+Here is the [pipeline definition]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/):
`codefresh.yml`
{% highlight yaml %}
@@ -227,13 +224,13 @@ steps:
{% endraw %}
{% endhighlight %}
-Just before the approval you can optionally execute the Argo Rollouts CLI to see what is happening behind the scenes:
+Just before the approval, you can optionally execute the Argo Rollouts CLI to see what is happening behind the scenes:
```
kubectl argo rollouts get rollout spring-sample-app-deployment --watch -n blue-green
```
-It should show the new color come up (but not accepting any traffic).
+It should show the new color come up, but not accepting any traffic.
{% include image.html
lightbox="true"
@@ -244,22 +241,20 @@ caption="Argo Rollouts CLI"
max-width="100%"
%}
-After the deployment has finished, the old pods will be destroyed after 30 seconds (this is the default value of Argo Rollouts).
+Once the deployment is complete, the old pods are destroyed after 30 seconds (this is the default value of Argo Rollouts).
### Blue/Green deployment with smoke tests
-Using manual approval before promoting the new version is a great starting point. To truly achieve continuous deployment one should automate the testing process
-and eliminate the human approval.
+Using manual approval before promoting the new version is a great starting point. To truly achieve continuous deployment, one should automate the testing process and eliminate the human approval.
-There are many approaches on testing a release and each organization will have a different set of "tests" that verify the next version of the software. Argo Rollouts
-has [several integrations](https://argoproj.github.io/argo-rollouts/features/analysis/) either with metric providers or [simple Kubernetes jobs](https://argoproj.github.io/argo-rollouts/analysis/job/) that can run integration tests or collect metrics and decide if the next color should be promoted or not.
+There are many approaches on testing a release, and each organization will have a different set of "tests" that verify the next version of the software. Argo Rollouts
+has [several integrations](https://argoproj.github.io/argo-rollouts/features/analysis/){:target="\_blank"} either with metric providers or [simple Kubernetes jobs](https://argoproj.github.io/argo-rollouts/analysis/job/){:target="\_blank"} that can run integration tests or collect metrics and decide if the next color should be promoted or not.
-Another alternative is to simply execute [integration tests]({{site.baseurl}}/docs/testing/integration-tests/) from within Codefresh. This is great if your integration tests need access to the source code or other
-external services that are accessible only to Codefresh.
+Another alternative is to simply execute [integration tests]({{site.baseurl}}/docs/testing/integration-tests/) from within Codefresh. This is great if your integration tests need access to the source code or other external services that are accessible only to Codefresh.
-We can modify the previous pipeline to include automated smoke tests that are already part of the [example application](https://github.com/codefresh-contrib/argo-rollout-blue-green-sample-app/blob/main/src/test/java/sample/actuator/HealthIT.java).
+We can modify the previous pipeline to include automated smoke tests that are already part of the [example application](https://github.com/codefresh-contrib/argo-rollout-blue-green-sample-app/blob/main/src/test/java/sample/actuator/HealthIT.java){:target="\_blank"}.
{% include image.html
lightbox="true"
@@ -272,14 +267,14 @@ max-width="100%"
This pipeline does the following:
-1. [Clones]({{site.baseurl}}/docs/yaml-examples/examples/git-checkout/) the source code of the application
-1. [Builds]({{site.baseurl}}/docs/ci-cd-guides/building-docker-images/) a docker image
-1. [Deploys]({{site.baseurl}}/docs/deploy-to-kubernetes/kubernetes-templating/) the application by updating the Kubernetes manifests. Argo Rollouts sees the new manifest and creates a new "color" for the next version
+1. [Clones]({{site.baseurl}}/docs/example-catalog/ci-examples/git-checkout/) the source code of the application.
+1. [Builds]({{site.baseurl}}/docs/ci-cd-guides/building-docker-images/) a Docker image.
+1. [Deploys]({{site.baseurl}}/docs/ci-cd-guides/kubernetes-templating/) the application by updating the Kubernetes manifests. Argo Rollouts sees the new manifest and creates a new "color" for the next version.
1. Runs integration tests against the "preview" service created by Argo Rollouts. Live users are still on the previous/stable version of the application.
-1. If smoke tests pass the new color is promoted and becomes the new active version
-1. If smoke tests fail the new color is discarded the all live users are not affected in any way
+1. If smoke tests pass, the new color is promoted and becomes the new active version.
+1. If smoke tests fail, the new color is discarded and all live users are not affected in any way.
-Here is the [pipeline definition]({{site.baseurl}}/docs/codefresh-yaml/what-is-the-codefresh-yaml/):
+Here is the [pipeline definition]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/):
`codefresh.yml`
{% highlight yaml %}
@@ -358,15 +353,14 @@ You can optionally execute the Argo Rollouts CLI to see what is happening behind
kubectl argo rollouts get rollout spring-sample-app-deployment --watch -n blue-green
```
->Notice that for simplicity reasons we have hardcoded the loadbalancer for the preview service at 13.86.102.74. In a real application you would have a DNS name such as `preview.example.com` or use another `kubectl command` to fetch the endpoint of the loadbalancer dynamically. Also our integration tests assume that the application is already deployed once they run. If your application takes too much time to deploy, you need to make sure that it is up before the tests actually run
+>For the sake of simplicity, we have hardcoded the load balancer for the preview service at 13.86.102.74. For an actual application, you would have a DNS name such as `preview.example.com`, or use another `kubectl command` to fetch the endpoint of the load balancer dynamically. Also, our integration tests assume that the application is already deployed, before they run. If your application takes too much time to deploy, you need to make sure that it is up before the tests actually run.
-The end result is the a continuous deployment pipeline where all release candidates that don't pass tests never reach production.
+The end result is a continuous deployment pipeline, where all release candidates that don't pass tests never reach production.
## Canary deployments
-Blue/Green deployments are great for minimizing downtime after a deployment, but they are not perfect. If your new version has a hidden issue that manifests itself
-only after some time (i.e. it is not detected by your smoke tests) then **all** your users will be affected, because the traffic switch is all or nothing.
+Blue/Green deployments are great for minimizing downtime after a deployment, but they are not perfect. If your new version has a hidden issue that manifests itself only after some time (i.e. it is not detected by your smoke tests), then **all** your users will be affected, because the traffic switch is all or nothing.
An improved deployment method is canary deployments. These function similar to blue/green, but instead of switching 100% of live traffic all at once to the new version, you can instead move only a subset of users.
@@ -379,27 +373,26 @@ caption="Canary Deployments"
max-width="50%"
%}
-1. In the beginning all users of the application are routed to the current version (shown as blue color). A key point is that all traffic passes from a load balancer
-1. A new version is deployed (shown as green color). This version gets only a very small amount of live traffic (for example 10%)
-1. Developers can test internally and monitor their metrics to verify the new release. If they are confident, they can redirect more traffic to the new version (for example 33%)
-1. If everything goes well the old version is discarded completely. All traffic is now redirected to the new version. We are back to initial state (order of colors does not matter)
+1. At the start, all users of the application are routed to the current version (shown in blue). A key point is that all traffic passes from a load balancer.
+1. A new version is deployed (shown in green). This version gets only a very small amount of live traffic (for example 10%).
+1. Developers can test internally and monitor their metrics to verify the new release. If they are confident, they can redirect more traffic to the new version (for example 33%).
+1. If everything goes well, the old version is completely discarded. All traffic is now redirected to the new version. We are back to initial state (order of colors does not matter).
The major benefit of this pattern is that if at any point in time the new version has issues, only a small subset of live users are affected. And like blue/green deployments, performing a rollback is as easy as resetting the load balancer to send no traffic to the canary version. Switching the load balancer is much faster than redeploying a new version, resulting in minimum disruption for existing users.
-There are several variations of this pattern. The amount of live traffic that you send to the canary at each step as well as the number of steps are user configurable. A simple approach would have just two steps (10%, 100%) while a more complex one could move traffic in a gradual way (10%, 30%, 60%, 90%, 100%).
+There are several variations of this pattern. The amount of live traffic that you send to the canary at each step as well as the number of steps are user configurable. A simple approach would have just two steps (10%, 100%), while a more complex one could move traffic in a gradual way (10%, 30%, 60%, 90%, 100%).
->Note that canary deployments are more advanced than blue/green deployments and are also more complex to setup. The loadbalancer is now much smarter as it can handle two streams of traffic at the same time with different destinations of different weights. You also need a way (usually an API) to instruct the loadbalancer to change the weight distribution of the traffic streams. If you are just getting started with progressive delivery, we suggest you master blue/green deployments first, before adopting canaries.
+>Canary deployments are more advanced than blue/green deployments, and are also more complex to set up. The load balancer is now much smarter as it can handle two streams of traffic at the same time with different destinations of different weights. You also need a way (usually an API) to instruct the loadbalancer to change the weight distribution of the traffic streams. If you are just getting started with progressive delivery, we suggest you master blue/green deployments first, before adopting canaries.
### Canary Deployment with Argo Rollouts
-
-
-Argo Rollouts supports the basic canary pattern described in the previous section, and also offers a wealth of [customization options](https://argoproj.github.io/argo-rollouts/features/canary/). One of the most important
-additions is the ability to "test" the upcoming version by introducing a "preview" [Kubernetes service](https://kubernetes.io/docs/concepts/services-networking/service/), in addition to the service used for live traffic.
+Argo Rollouts supports the basic canary pattern described in the previous section, and also offers a wealth of [customization options](https://argoproj.github.io/argo-rollouts/features/canary/){:target="\_blank"}.
+One of the most important
+additions is the ability to "test" the upcoming version by introducing a "preview" [Kubernetes service](https://kubernetes.io/docs/concepts/services-networking/service/){:target="\_blank"}, in addition to the service used for live traffic.
This preview service can be used by the team that performs the deployment to verify the new version as it gets used by the subset of live users.
-Here is the initial state of a deployment. The example uses 4 pods (shown as `22nqx`, `nqksq`, `8bzwh` and `jtdcc` in the diagram).
+Here is the initial state of a deployment. The example uses four pods (shown as `22nqx`, `nqksq`, `8bzwh` and `jtdcc` in the diagram).
{% include image.html
lightbox="true"
@@ -410,11 +403,15 @@ caption="Initial deployment. All services point to active version"
max-width="90%"
%}
-There are now three Kubernetes services . The `rollout-canary-all-traffic` is capturing all live traffic from actual users of the application (internet traffic coming from `20.37.135.240`). There is a secondary service
-called `rollout-canary-active`. This will always point to the stable/previous version of the software. Finally the third services is called `rollout-canary-preview` and this will only route traffic to the canary/new versions. Under normal circumstances all 3 services point to the same version.
+There are now three Kubernetes services:
+* The `rollout-canary-all-traffic` that captures all live traffic from actual users of the application (internet traffic coming from `20.37.135.240`).
+* A secondary service, `rollout-canary-active`, that always points to the stable/previous version of the software.
+* A third service, `rollout-canary-preview`, that only routes traffic to the canary/new versions.
+In normal circumstances all there services point to the same version.
-Once a deployment starts a new "version" is created. In the example we have 1 new pod that represents the next version of the application to be deployed (shown as `9wx8w` at the top of the diagram).
+
+Once a deployment starts, a new "version" is created. In the example we have one new pod that represents the next version of the application to be deployed (shown as `9wx8w` at the top of the diagram).
{% include image.html
lightbox="true"
@@ -425,9 +422,9 @@ caption="Deployment in progress. 10% of users are sent to the canary version"
max-width="90%"
%}
-The important point here is the fact that the service used by live users (called `rollout-canary-all-traffic`) is routing traffic to **both** the canary and the previous version. It is not visible in the diagram but only 10% of traffic is sent to the single pod that hosts the new version, while 90% of traffic goes to the 4 pods of the old version.
+The important point here is the fact that the service used by live users (called `rollout-canary-all-traffic`) routes traffic to **both** the canary and the previous version. It is not visible in the diagram, but only 10% of traffic is sent to the single pod that hosts the new version, while 90% of traffic goes to the four pods of the old version.
-The `rollout-canary-preview` service goes only to the canary pod. You can use this service to examine metrics from the canary or even give it to users that always want to try the new version first (e.g. your internal developers). On the other hand the `rollout-canary-active` service always goes to the stable version. You can use that for users that never want to try the new version first or for verifying how something worked in the previous version.
+The `rollout-canary-preview` service goes only to the canary pod. You can use this service to examine metrics from the canary or even give it to users who always want to try the new version first (e.g. your internal developers). On the other hand, the `rollout-canary-active` service always goes to the stable version. You can use that for users who never want to try the new version first or for verifying how something worked in the previous version.
@@ -442,7 +439,7 @@ caption="Deployment in progress. 33% of users are sent to the canary version"
max-width="90%"
%}
-We are now sending 33% of live traffic to the canary (the traffic weights are not visible in the picture). To accommodate for the extra traffic the canary version now has 2 pods instead of one. This is also another great feature of Argo Rollouts. The amount of pods you have in the canary is completely unrelated to the amount of traffic that you send to it. You can have all possible combinations that you can think of (e.g. 10% of traffic to 5 pods, or 50% of traffic to 3 pods and so on). It all depends on the resources used by your application.
+We are now sending 33% of live traffic to the canary (the traffic weights are not visible in the picture). To accommodate the extra traffic, the canary version now has two pods instead of one. This is also another great feature of Argo Rollouts. The amount of pods you have in the canary is completely unrelated to the amount of traffic that you send to it. You can have all possible combinations that you can think of (e.g. 10% of traffic to five pods, or 50% of traffic to three pods and so on). It all depends on the resources used by your application.
It makes sense of course to gradually increase the number of pods in the canary as you shift more traffic to it.
@@ -452,18 +449,18 @@ by simply telling the load balancer to move 100% of traffic back to the previous
{% include image.html
lightbox="true"
file="/images/guides/progressive-delivery/04_canary_finished.png"
-url="/images/guides/progressive-delivery/04_canary_finished"
+url="/images/guides/progressive-delivery/04_canary_finished.png"
alt="Old application version is discarded. Only new version remains."
caption="Old application version is discarded. Only new version remains."
max-width="90%"
%}
-Two more pods are launched for the canary (for a total of 4) and finally we can shift 100% of live traffic to it. After some time the old version is scaled down completely (to preserve resources). We are now back
+Two more pods are launched for the canary (for a total of four), and finally we can shift 100% of live traffic to it. After some time,the old version is scaled down completely to preserve resources. We are now back
to the same configuration as the initial state, and the next deployment will follow the same sequence of events.
-### The example application
+### Example application
-You can find an example application at [https://github.com/codefresh-contrib/argo-rollout-canary-sample-app](https://github.com/codefresh-contrib/argo-rollout-canary-sample-app) that also includes simple metrics (we will use them in the second example with canaries).
+You can find an example application at [https://github.com/codefresh-contrib/argo-rollout-canary-sample-app](https://github.com/codefresh-contrib/argo-rollout-canary-sample-app){:target="\_blank"} that also includes simple metrics (we will use them in the second example with canaries).
Notice that the first deployment of your application will NOT follow the canary deployment process as there is no "previous" version. So you need to deploy it at least
once.
@@ -483,25 +480,23 @@ kubectl argo rollouts get rollout golang-sample-app-deployment --watch -n canary
### Choosing a solution for Traffic Management
-Unlike Blue/Green deployments, canary deployments require a smarter way to handle incoming traffic to your application. Specifically for Kubernetes
-you need a networking solution that can split traffic according to percentages. Kubernetes on its own performs simple load balancing where the number
-of pods affects the traffic they get. But that is not enough for canary deployments.
+Unlike Blue/Green deployments, canary deployments require a smarter way to handle incoming traffic to your application. Specifically for Kubernetes, you need a networking solution that can split traffic according to percentages. Kubernetes on its own performs simple load balancing where the number of pods affects the traffic they get. But that is not enough for canary deployments.
-Argo Rollouts has [several integrations](https://argoproj.github.io/argo-rollouts/features/traffic-management/) with Service Meshes and ingresses that can be used for Traffic Splits.
+Argo Rollouts has [several integrations](https://argoproj.github.io/argo-rollouts/features/traffic-management/){:target="\_blank"} with Service Meshes and ingresses that can be used for Traffic Splits.
-Apart from the platforms that are supported natively by Argo Rollouts, you can also use any solution that implements the [Service Mesh Interface](https://smi-spec.io/), a common
-standard for service mesh implementations. Argo Rollouts [adheres to the SMI spec](https://argoproj.github.io/argo-rollouts/features/traffic-management/smi/) and can instruct any compliant solution for the traffic split process during canaries.
+Apart from the platforms that are supported natively by Argo Rollouts, you can also use any solution that implements the [Service Mesh Interface (SMI)](https://smi-spec.io/){:target="\_blank"}, a common
+standard for service mesh implementations. Argo Rollouts [adheres to the SMI spec](https://argoproj.github.io/argo-rollouts/features/traffic-management/smi/){:target="\_blank"}, and can instruct any compliant solution for the traffic split process during canaries.
-In our example we are using [LinkerD](https://linkerd.io/), an open source service mesh solution for Kubernetes that also implements SMI.
-You can install LinkerD by following [the official documentation](https://linkerd.io/2.10/getting-started/) in your cluster and then making sure that your application is [meshed](https://linkerd.io/2.10/tasks/adding-your-service/) (i.e. it is managed by LinkerD) by adding the special annotation [linkerd.io/inject:enabled](https://github.com/codefresh-contrib/argo-rollout-canary-sample-app/blob/main/canary-manual-approval/rollout.yaml#L36) in the rollout YAML.
+In our example we are using [LinkerD](https://linkerd.io/){:target="\_blank"}, an open source service mesh solution for Kubernetes that also implements SMI.
+You can install LinkerD by following [the official documentation](https://linkerd.io/2.10/getting-started/){:target="\_blank"} in your cluster and then making sure that your application is [meshed](https://linkerd.io/2.10/tasks/adding-your-service/){:target="\_blank"} (i.e. it is managed by LinkerD) by adding the special annotation [linkerd.io/inject:enabled](https://github.com/codefresh-contrib/argo-rollout-canary-sample-app/blob/main/canary-manual-approval/rollout.yaml#L36){:target="\_blank"} in the rollout YAML.
### Canary deployment with manual approval
-As with Blue/Green deployments, the easiest way to use canaries is by simply inserting [an approval step]({{site.baseurl}}/docs/codefresh-yaml/steps/approval/) before each subsequent traffic switch step.
+As with Blue/Green deployments, the easiest way to use canaries is by simply inserting an [approval step]({{site.baseurl}}/docs/pipelines/steps/approval/) before each subsequent traffic switch step.
This will pause the pipeline and the developers or QA team can evaluate the canary stability.
-Here is the [Canary setup](https://github.com/codefresh-contrib/argo-rollout-canary-sample-app/blob/main/canary-manual-approval/rollout.yaml#L8):
+Here is the [Canary setup](https://github.com/codefresh-contrib/argo-rollout-canary-sample-app/blob/main/canary-manual-approval/rollout.yaml#L8){:target="\_blank"}:
`rollout.yaml` (excerpt)
```yaml
@@ -526,12 +521,12 @@ spec:
- pause: {}
```
-The canary has essentially 3 stages. At the beginning it gets only 10% of the traffic and then it stops. At this point it creates 1/4 of pods. Then
-if we promote it, it gets 33% of the traffic and is now scaled up to 1/2 of pods of a full deployment. We pause again and then finally it gets 100% of
+The canary has essentially three stages. At the beginning, it gets only 10% of the traffic and then it stops. At this point it creates 1/4 of pods. Then
+if we promote it, it gets 33% of the traffic and is now scaled up to 1/2 the number of pods constituting a full deployment. We pause again and then finally it gets 100% of
live traffic.
-Here is the respective pipeline pipeline with canary steps:
+Here is the pipeline with canary steps:
{% include image.html
lightbox="true"
@@ -544,15 +539,15 @@ max-width="100%"
This pipeline does the following:
-1. [Clones]({{site.baseurl}}/docs/yaml-examples/examples/git-checkout/) the source code of the application
-1. [Builds]({{site.baseurl}}/docs/ci-cd-guides/building-docker-images/) a docker image
-1. [Deploys]({{site.baseurl}}/docs/deploy-to-kubernetes/kubernetes-templating/) the application by updating the Kubernetes manifests. Argo Rollouts sees the new manifest and creates a new version. 10% of live traffic is redirected to it.
-1. The pipeline is paused and waits for an [approval/rejection]({{site.baseurl}}/docs/codefresh-yaml/steps/approval/#getting-the-approval-result) by a human user.
-1. If the pipeline is approved 33% of traffic is now sent to the canary. If the pipeline is rejected, the canary is discarded and all traffic goes back to the stable version.
+1. [Clones]({{site.baseurl}}/docs/example-catalog/ci-examples/git-checkout/) the source code of the application.
+1. [Builds]({{site.baseurl}}/docs/ci-cd-guides/building-docker-images/) a Docker image.
+1. [Deploys]({{site.baseurl}}/docs/ci-cd-guides/kubernetes-templating/) the application by updating the Kubernetes manifests. Argo Rollouts sees the new manifest and creates a new version. 10% of live traffic is redirected to it.
+1. The pipeline is paused and waits for an [approval/rejection]({{site.baseurl}}/docs/pipelines/steps/approval/#getting-the-approval-result) by a human user.
+1. If the pipeline is approved, 33% of traffic is now sent to the canary. If the pipeline is rejected, the canary is discarded and all traffic goes back to the stable version.
1. In the next pause, the pipeline waits for a second approval.
-1. If the pipeline is approved all traffic is now sent to the canary. If the pipeline is rejected, the canary is discarded and all traffic goes back to the stable version.
+1. If the pipeline is approved, all traffic is now sent to the canary. If the pipeline is rejected, the canary is discarded and all traffic goes back to the stable version.
-Here is the [pipeline definition]({{site.baseurl}}/docs/codefresh-yaml/what-is-the-codefresh-yaml/):
+Here is the [pipeline definition]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/):
`codefresh.yml`
{% highlight yaml %}
@@ -675,7 +670,7 @@ steps:
{% endraw %}
{% endhighlight %}
-Just before the approval you can optionally execute the Argo Rollouts CLI to see what is happening behind the scenes:
+Just before the approval, you can optionally execute the Argo Rollouts CLI to see what is happening behind the scenes:
```
kubectl argo rollouts get rollout golang-sample-app-deployment --watch -n canary
@@ -692,9 +687,9 @@ caption="Argo Rollouts CLI"
max-width="100%"
%}
-In the screenshot about, the canary deployment has just started. There is only one pod for the canary and it gets 10% of live traffic. The 4 pods of the previous version still receive 9 percent of live traffic.
+In the above picture, the canary deployment has just started. There is only one pod for the canary that gets 10% of live traffic. The four pods of the previous version still receive 90% percent of live traffic.
-You can also see the traffic split in the [LinkerD Dashboard](https://linkerd.io/2.10/reference/architecture/#dashboard):
+You can also see the traffic split in the [LinkerD Dashboard](https://linkerd.io/2.10/reference/architecture/#dashboard){:target="\_blank"}:
{% include image.html
lightbox="true"
@@ -710,23 +705,22 @@ You can also get the same information from the command line with `kubectl get tr
### Choosing a solution for automated metric analysis
-Canary deployments with manual pauses are great to get started but can quickly become cumbersome and error-prone. Ideally the canary should automatically promote itself
-if the application "looks good". One of the most straightforward ways to examine application health is by reading its metrics and decide on the progress of the canary in a completely automated way.
+Canary deployments with manual pauses are great to get started but can quickly become cumbersome and error-prone. Ideally, the canary should automatically promote itself if the application "looks good". One of the most straightforward ways to examine application health is by reading its metrics and decide on the progress of the canary in a completely automated way.
There are two main sources for metrics that you can use
-1. Application specific metrics. This requires instrumentation in your application but is very powerful as you can query exactly what you want
-1. Cluster level metrics (i.e. from the service mesh). These are very easy to setup but are generic and deal mostly with the traffic the application receives.
+1. Application-specific metrics. This requires instrumentation in your application but is very powerful as you can query exactly what you want.
+1. Cluster-level metrics (i.e. from the service mesh). These are very easy to set up, but are generic and deal mostly with the traffic the application receives.
-Argo Rollouts has native integration for [several metric providers](https://argoproj.github.io/argo-rollouts/features/analysis/). We will use Prometheus in our example.
-The example application [is already instrumented](https://github.com/codefresh-contrib/argo-rollout-canary-sample-app/blob/main/main.go#L51) to expose some basic metrics.
+Argo Rollouts has native integration for [several metric providers](https://argoproj.github.io/argo-rollouts/features/analysis/){:target="\_blank"}. We will use Prometheus in our example.
+The example application [is already instrumented](https://github.com/codefresh-contrib/argo-rollout-canary-sample-app/blob/main/main.go#L51){:target="\_blank"} to expose some basic metrics.
-First you need to install Prometheus by following [the official documentation](https://prometheus.io/docs/prometheus/latest/installation/). Then you need to make sure that Prometheus will actually scrape your application. Prometheus has [native service discovery for Kubernetes](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#kubernetes_sd_config) but you need to enable it in the configuration.
+First, you need to install Prometheus by following [the official documentation](https://prometheus.io/docs/prometheus/latest/installation/){:target="\_blank"}. Then you need to make sure that Prometheus will actually scrape your application. Prometheus has [native service discovery for Kubernetes](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#kubernetes_sd_config){:target="\_blank"} but you need to enable it in the configuration.
-If you [install Prometheus with the Helm chart](https://github.com/prometheus-community/helm-charts), Kubernetes service discovery is already enabled. The only thing to setup is to add the `prometheus.io/scrape: "true"` annotation in your rollout so that Prometheus does not ignore your application.
+If you [install Prometheus with the Helm chart](https://github.com/prometheus-community/helm-charts){:target="\_blank"}, Kubernetes service discovery is already enabled. The only thing to set up is to add the `prometheus.io/scrape: "true"` annotation in your rollout so that Prometheus does not ignore your application.
-You can optionally install [Graphana](https://grafana.com/) so that you can inspect your application metrics before using them in the canary process. The example application has an [basic dashboard](https://github.com/codefresh-contrib/argo-rollout-canary-sample-app/blob/main/graphana/graphana-dashboard.json)
+You can optionally install [Graphana](https://grafana.com/){:target="\_blank"} so that you can inspect your application metrics before using them in the canary process. The example application has an [basic dashboard](https://github.com/codefresh-contrib/argo-rollout-canary-sample-app/blob/main/graphana/graphana-dashboard.json){:target="\_blank"}
that you can import:
{% include image.html
@@ -768,7 +762,7 @@ Note that Argo Rollouts can evaluate multiple queries when deciding if the canar
Once your have your metric solution in place we need to instruct Argo Rollouts to use it during a deployment.
-This happens with an [Analysis CRD](https://github.com/codefresh-contrib/argo-rollout-canary-sample-app/blob/main/canary-with-metrics/analysis.yaml).
+This happens with an [Analysis CRD](https://github.com/codefresh-contrib/argo-rollout-canary-sample-app/blob/main/canary-with-metrics/analysis.yaml){:target="\_blank"}.
`analysis.yaml`
```yaml
@@ -847,11 +841,11 @@ max-width="100%"
This pipeline does the following:
-1. [Clones]({{site.baseurl}}/docs/yaml-examples/examples/git-checkout/) the source code of the application
-1. [Builds]({{site.baseurl}}/docs/ci-cd-guides/building-docker-images/) a docker image
-1. [Deploys]({{site.baseurl}}/docs/deploy-to-kubernetes/kubernetes-templating/) the application by updating the Kubernetes manifests. Argo Rollouts sees the new manifest and creates a new version and starts the canary process.
+1. [Clones]({{site.baseurl}}/docs/example-catalog/ci-examples/git-checkout/) the source code of the application.
+1. [Builds]({{site.baseurl}}/docs/ci-cd-guides/building-docker-images/) a Docker image.
+1. [Deploys]({{site.baseurl}}/docs/ci-cd-guides/kubernetes-templating/) the application by updating the Kubernetes manifests. Argo Rollouts sees the new manifest and creates a new version and starts the canary process.
-Here is the [pipeline definition]({{site.baseurl}}/docs/codefresh-yaml/what-is-the-codefresh-yaml/):
+Here is the [pipeline definition]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/):
`codefresh.yml`
{% highlight yaml %}
@@ -914,15 +908,15 @@ caption="Running the Analysis in the background"
max-width="100%"
%}
-For each deployment you can also see the result of the Analysis along with the canary pods. The number next to the checkmark shows how many times the analysis will run (this is defined by the `count` property in the Analysis file). See the [Canary specification](https://argoproj.github.io/argo-rollouts/features/canary/) for more parameters.
+For each deployment you can also see the result of the Analysis along with the canary pods. The number next to the checkmark shows how many times the analysis will run (this is defined by the `count` property in the Analysis file). See the [Canary specification](https://argoproj.github.io/argo-rollouts/features/canary/){:target="\_blank"} for more parameters.
## Monitoring the Argo Rollouts controller
-Note that regardless of whether you use metric evaluation for your own applications, Argo Rollouts itself exposes Prometheus metrics
+Regardless of whether you use metric evaluation for your own applications, Argo Rollouts itself exposes Prometheus metrics
for its internal functionality. You can ingest those metrics like any other Prometheus application
and create your own dashboards if you want to get some insights on what the controller is doing.
-You can find an example dashboard at [https://github.com/argoproj/argo-rollouts/blob/master/examples/dashboard.json](https://github.com/argoproj/argo-rollouts/blob/master/examples/dashboard.json) that can be used as a starting point.
+You can find an example dashboard at [https://github.com/argoproj/argo-rollouts/blob/master/examples/dashboard.json](https://github.com/argoproj/argo-rollouts/blob/master/examples/dashboard.json){:target="\_blank"} that can be used as a starting point.
{% include image.html
lightbox="true"
@@ -934,7 +928,7 @@ max-width="80%"
%}
-For more details see the [metrics documentation page](https://argoproj.github.io/argo-rollouts/features/controller-metrics/).
+For more details, see the [metrics documentation page](https://argoproj.github.io/argo-rollouts/features/controller-metrics/){:target="\_blank"}.
## Using Argo Rollouts with GitOps
@@ -956,11 +950,9 @@ See our [GitOps page]({{site.baseurl}}/docs/ci-cd-guides/gitops-deployments/) fo
-## What to read next
-
-* [Production/Staging deployments]({{site.baseurl}}/docs/ci-cd-guides/environment-deployments/)
-* [GitOps Deployments]({{site.baseurl}}/docs/ci-cd-guides/gitops-deployments/)
-* [Pipelines for Microservices]({{site.baseurl}}/docs/ci-cd-guides/microservices/)
+## Related articles
+[Deploying to predefined environments]({{site.baseurl}}/docs/ci-cd-guides/environment-deployments/)
+[Building microservices]({{site.baseurl}}/docs/ci-cd-guides/microservices/)
diff --git a/_docs/ci-cd-guides/pull-request-branches.md b/_docs/ci-cd-guides/pull-request-branches.md
index a086a8446..74c808afe 100644
--- a/_docs/ci-cd-guides/pull-request-branches.md
+++ b/_docs/ci-cd-guides/pull-request-branches.md
@@ -1,13 +1,13 @@
---
-title: "Pull Requests and Branches"
-description: "Learn how to handle builds for Pull requests or other branches"
+title: "Pull requests and branches"
+description: "Handle builds for pull requests or other branches"
group: ci-cd-guides
toc: true
---
Codefresh has native support for working with different branches and building pull requests. In particular, it has a very rich trigger model that allows you to handle specific events (such as opening a pull request or adding a comment).
-The possible actions can be seen on the trigger dialog of your pipeline:
+The possible actions can be seen in the trigger dialog of your pipeline:
{% include image.html
lightbox="true"
@@ -17,20 +17,20 @@ alt="Adding GIT Trigger"
max-width="50%"
%}
-Notice however that Codefresh capabilities are always based on what your Git provider is offering. If your GIT provider does not support webhooks for specific events, then these will not be available in the trigger dialog.
+Notice however that Codefresh capabilities are always based on what your Git provider is offering. If your Git provider does not support webhooks for specific events, then these will not be available in the trigger dialog.
## Building branches automatically
-By default Codefresh will connect to your Git provider and do the following:
+By default, Codefresh connects to your Git provider and does the following:
-1. Auto-build every new commit that happens in master or any other branch
-2. Auto-build every new branch when it is created
+1. Auto-builds every new commit that happens in master or any other branch
+2. Auto-builds every new branch when it is created
-You can change the default behavior so that it matches your own workflow using extra [GIT Triggers]({{site.baseurl}}/docs/configure-ci-cd-pipeline/triggers/git-triggers/).
+You can change the default behavior so that it matches your own workflow using extra [Git triggers]({{site.baseurl}}/docs/pipelines/triggers/git-triggers/).
-You don't have to do anything special to setup this communication between Codefresh and your Git provider. It was setup automatically for you when you connected your Codefresh account to your Git provider.
+You don't have to do anything special to set up this communication between Codefresh and your Git provider. It was set up automatically when you connected your Codefresh account to your Git provider.
-Codefresh also creates for you a default Git trigger the first time you create a project.
+Codefresh also creates a default Git trigger the first time you create a project.
{% include
image.html
@@ -42,7 +42,7 @@ caption="Default GIT trigger"
max-width="50%"
%}
-If you create a new branch in your repository Codefresh will automatically build it (and also store the resulting Docker image).
+If you create a new branch in your repository, Codefresh automatically builds it and also stores the resulting Docker image.
```
git checkout -b another-branch
@@ -62,21 +62,21 @@ caption="Building automatically new branches"
max-width="100%"
%}
-When you commit to a Pull Request, not only Codefresh will auto-build it, but you will also see the build request in the GitHub UI as well:
+When you commit to a Pull Request (PR), Codefresh auto-builds the PR, and you can also see the build request in the GitHub UI as well:
{% include
image.html
lightbox="true"
-file="/images/getting-started/quick-start-test-pr/auto-build-pr.png"
-url="/images/getting-started/quick-start-test-pr/auto-build-pr.png"
-alt="Pull Request Status"
-caption="Pull Request Status (click image to enlarge)"
+file="/images/guides/branches-pull-requests/auto-build-pr.png"
+url="/images/guides/branches-pull-requests/auto-build-pr.png"
+alt="Pull Request status"
+caption="Pull Request status"
max-width="50%"
%}
## Building specific branches manually
-Sometimes you want to run an ad-hoc build on a specific branch without actually committing anything. You can do that in the [run dialog of a pipeline]({{site.baseurl}}/docs/configure-ci-cd-pipeline/pipelines/#creating-new-pipelines) by selecting a branch from the drop down menu.
+Sometimes you want to run an ad-hoc build on a specific branch without actually committing anything. You can do that in the [run dialog of a pipeline]({{site.baseurl}}/docs/pipelines/pipelines/#creating-new-pipelines) by selecting a branch from the dropdown menu.
{% include image.html
lightbox="true"
@@ -87,13 +87,13 @@ caption="Building a specific branch"
max-width="50%"
%}
-From the same dialog, you can also choose a specific trigger to "emulate" for this branch if you have connected multiple triggers on the same pipeline.
+From the same dialog, you can also select a specific trigger to "emulate" for this branch if you have connected multiple triggers on the same pipeline.
## Restricting which branches to build
-The auto-build nature of Codefresh for all branches, is what you want most times. For larger projects you might wish to restrict pipelines running only on specific branches.
+The auto-build nature of Codefresh for all branches is what you want most times. For larger projects, you might wish to restrict pipelines running only on specific branches.
-This is performed by filling [the branch field]({{site.baseurl}}/docs/configure-ci-cd-pipeline/triggers/git-triggers/#pull-request-target-branch-and-branch) in the trigger dialog with a regular expression.
+This is performed by defining [the branch field]({{site.baseurl}}/docs/pipelines/triggers/git-triggers/#pull-request-target-branch-and-branch) in the trigger dialog with a regular expression.
{% include image.html
lightbox="true"
@@ -104,9 +104,10 @@ caption="Restrict a pipeline to a single branch"
max-width="50%"
%}
-The trigger above will only be activated for the `production` branch, so if a developer creates another new branch this pipeline will not run for it. Remember also that this field is actually a regular expression so you can restrict a pipeline to a specific naming pattern (i.e. a group of branch names).
+The trigger above will only be activated for the `production` branch, so if a developer creates a new branch this pipeline will not run for it. Remember also that this field is actually a regular expression, so you can restrict a pipeline to a specific naming pattern (i.e. a group of branch names).
-Another popular filtering mechanism is to keep the auto-build nature of Codefresh, but enable/disable specific pipeline steps according to the branch being built. This is performed by using [step conditionals]({{site.baseurl}}/docs/codefresh-yaml/conditional-execution-of-steps/). Here is an example
+Another popular filtering mechanism is to keep the auto-build nature of Codefresh, but enable/disable specific pipeline steps according to the branch being built. This is performed by using [step conditions]({{site.baseurl}}/docs/pipelines/conditional-execution-of-steps/).
+Here is an example:
`codefresh.yml`
{% highlight yaml %}
@@ -130,7 +131,7 @@ steps:
stage: build
image_name: spring-boot-2-sample-app
working_directory: ./
- tag: 'multi-stage'
+ tag: 'multistage'
dockerfile: Dockerfile
deploy_production:
title: Deploying to production
@@ -169,7 +170,7 @@ This pipeline will execute for **ALL** branches and pull requests, but:
1. If the branch is `master` it will deploy the Docker image to the production cluster and namespace `default`
1. If the branch starts with `JIRA-FEATURE-` (e.g. JIRA-FEATURE-1234, JIRA-FEATURE-testing, JIRA-FEATURE-fixbbug), it will deploy to a staging cluster to namespace `development`
-1. In all other cases of branches or pull requests it will just build the Docker image without deploying it anywhere
+1. In all other cases of branches or pull requests, it will just build the Docker image without deploying it anywhere
You can see that if a developer creates an unrelated branch (that doesn't match the expected name), no deployment will take place:
@@ -184,13 +185,13 @@ max-width="80%"
This is a more granular way to control how your branch affects your pipeline.
->Notice that we recommend you follow the first method of having multiple simple pipelines with different branch expressions in the trigger dialog, instead of having a single complex pipeline that is using step conditionals. Remember that in Codefresh you can create as many pipeline as you want for a single project instead of being limited to 1 pipeline per project.
+>We recommend you follow the first method of having multiple simple pipelines with different branch expressions in the trigger dialog, instead of having a single complex pipeline using step conditions. Remember that in Codefresh you can create as many pipelines as you want for a single project instead of being limited to one pipeline per project.
-## Handling Pull Request events
+## Handling pull request events
-The big power of Codefresh becomes evident when you realize that you can have extra pipelines that respond to specific Pull Request events. For example, you can have a specific pipeline that runs **only** when a Pull Request is opened for the first time or when a Pull Request is closed.
+The power of Codefresh becomes evident when you realize that you can have extra pipelines that respond to specific PR events. For example, you can have a specific pipeline that runs **only** when a PR is opened for the first time or when a PR is closed.
-You can see all supported Pull Request events in the trigger dialog.
+You can see all supported PR events in the trigger dialog.
{% include image.html
lightbox="true"
@@ -201,40 +202,40 @@ caption="Choosing PR events for a pipeline"
max-width="80%"
%}
->Remember that the events shown are those supported by your Git provider. Not all Git providers support all possible Pull request events.
+>Remember that the events shown are those supported by your Git provider. Not all Git providers support all possible pull request events.
-You can select multiple Pull Request events for a single pipeline, or have multiple pipelines that respond to individual Pull Request events. There is no right or wrong answer as it mostly depends on how your team is handling Pull Requests
+You can select multiple pull request events for a single pipeline, or have multiple pipelines that respond to individual pull request events. There is no right or wrong answer as it mostly depends on how your team handles pull requests.
The most useful events are:
-* Pull Request open
-* Pull Request sync (when a commit happens to a PR)
-* Pull Request closed
-* Comment added on Pull Request
+* Pull request open
+* Pull request sync (when a commit happens to a PR)
+* Pull request closed
+* Comment added on a pull request
There is also the shortcut checkbox for *any PR event* if you don't care about which specific event happened.
-## Trunk based development
+## Trunk Based Development
-One of the most popular git workflows is [Trunk Based development](https://trunkbaseddevelopment.com/) with short lived feature branches.
+One of the most popular Git workflows is [Trunk Based development](https://trunkbaseddevelopment.com/){:target="\_blank"} with short-lived feature branches.
{% include image.html
lightbox="true"
file="/images/guides/branches-pull-requests/trunk-based-development.png"
url="/images/guides/branches-pull-requests/trunk-based-development.png"
-alt="Trunk Based development"
+alt="Trunk Based Development"
caption="Trunk Based Development"
max-width="100%"
%}
-In this process, the master branch is always ready for production. The feature branches are created from master and can have several commits before being merged back to master.
+In this process, the master branch is always ready for production. The feature branches are created from the master and can have several commits before being merged back to master.
-This process can be easily created in Codefresh with two separate pipelines
+This process can be easily created in Codefresh with two separate pipelines:
* The "main" pipeline that deploys master to the production environment
* The feature pipeline that checks each feature as it is developed (and optionally deploys it to a staging environment)
-As an example here is a minimal pipeline for the master branch:
+As an example, here is a minimal pipeline for the master branch:
{% include image.html
lightbox="true"
@@ -249,7 +250,7 @@ The pipeline:
1. Checks out the source code
1. Builds a Docker image
-1. Creates and Stores a Helm chart
+1. Creates and stores a Helm chart
1. Deploys the chart to Kubernetes
The pipeline for feature branches is different:
@@ -265,12 +266,12 @@ max-width="100%"
For each feature branch:
-1. We checkout the code
+1. We check out the code
1. Run linters on the source code
1. Build the Docker image
-1. Run some unit tests to verify the Docker image (possible with [service containers]({{site.baseurl}}/docs/codefresh-yaml/service-containers/))
+1. Run some unit tests to verify the Docker image (possible with [service containers]({{site.baseurl}}/docs/pipelines/service-containers/))
-To implement trunk-based development we create two triggers for these pipelines. For the production pipeline we just make sure that the trigger is only launched when commits land on master (and only there).
+To implement trunk-based development, we create two triggers for these pipelines. For the production pipeline, we just make sure that the trigger is only launched when commits land on master (and only there).
{% include image.html
lightbox="true"
@@ -281,12 +282,12 @@ caption="Trigger for production pipeline"
max-width="50%"
%}
-For the feature branch pipeline we check the events for:
+For the feature branch pipeline, we check the events for:
-* Pull Request Open
-* Pull Request Sync (when a commit happens on the PR)
+* PR (pull request) Open
+* PR Sync (when a commit happens on the PR)
-For the [branch specifications]({{site.baseurl}}/docs/configure-ci-cd-pipeline/triggers/git-triggers/#pull-request-target-branch-and-branch) we make sure that we look only for Pull Requests that are targeted **AT** `master`.
+For the [branch specifications]({{site.baseurl}}/docs/pipelines/triggers/git-triggers/#pull-request-target-branch-and-branch) we make sure that we look only for Pull Requests that are targeted **AT** `master`.
{% include image.html
lightbox="true"
@@ -299,20 +300,20 @@ max-width="50%"
With this configuration, the whole process is as follows:
-1. A developer creates a new branch from master. Nothing really happens at this point
-1. The developer opens a new Pull Request for this branch. The feature pipeline runs (because of the PR open checkbox)
-1. The developer commits one or more times on the branch. The feature pipeline runs again for each commit (because of the PR sync checkbox)
+1. A developer creates a new branch from master. Nothing really happens at this point.
+1. The developer opens a new PR for this branch. The feature pipeline runs (because of the PR open checkbox).
+1. The developer makes one or more commits to the branch. The feature pipeline runs again for each commit (because of the PR sync checkbox).
1. The developer commits the branch back to master. The main pipeline runs and deploys to production.
-You can fine-tune this workflow according to your needs. For example, you might also specify a naming pattern on the branches for the Pull Requested (e.g. feature-xxx) to further restrict which branches are considered ready for production.
+You can fine-tune this workflow according to your needs. For example, you might also specify a naming pattern on the branches for the PR (e.g. feature-xxx) to further restrict which branches are considered ready for production.
-> Notice that we didn't need to handle the PR close/merge events. As soon as a Pull Request is merged back to master, the GIT provider sends anyway an event that a commit has happened in master, which means that the main production pipeline will take care of releasing the contents of master.
+> We didn't need to handle the PR close/merge events. As soon as a PR is merged back to master, the Git provider sends anyway an event that a commit has happened in master, which means that the main production pipeline will take care of releasing the contents of master.
## Git-flow
-[Git Flow](https://nvie.com/posts/a-successful-git-branching-model/) is another popular management process for git branches. For brevity reasons, we will not list all the details for all branch types, but it should be obvious that you can recreate all aspects of Git flow with Codefresh triggers.
+[Git Flow](https://nvie.com/posts/a-successful-git-branching-model/){:target="\_blank"} is another popular management process for Git branches. For brevity reasons, we will not list all the details for all branch types, but it should be obvious that you can recreate all aspects of Git flow with Codefresh triggers.
-For example to run a pipeline only for pull requests from branches named `feature-XXX` that will be merged back to `develop` branch, you can create a trigger like this:
+For example, to run a pipeline only for pull requests from branches named `feature-XXX` that will be merged back to `develop` branch, you can create a trigger like this:
{% include image.html
lightbox="true"
@@ -323,7 +324,7 @@ caption="Git flow feature branch trigger"
max-width="50%"
%}
-To launch a pipeline that will only run when a commit happens on a release branch named `release-XXX` you can create a trigger like this:
+To launch a pipeline that will only run when a commit happens on a release branch named `release-XXX`, you can create a trigger like this:
{% include image.html
lightbox="true"
@@ -338,15 +339,14 @@ In a similar manner, you can create the triggers for all other branch types in G
## Create your own workflow
-Trunk-based development and Git-flow are only some examples of what a Git workflow can look like. Your organization might follow a completely different process. Using the basic building blocks of Codefresh triggers (branch field PR checkboxes etc) you should be able to model your own workflow according to your own pipelines.
+Trunk-based development and Git-flow are only some examples of what a Git workflow can look like. Your organization might follow a completely different process. Using the basic building blocks of Codefresh triggers (branch field, PR checkboxes, etc) you should be able to model your own workflow according to your own pipelines.
-## What to read next
-
-* [Codefresh YAML]({{site.baseurl}}/docs/codefresh-yaml/what-is-the-codefresh-yaml/)
-* [Pipeline steps]({{site.baseurl}}/docs/codefresh-yaml/steps/)
-* [Git Triggers]({{site.baseurl}}/docs/configure-ci-cd-pipeline/triggers/git-triggers/)
-* [YAML Examples]({{site.baseurl}}/docs/yaml-examples/examples/)
-* [Preview environments]({{site.baseurl}}/docs/ci-cd-guides/preview-environments/)
+## Related articles
+[Codefresh YAML for pipeline definitions]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/)
+[Steps in pipelines]({{site.baseurl}}/docs/pipelines/steps/)
+[Git triggers in pipelines]({{site.baseurl}}/docs/pipelines/triggers/git-triggers/)
+[CI/CD examples for pipelines]({{site.baseurl}}/docs/example-catalog/examples/)
+[Previewing dynamic environments]({{site.baseurl}}/docs/ci-cd-guides/preview-environments/)
diff --git a/_docs/ci-cd-guides/working-with-docker-registries.md b/_docs/ci-cd-guides/working-with-docker-registries.md
index 516fc835e..f2ba3308d 100644
--- a/_docs/ci-cd-guides/working-with-docker-registries.md
+++ b/_docs/ci-cd-guides/working-with-docker-registries.md
@@ -1,6 +1,6 @@
---
-title: "Working with Docker Registries"
-description: "How to push, pull and tag Docker images in Codefresh pipelines"
+title: "Working with Docker registries"
+description: "Push, pull, and tag Docker images in Codefresh pipelines"
group: ci-cd-guides
redirect_from:
- /docs/build-specific-revision-image/
@@ -9,11 +9,14 @@ redirect_from:
toc: true
---
-Codefresh contains first-class Docker registry support. This means that you don't need to manually write `docker login` and `docker pull/push` commands inside pipelines. You use instead declarative YAML and all credential configuration is configured centrally once.
+Codefresh contains first-class Docker registry support. This means that you don't need to manually write `docker login` and `docker pull/push` commands within pipelines. You can use declarative YAML, and all credentials are configured in a central location once.
## Viewing Docker images
-To see all images currently from [all your connected Registries]({{site.baseurl}}/docs/docker-registries/external-docker-registries/), select *Artifacts -> Images* from the left sidebar and you will see a sorted list of all images.
+To see all images from [all connected registries]({{site.baseurl}}/docs/integrations/docker-registries/):
+
+* In the Codefresh UI, from Artifacts in the sidebar, select [**Images**](https://g.codefresh.io/images/){:target="\_blank"}.
+ Each image displays basic details such as the Git branch, commit message, hash that created it, creation date, as well as all tags.
{%
include image.html
@@ -25,10 +28,19 @@ To see all images currently from [all your connected Registries]({{site.baseurl}
max-width="70%"
%}
-For each image you get some basic details such as the git branch, commit message and hash that created it, date of creation as well as all tags. You can click on any image and look at [its individual metadata]({{site.baseurl}}/docs/docker-registries/metadata-annotations/).
+* To view image metadata, click on the image. For details, see [Docker image metadata]({{site.baseurl}}/docs/pipelines/docker-image-metadata/).
+
+**Filters for Docker images**
+The top left of the Images page has several filters that allow you to search for a specific subset of Docker images.
+Filters include:
+* Tagged/untagged images
+* Base image name
+* Git branch
+* Tag
+* Pipeline volumes
-On the top left of the screen you can find several filters that allow you to search for a specific subset of Docker images:
+Multiple filters work in an `AND` manner.
{%
include image.html
@@ -40,32 +52,27 @@ On the top left of the screen you can find several filters that allow you to sea
max-width="40%"
%}
-Filters include:
-
-* Tagged/untagged images
-* Base image name
-* Git branch
-* Tag
-* Pipeline volumes
-
-You can add multiple filters and they will work in an `AND` manner.
-
-On the right side of the screen, you also have a list of buttons for actions on each Docker image.
-These are:
-* Launching a Docker image as a [test environment]({{site.baseurl}}/docs/getting-started/on-demand-environments/)
-* Promoting a Docker image (explained in the following sections)
-* Looking at the Docker commands that allow you to pull the image locally on your workstation
-* Re-running the pipeline that created this image
+**Actions for Docker images**
+On the right are the actions available foreach Docker image.
+You can:
+* Launch a Docker image as a [test environment]({{site.baseurl}}/docs/quick-start/ci-quick-start/on-demand-environments/)
+* Promote a Docker image (explained in the following sections)
+* Pull the image locally on your workstation with different commands
+* Re-run the pipeline that created the image
## Pulling Docker images
-Pulling Docker images in Codefresh is completely automatic. You only need to mention a Docker image by name and Codefresh will automatically pull it for you and use it in a pipeline.
+Pulling Docker images in Codefresh is completely automatic. You only need to mention a Docker image by name, and Codefresh automatically pulls it for you and uses it in a pipeline.
### Pulling public images
-To pull a public image from Dockerhub or other public registries you simply mention the name of the image and tag that you want to use. For example:
+To pull a public image from Docker Hub or other public registries:
+
+* Specify the name of the image and tag that you want to use.
+
+For example:
```yaml
CollectAllMyDeps:
@@ -75,7 +82,8 @@ CollectAllMyDeps:
- pip install .
```
-This [freestyle step]({{site.baseurl}}/docs/codefresh-yaml/steps/freestyle/) will pull from Dockerhub the image `python:3.6.4-alpine3.6` and then run the command `pip install .` inside it. You can see the images get pulled in the [Codefresh pipeline log]({{site.baseurl}}/docs/configure-ci-cd-pipeline/monitoring-pipelines/).
+This [freestyle step]({{site.baseurl}}/docs/pipelines/steps/freestyle/) pulls the image `python:3.6.4-alpine3.6` from Docker Hub, and then runs the command `pip install .` inside it.
+You can see the images that get pulled in the [Codefresh pipeline log]({{site.baseurl}}/docs/pipelines/monitoring-pipelines/).
{%
include image.html
@@ -87,22 +95,24 @@ This [freestyle step]({{site.baseurl}}/docs/codefresh-yaml/steps/freestyle/) wil
max-width="70%"
%}
-The image will also be cached in the [image cache]({{site.baseurl}}/docs/configure-ci-cd-pipeline/pipeline-caching/#distributed-docker-image-caching) without any other configuration.
+The image is also automatically cached in the [image cache]({{site.baseurl}}/docs/pipelines/pipeline-caching/#distributed-docker-image-caching).
-Codefresh will also automatically pull for you any images mentioned in Dockerfiles (i.e. the `FROM` directive) as well as [service containers]({{site.baseurl}}/docs/codefresh-yaml/service-containers/).
+Codefresh also automatically pull for you any images mentioned in Dockerfiles (i.e. the `FROM` directive) as well as [service containers]({{site.baseurl}}/docs/pipelines/service-containers/).
### Pulling private images
-To pull a private image from one of your connected registries, again you mention the image by name and tag. In order for Codefresh to understand that you are talking about a private image, you need to prepend the appropriate prefix of the registry domain.
+To pull a private image from one of your connected registries, in addition to specifying the image by name and tag, you must also prepend the appropriate prefix of the registry domain. The registry domain prefix is required for Codefresh to understand that it is a private image.
-For example, in the case of [ACR]({{site.baseurl}}/docs/docker-registries/external-docker-registries/azure-docker-registry/):
+For example, in the case of ACR (Azure Container Registry):
```
registry-name.azurecr.io/my-docker-repo/my-image-name:tag
```
-You can find the full name of any docker image by visiting the image dashboard and looking at the URL field of any tag:
+Get the full name of a Docker image:
+* In the Codefresh UI, from Artifacts in the sidebar, select [**Images**](https://g.codefresh.io/images/){:target="\_blank"}.
+* Click on the image and copy the image name from the Activity column, **Image promoted** label.
{%
include image.html
@@ -114,9 +124,9 @@ You can find the full name of any docker image by visiting the image dashboard a
max-width="65%"
%}
-The exact format of the full image name will depend on the type of registry you use. Codefresh will use the domain prefix of each image to understand which integration it will use. It will then take care of all `docker login` and `docker pull` commands on its own behind the scenes.
+The exact format of the image name depends on the type of registry you use. Codefresh uses the domain prefix of each image to understand which integration to use, and then takes care of all `docker login` and `docker pull` commands on its own behind the scenes.
-For example, if you have connected [Azure]({{site.baseurl}}/docs/docker-registries/external-docker-registries/azure-docker-registry/), [AWS]({{site.baseurl}}/docs/docker-registries/external-docker-registries/amazon-ec2-container-registry/) and [Google]({{site.baseurl}}/docs/docker-registries/external-docker-registries/google-container-registry/) registries, you can pull 3 images for each in a pipeline like this:
+For example, if you have connected [Azure]({{site.baseurl}}/docs/integrations/docker-registries/azure-docker-registry/), [AWS]({{site.baseurl}}/docs/integrations/docker-registries/amazon-ec2-container-registry/), and [Google]({{site.baseurl}}/docs/integrations/docker-registries/google-container-registry/) registries, you can pull three images for each in a pipeline like this:
`codefresh.yml`
@@ -142,14 +152,14 @@ steps:
{% endraw %}
{% endhighlight %}
-Codefresh will automatically login to each registry using the credentials you have defined centrally and pull all the images. The same thing will happen with Dockerfiles that mention any valid Docker image in their `FROM` directive.
+Codefresh automatically logs in to each registry using the credentials you have defined centrally, and pulls all the images. The same thing will happen with Dockerfiles that mention any valid Docker image in their `FROM` directive.
-### Pulling images that were just built in the same pipeline
+### Pulling images created in the same pipeline
-Codefresh allows you to create a Docker image on demand and use it in the same pipeline that created it. In several scenarios (such as [unit tests]({{site.baseurl}}/docs/testing/unit-tests/)) it is very common to use a Docker image right after it was built.
+Codefresh allows you to create a Docker image on demand and use it in the same pipeline that created it. In several scenarios (such as [unit tests]({{site.baseurl}}/docs/testing/unit-tests/)), it is very common to use a Docker image right after it is built.
-In that case, as a shortcut Codefresh allows you to simply [mention the name]({{site.baseurl}}/docs/codefresh-yaml/variables/#context-related-variables) of the respective [build step]({{site.baseurl}}/docs/codefresh-yaml/steps/build/).
+In that case, as a shortcut, Codefresh allows you to simply [specify the name]({{site.baseurl}}/docs/pipelines/variables/#context-related-variables) of the respective [build step]({{site.baseurl}}/docs/pipelines/steps/build/).
`codefresh.yml`
{% highlight yaml %}
@@ -178,11 +188,11 @@ steps:
{% endraw %}
{% endhighlight %}
-In this pipeline Codefresh:
+In the above pipeline, Codefresh:
-1. Checks out source code with the [git-clone step]({{site.baseurl}}/docs/codefresh-yaml/steps/git-clone/)
-1. Builds a Docker image that gets named `my-app-image:master`. Notice the lack of `docker push` commands
-1. In the next step, automatically uses that image and runs `python setup.py test` inside it. Again notice the lack of `docker pull` commands
+1. Checks out source code through a [git-clone step]({{site.baseurl}}/docs/pipelines/steps/git-clone/).
+1. Builds a Docker image, named `my-app-image:master`. Notice the lack of `docker push` commands.
+1. In the next step, automatically uses that image and runs `python setup.py test` inside it. Again, notice the lack of `docker pull` commands.
The important line here is the following:
@@ -206,14 +216,14 @@ You can see the automatic pull inside the Codefresh logs.
max-width="70%"
%}
-The image will still be pushed in your default Docker registry. If you don't want this behavior you can simply add the `disable_push` property in the build step.
+The image is still pushed to your default Docker registry. If you don't want this behavior, add the `disable_push` property in the build step.
## Pushing Docker images
-Pushing to your default Docker registry is completely automatic. All successful [build steps]({{site.baseurl}}/docs/codefresh-yaml/steps/build/) automatically push to the default Docker registry of your Codefresh account without any extra configuration.
+Pushing to your default Docker registry is completely automatic. All successful [build steps]({{site.baseurl}}/docs/pipelines/steps/build/) automatically push to the default Docker registry of your Codefresh account without any extra configuration.
-To push to another registry you only need to know how this registry is [linked into Codefresh]({{site.baseurl}}/docs/docker-registries/external-docker-registries/) and more specifically what is the unique name of the integration. You can see that name by visiting your [integrations screen](https://g.codefresh.io/account-admin/account-conf/integration/registry) or asking your Codefresh administrator.
+To push to another registry, you only need to know how this registry is [connected to Codefresh]({{site.baseurl}}/docs/integrations/docker-registries/), and more specifically, what is the unique name of the integration. You can see the name in the Codefresh UI, in [Docker Registry integrations](https://g.codefresh.io/account-admin/account-conf/integration/registryNew){:target="\_blank"}, or asking your Codefresh administrator.
{%
@@ -226,7 +236,7 @@ To push to another registry you only need to know how this registry is [linked i
max-width="50%"
%}
-Once you know the registry identifier you can use it in any [push step]({{site.baseurl}}/docs/codefresh-yaml/steps/push/) or [build step]({{site.baseurl}}/docs/codefresh-yaml/steps/build/) by mentioning the registry with that name:
+Once you know the registry identifier, you can use it in any [push step]({{site.baseurl}}/docs/pipelines/steps/push/) or [build step]({{site.baseurl}}/docs/pipelines/steps/build/) by specifying the registry with that name:
`codefresh.yml`
{% highlight yaml %}
@@ -249,8 +259,8 @@ Once you know the registry identifier you can use it in any [push step]({{site.b
{% endhighlight %}
Notice that
- * the `candidate` field of the push step mentions the name of the build step (`build_image`) that will be used for the image to be pushed
- * The registry is only identified by name (i.e. `azure-demo`). The domain and credentials are not part of the pipeline (they are already known to Codefresh by the Docker registry integration)
+ * the `candidate` field of the push step mentions the name of the build step (`build_image`) that will be used for the image to be pushed.
+ * The registry is only identified by name (`azure-demo` in the example). The domain and credentials are not part of the pipeline as they are already known to Codefresh through the Docker registry integration.
You can also override the name of the image with any custom name. This way the push step can choose any image name regardless of what was used in the build step.
@@ -275,13 +285,13 @@ Notice that
{% endraw %}
{% endhighlight %}
-Here the build step is creating an image named `my-app-image:master` but the push step will actually push it as `my-company/web-app:1.2.3`
+Here the build step creates an image named `my-app-image:master`, but the push step actually pushes it as `my-company/web-app:1.2.3`.
-For more examples such as using multiple tags, or pushing in parallel see the [push examples]({{site.baseurl}}/docs/codefresh-yaml/steps/push/#examples)
+For more examples, such as using multiple tags, or pushing in parallel, see the [push examples]({{site.baseurl}}/docs/pipelines/steps/push/#examples).
### Pushing images with an optional prefix
-There are some Registry providers that require a specific prefix for all your Docker images. This is often the name of an organization, account or other top-level construct defined by the Registry.
+There are some registry providers that require a specific prefix for all your Docker images. This is often the name of an organization, account, or other top-level construct defined by the registry.
`codefresh.yml`
{% highlight yaml %}
@@ -298,7 +308,9 @@ There are some Registry providers that require a specific prefix for all your Do
{% endraw %}
{% endhighlight %}
-The example above will push the final Docker image as `kostisazureregistry.azurecr.io/acme-company/trivial-go-web:latest`. However, you can also setup the prefix globally once in the [Docker integration screen]({{site.baseurl}}/docs/docker-registries/external-docker-registries/#using-an-optional-repository-prefix). This way you can simplify your pipelines and have them mention only the final image name.
+The example above will push the final Docker image as `kostisazureregistry.azurecr.io/acme-company/trivial-go-web:latest`.
+
+However, you can also set up the prefix globally once in the [Docker registry integrations]({{site.baseurl}}/docs/integrations/docker-registries/). This way you can simplify your pipelines and have them mention only the final image name.
{%
include image.html
@@ -310,7 +322,7 @@ The example above will push the final Docker image as `kostisazureregistry.azure
max-width="70%"
%}
-The example above will automatically prefix all your Docker images with `acme-company`.
+Using the repository prefix in the example above, automatically prefixes all your Docker images with `acme-company`.
Now you can simplify your build/push step as below:
@@ -333,15 +345,15 @@ The final Docker image will still be `kostisazureregistry.azurecr.io/acme-compan
## Working with multiple registries with the same domain
-With Codefresh you can [connect multiple registries on a global level]({{site.baseurl}}/docs/docker-registries/external-docker-registries/). This allows you to create pipelines that push/pull images to different registries without having to deal with Docker credentials inside the pipeline itself.
+With Codefresh, you can [connect multiple registries on a global level]({{site.baseurl}}/docs/integrations/docker-registries/). This allows you to create pipelines that push/pull images to different registries without having to deal with Docker credentials within the pipeline itself.
-However, there are several times where you have multiple registries that have the same domain. For example, you might have two Dockerhub accounts connected to Codefresh (so both of them can resolve images for the docker.io domain)
+However, there are several times where you have multiple registries that have the same domain. For example, you might have two Docker Hub accounts connected to Codefresh (so both of them can resolve images for the `docker.io` domain).
-This means that when you reference an image by domain name (e.g. in a freestyle step), Codefresh might not know which Docker registry account you want to use for the pull action.
+This means that when you reference an image by domain name, as in a freestyle step for example, Codefresh might not know which Docker registry account to use for the pull action.
-> Notice, that this is not a Codefresh limitation, but a Docker one. Even with vanilla Docker you cannot login to multiple registries at the same time if they share the same domain.
+> This is not a Codefresh limitation, but a Docker one. Even with vanilla Docker you cannot log in to multiple registries at the same time if they share the same domain.
-To solve this problem, Codefresh will automatically detect connected registries that have the same domain and allow you to designate the primary one, that will be used for image resolution when pulling Docker images.
+To solve this problem, Codefresh automatically detects connected registries that have the same domain and allow you to designate the primary one. The primary registry is used for image resolution when pulling Docker images.
{%
include image.html
@@ -353,17 +365,17 @@ To solve this problem, Codefresh will automatically detect connected registries
max-width="90%"
%}
-In the example above, even though two Dockerhub integrations are connected to Codefresh, only the primary one will be used for pulling images from the docker.io domain (You can still use the second one in push/build steps using the `registry` property).
+In the example above, even though two Docker Hub integrations are connected to Codefresh, only the primary one is used to pull images from the `docker.io` domain. You can still use the second one in push/build steps using the `registry` property.
You can override the default behavior in each pipeline, by adding the optional `registry_context` property to instruct Codefresh on how to use a specific registry for pulling Docker images (if you have more than one for the same domain).
-You can use the `registry_context` property in [build]({{site.baseurl}}/docs/codefresh-yaml/steps/build/), [push]({{site.baseurl}}/docs/codefresh-yaml/steps/push/), [freestyle]({{site.baseurl}}/docs/codefresh-yaml/steps/freestyle/) and [composition]({{site.baseurl}}/docs/codefresh-yaml/steps/composition/) steps.
+You can use the `registry_context` property in [build]({{site.baseurl}}/docs/pipelines/steps/build/), [push]({{site.baseurl}}/docs/pipelines/steps/push/), [freestyle]({{site.baseurl}}/docs/pipelines/steps/freestyle/), and [composition]({{site.baseurl}}/docs/pipelines/steps/composition/) steps.
The `registry_context` property takes as value the name of an external connected registry. Build and composition steps accept an array of values as `registry_contexts`. In all cases, by using this optional property you instruct Codefresh to use a specific registry for pulling images.
-> Notice that the optional `registry_context` and `registry_contexts` properties only affect the **pulling** of Docker images. The registry used for *pushing* images is still declared explicitly in build and push pipeline steps.
+> The optional `registry_context` and `registry_contexts` properties only affect the **pulling** of Docker images. The registry used for *pushing* images is still declared explicitly in build and push pipeline steps.
The syntax for the freestyle step is the following:
@@ -454,7 +466,7 @@ Let's look at an example. We assume that we have two GCR integrations:
max-width="90%"
%}
-The first integration is the "production" one and the second one is the "staging" one. The production one is designated as primary. This means that by default even though both integrations work for the gcr.io domain, only the primary one will be used in the Codefresh pipeline for pulling images.
+The first integration is the "production" one, and the second integration is the "staging" one. The production one is designated as primary. This means that by default even though both integrations work for the `gcr.io` domain, only the primary one is used in the Codefresh pipeline for pulling images.
Let's say however that you want to build a Docker image that has a `FROM` statement from an image that exists in the staging registry. The image should be pushed to the production registry. You can use the `registry_context` property as shown below:
@@ -477,10 +489,10 @@ Let's say however that you want to build a Docker image that has a `FROM` statem
Behind the scenes Codefresh will:
-1. First login to the "staging" Docker registry using the "staging" credentials
-1. Build the Docker image, by resolving the `FROM` statements with "staging" images, pulling them as needed using the staging credentials
-1. Tag the Docker image
-1. Login to the "production" Docker registry
+1. First log in to the "staging" Docker registry using the "staging" credentials.
+1. Build the Docker image, by resolving the `FROM` statements with "staging" images, pulling them as needed using the staging credentials.
+1. Tag the Docker image.
+1. Log in to the "production" Docker registry.
1. Push the final Docker image to the "production" registry.
If your primary Docker registry is also the one that is used in your pipelines, you don't need the `registry_context` property at all, as this is the default behavior. When searching for an image to pull Codefresh will look at all your Docker registries (if they manage only a single domain), plus your "primary" Docker registries in case you have multiple Docker registries for the same domain.
@@ -493,10 +505,11 @@ You can perform this action either from the Codefresh UI or automatically from p
### Promoting images via the Codefresh UI
-You have the capability to "promote" any image of your choosing and push it to an external Registry that you have integrated into Codefresh (such as Azure, Google, Bintray etc.)
+You have the capability to "promote" any image of your choosing and push it to an external registry you have integrated into Codefresh (such as Azure, Google, Bintray etc.).
-Visit the Docker image dashboard and click the *Promote* button for the image you wish to promote:
+1. In the Codefresh UI, from Artifacts in the sidebar, select [**Images**](https://g.codefresh.io/images/){:target="\_blank"}.
+1. To promote an image, in the row with the image, click the **Promote Image** icon on the right.
{%
include image.html
@@ -508,11 +521,13 @@ Visit the Docker image dashboard and click the *Promote* button for the image yo
max-width="50%"
%}
-You will get a list of your connected registries. Choose the target Registry and define the tag that you want to push. Then click the *Promote* button to "copy" this image from its existing registry to the target Registry.
+{:start="3"}
+1. From the list of connected registries, select the target registry, and define the tag that you want to push.
+1. To "copy" this image from the existing registry to the target registry, click **Promote**.
### Promoting images in pipelines
-You can also copy images from one registry to the other inside a pipeline.
+You can also copy images from one registry to the other within a pipeline.
This is accomplished by specifying an existing image in the `candidate` field of the push step.
For example:
@@ -530,9 +545,9 @@ For example:
{% endraw %}
{% endhighlight %}
-In the example above we promote an image from [GCR]({{site.baseurl}}/docs/docker-registries/external-docker-registries/google-container-registry/) to [ACR]({{site.baseurl}}/docs/docker-registries/external-docker-registries/azure-docker-registry/) (which is already setup as `azure-demo`).
+In the example above, we promote an image from [GCR]({{site.baseurl}}/docs/integrations/docker-registries/google-container-registry/) to [ACR]({{site.baseurl}}/docs/integrations/docker-registries/azure-docker-registry/), which is already set up as `azure-demo`.
-You can even "promote" Docker images within the same registry by simply creating new tags.
+You can even "promote" Docker images within the same registry by simply creating new tags.
For example:
`codefresh.yml`
@@ -548,13 +563,11 @@ For example:
{% endraw %}
{% endhighlight %}
-In the example above the image `my-azure-registry.azurecr.io/kostis-codefresh/my-python-app:1.2.3` is re-tagged as `my-azure-registry.azurecr.io/kostis-codefresh/my-python-app:prod`. A very common pattern is to mark images with a special tag such as `prod` **after** the image has been deployed successfully.
-
+In the example above, the image `my-azure-registry.azurecr.io/kostis-codefresh/my-python-app:1.2.3` is re-tagged as `my-azure-registry.azurecr.io/kostis-codefresh/my-python-app:prod`. A very common pattern is to mark images with a special tag such as `prod` **after** the image has been deployed successfully.
-## What to read next
-* [Push pipeline step]({{site.baseurl}}/docs/codefresh-yaml/steps/push/)
-* [External Docker Registries]({{site.baseurl}}/docs/docker-registries/external-docker-registries/)
-* [Accessing a Docker registry from your Kubernetes cluster]({{site.baseurl}}/docs/deploy-to-kubernetes/access-docker-registry-from-kubernetes/)
-* [Build and Push an image example]({{site.baseurl}}/docs/yaml-examples/examples/build-and-push-an-image/)
+## Related articles
+[Docker registry integrations for pipelines]({{site.baseurl}}/docs/integrations/docker-registries/)
+[Accessing a Docker registry from your Kubernetes cluster]({{site.baseurl}}/docs/ci-cd-guides/access-docker-registry-from-kubernetes/)
+[Build and push an image example]({{site.baseurl}}/docs/example-catalog/ci-examples/build-and-push-an-image/)
diff --git a/_docs/codefresh-yaml/condition-expression-syntax.md b/_docs/codefresh-yaml/condition-expression-syntax.md
deleted file mode 100644
index 4fd3e774d..000000000
--- a/_docs/codefresh-yaml/condition-expression-syntax.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Condition Expression Syntax"
-description: "Condition expressions can be included in each step in your codefresh.yml, and must be satisfied for the step to execute."
-group: codefresh-yaml
-redirect_from:
- - /docs/condition-expression-syntax/
- - /docs/codefresh-yaml/expression-condition-syntax/
-toc: true
----
-Each step in `codefresh.yml` file can contain conditions expressions that must be satisfied for the step to execute.
-
-This is a small example of where a condition expression can be used:
- `YAML`
-{% highlight yaml %}
-step-name:
- description: Step description
- image: image/id
- commands:
- - bash-command1
- - bash-command2
- when:
- condition:
- all:
- executeForMasterBranch: "{% raw %}'${{CF_BRANCH}}{% endraw %}' == 'master'"
-{% endhighlight %}
-
-A condition expression is a basic expression that is evaluated to true/false (to decide whether to execute or not to execute), and can have the following syntax:
-
-### Types
-
-{: .table .table-bordered .table-hover}
-| Type | True/False Examples | True/False |
-| ------- | ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
-| String | True: "hello" False: "" | {::nomarkdown}
String with content = true
Empty string = false
String with content = true
String comparison is lexicographic.{:/} |
-| Number | True: 5 True: 3.4 True: 1.79E+308 | {::nomarkdown}
{:/} |
-| Null | False: null | Always false |
-
-### Variables
-
-You can use the User Provided variables as explained in the [Variables]({{site.baseurl}}/docs/codefresh-yaml/variables/) documentation including the [variables
-exposed by each individual pipeline step]({{site.baseurl}}/docs/codefresh-yaml/variables/#step-variables).
-
-### Unary Operators
-
-{: .table .table-bordered .table-hover}
-| Operator | Operation |
-| ---------- | --------------------- |
-| `-` | Negation of numbers |
-| `!` | Logical NOT |
-
-### Binary Operators
-
-{: .table .table-bordered .table-hover}
-| Operator | Operation |
-| --------------------------- | ----------- |
-| Add, String Concatenation | `+` |
-| Subtract | `-` |
-| Multiply | `*` |
-| Divide | `/` |
-| Modulus | `%` |
-| Logical AND | `&&` |
-| Logical OR | `||` |
-
-### Comparisons
-
-{: .table .table-bordered .table-hover}
-| Operator | Operation |
-| ----------- | ---------------------- |
-| `==` | Equal to |
-| `!=` | Not equal to |
-| `>` | Greater than |
-| `>=` | Greater than or equal |
-| `<` | Less than |
-| `<=` | Less than or equal |
-
-### Functions
-
-{: .table .table-bordered .table-hover}
-| Function Name | Parameters | Return value | Example |
-| ------------- | ------------------ | -------------- | ----------------------- |
-| String | 0: number or string | String of input value. | `String(40) == '40'` |
-| Number | 0: number or string | Number of input value. | `Number('50') == 50` `Number('hello')` is invalid |
-| Boolean | 0: number or string | Boolean of input value. | `Boolean('123') == true` `Boolean('') == false` `Boolean(583) == true` `Boolean(0) == false` |
-| round | 0: number | Rounded number. | `round(1.3) == 1` `round(1.95) == 2` |
-| floor | 0: number | Number rounded to floor. | `floor(1.3) == 1` `floor(1.95) == 1` |
-| upper | 0: string | String in upper case. | `upper('hello') == 'HELLO'` |
-| lower | 0: string | String in lower case. | `lower('BYE BYE') == 'bye bye'` |
-| trim | 0: string | Trimmed string. | `trim(" abc ") == "abc"` |
-| trimLeft | 0: string | Left-trimmed string. | `trimLeft(" abc ") == "abc "` |
-| trimRight | 0: string | Right-trimmed string. | `trimRight(" abc ") == " abc"` |
-| replace | 0: string - main string 1: string - substring to find 2: string - substring to replace | Replace all instances of the sub-string (1) in the main string (0) with the sub-string (2). | `replace('hello there', 'e', 'a') == 'hallo thara'` |
-| substring | 0: string - main string 1: string - index to start 2: string - index to end | Returns a sub-string of a string. | `substring("hello world", 6, 11) == "world"` |
-| length | string | Length of a string. | `length("gump") == 4` |
-| includes | 0: string - main string 1: string - string to search for | Whether a search string is located within the main string. | `includes("codefresh", "odef") == true` |
-| indexOf | 0: string - main string 1: string - string to search for | Index of a search string if it is found inside the main string | `indexOf("codefresh", "odef") == 1` |
-| match | 0: string - main string 1: string - regular expression string, [JS style](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_Expressions) (Note: in JS strings, the backslash `\` is an escape character so in order to use a literal backslash, you need to escape it. For example: `"^\\d+$"` instead of `"^\d+$"`) 2: boolean - ignore case | Search for a regular expression inside a string, ignoring or not ignoring case | `match("hello there you", "..ll.", false) == true` `match("hello there you", "..LL.", false) == false` `match("hello there you", "hell$", true) == false` `match("hello there you", "^hell", true) == true` `match("hello there you", "bye", false) == false` |
-| Variable | string | Search for the value of a variable | `Variable('some-clone')` |
-| Member | 0: string - variable name 1: string - member name | Search for the value of a variable member | `Member('some-clone', 'working-directory')` |
-
-## What to read next
-
-* [Conditional Execution of Steps]({{site.baseurl}}/docs/codefresh-yaml/conditional-execution-of-steps/)
-* [Condition Expression Syntax]({{site.baseurl}}/docs/codefresh-yaml/condition-expression-syntax/)
-* [Working Directories]({{site.baseurl}}/docs/codefresh-yaml/working-directories/)
-* [Annotations]({{site.baseurl}}/docs/codefresh-yaml/annotations/)
-* [Pipeline/Step hooks]({{site.baseurl}}/docs/codefresh-yaml/hooks/)
diff --git a/_docs/codefresh-yaml/conditional-execution-of-steps.md b/_docs/codefresh-yaml/conditional-execution-of-steps.md
deleted file mode 100644
index 56eea7d73..000000000
--- a/_docs/codefresh-yaml/conditional-execution-of-steps.md
+++ /dev/null
@@ -1,155 +0,0 @@
----
-title: "Conditional Execution of Steps"
-description: "Skip specific pipeline steps according to one or more conditions"
-group: codefresh-yaml
-redirect_from:
- - /docs/conditional-execution-of-steps/
-toc: true
----
-For each step in a `codefresh.yml` file, you can define a set of conditions which need to be satisfied in order to execute the step. (An introduction to the `codefresh.yml` file can be found [here]({{site.baseurl}}/docs/codefresh-yaml/what-is-the-codefresh-yaml/).)
-
-There are currently two main methods to define conditions: branch conditions and expression conditions.
-
-## Branch Conditions
-
-Usually, you'll want to define a branch condition, be it of the type ```ignore``` for blacklisting a set of branches or of the type ```only``` for allowlisting a set of branches. Each branch specification can either be an exact branch name, e.g. ```master```, or a regular expression, e.g. ```/hotfix$/```. Case insensitive regexps (```/^FB-/i```) are also supported.
-
-Here are some examples:
-
-Only execute for the ```master``` branch:
-
- `only-master-branch.yml`
-{% highlight yaml %}
-build-step:
- description: Building the image.
- type: build
- dockerfile: Dockerfile
- image-name: someRepo/someUser
- when:
- branch:
- only:
- - master
-{% endhighlight %}
-
-Only execute for branches whose name begins with ```FB-``` prefix (feature branches):
-
- `only-feature-branches.yml`
-{% highlight yaml %}
-build-step:
- description: Building the image.
- type: build
- dockerfile: Dockerfile
- image-name: someRepo/someUser
- when:
- branch:
- only:
- - /^FB-.*/i
-{% endhighlight %}
-
-Ignore the develop branch and master branch:
-
- `ignore-master-and-develop-branch.yml`
-{% highlight yaml %}
-build-step:
- description: Building the image.
- type: build
- dockerfile: Dockerfile
- image-name: someRepo/someUser
- when:
- branch:
- ignore:
- - master
- - develop
-{% endhighlight %}
-
-
->We use [JavaScript regular expressions](https://developer.mozilla.org/en/docs/Web/JavaScript/Guide/Regular_Expressions) for the syntax in branch conditions.
-
-
-## Condition expressions
-
-Alternatively, you can use more advanced condition expressions.
-
-This follows the standard [condition expression syntax]({{site.baseurl}}/docs/codefresh-yaml/condition-expression-syntax/). In this case, you can choose to execute if ```all``` expression conditions evaluate to ```true```, or to execute if ```any``` expression conditions evaluate to ```true```.
-
-> Note: Use "" around variables with text to avoid errors in processing the conditions. ex: "${{CF_COMMIT_MESSAGE}}"
-
-Here are some examples. Execute if the string ```[skip ci]``` is not part of the main repository commit message AND if the branch is ```master```
-
- `all-conditions.yml`
-{% highlight yaml %}
-build-step:
- description: Building the image.
- type: build
- dockerfile: Dockerfile
- image-name: someRepo/someUser
- when:
- condition:
- all:
- noSkipCiInCommitMessage: 'includes(lower({% raw %}"${{CF_COMMIT_MESSAGE}}"{% endraw %}), "skip ci") == false'
- masterBranch: '{% raw %}"${{CF_BRANCH}}{% endraw %}" == "master"'
-{% endhighlight %}
-
-Execute if the string ```[skip ci]``` is not part of the main repository commit message, OR if the branch is not a feature branch (i.e. name starts with FB-)
-
- `any-condition.yml`
-{% highlight yaml %}
-build-step:
- description: Building the image.
- type: build
- dockerfile: Dockerfile
- image-name: someRepo/someUser
- when:
- condition:
- any:
- noSkipCiInCommitMessage: 'includes(lower({% raw %}"${{CF_COMMIT_MESSAGE}}"{% endraw %}), "skip ci") == false'
- notFeatureBranch: 'match({% raw %}"${{CF_BRANCH}}"{% endraw %}, "^FB-", true) == false'
-{% endhighlight %}
-
-## Execute steps according to the presence of a variable
-
-If a variable does not exist in a Codefresh pipeline, then it will simply stay as a string inside the definition. When the `{% raw %}${{MY_VAR}}{% endraw %}` variable is not available, the engine will literally print `{% raw %}${{MY_VAR}}{% endraw %}`, because that variable doesn't exist.
-
-You can use this mechanism to decide which steps will be executed if a [variable]({{site.baseurl}}/docs/codefresh-yaml/variables/) exists or not.
-
-
-
-`codefresh.yml`
-{% highlight yaml %}
-{% raw %}
-version: "1.0"
-steps:
- step1:
- title: "Running if variable exists"
- type: "freestyle"
- image: "alpine:3.9"
- commands:
- - echo "Step 1 is running"
- when:
- condition:
- all:
- whenVarExists: 'includes("${{MY_VAR}}", "{{MY_VAR}}") == false'
- step2:
- title: "Running if variable does not exist"
- type: "freestyle"
- image: "alpine:3.9"
- commands:
- - echo "Step 2 is running"
- when:
- condition:
- all:
- whenVarIsMissing: 'includes("${{MY_VAR}}", "{{MY_VAR}}") == true'
-{% endraw %}
-{% endhighlight %}
-
-Try running the pipeline above and see how it behaves when a variable called `MY_VAR` exists (or doesn't exist).
-
->Notice that if you use this pattern a lot it means that you are trying to create a complex pipeline that is very smart. We suggest you create instead multiple [simple pipelines for the same project]({{site.baseurl}}/docs/ci-cd-guides/pull-request-branches/#trunk-based-development).
-
-## What to read next
-
-* [Codefresh YAML]({{site.baseurl}}/docs/codefresh-yaml/what-is-the-codefresh-yaml/)
-* [Variables]({{site.baseurl}}/docs/codefresh-yaml/variables/)
-* [Condition syntax]({{site.baseurl}}/docs/codefresh-yaml/condition-expression-syntax/)
-* [Pull Requests and Branches]({{site.baseurl}}/docs/ci-cd-guides/pull-request-branches/)
-* [Pipeline/Step hooks]({{site.baseurl}}/docs/codefresh-yaml/hooks/)
diff --git a/_docs/codefresh-yaml/post-step-operations.md b/_docs/codefresh-yaml/post-step-operations.md
deleted file mode 100644
index 1d367309b..000000000
--- a/_docs/codefresh-yaml/post-step-operations.md
+++ /dev/null
@@ -1,117 +0,0 @@
----
-title: "Post-Step Operations"
-description: "Annotate your builds and run extra steps"
-group: codefresh-yaml
-redirect_from:
- - /docs/post-step-operations/
-toc: true
----
-Post-step operations are a set of optional predefined processes that can be configured on any step. These operations will be executed once the step has completed. The post-step operations allow you to annotate your builds, images and pipelines with extra metadata or run other steps.
-
-
-## Result Aware Post-Step Operations
-You may execute post-step operations conditionally, based on the outcome of the step itself.
-
-To execute operations only when the step has completed successfully, use `on_success`:
-
-
-{% highlight yaml %}
-step_name:
- ...
- on_success:
- ...
-{% endhighlight %}
-
-To execute operations only when the step has failed, use `on_fail`:
-
-
-{% highlight yaml %}
-step_name:
- ...
- on_fail:
- ...
-{% endhighlight %}
-
-## Result Agnostic Post-Step Operations
-You may execute post-step operations regardless of the outcome of the step itself.
-
-To execute operations regardless of the result, use `on_finish`:
-
-
-{% highlight yaml %}
-step_name:
- ...
- on_finish:
- ...
-{% endhighlight %}
-
-## Available Post-Step Operations
-
-- [Image Metadata]({{site.baseurl}}/docs/docker-registries/metadata-annotations/)
-- [Custom Annotations]({{site.baseurl}}/docs/codefresh-yaml/annotations/)
-- [Hooks]({{site.baseurl}}/docs/codefresh-yaml/hooks/)
-
-## Example
-
-Marking a Docker image with the results of unit tests:
-
-{% highlight yaml %}
-{% raw %}
-build_step:
- title: Building My Docker image
- type: build
- image_name: my-app-image
- tag: 1.0.1
- dockerfile: Dockerfile
-run_tests:
- title: Running unit tests
- image: ${{build_step}}
- commands:
- - npm install
- - npm run test
- on_success: # Execute only once the step succeeded
- metadata:
- set:
- - ${{build_step.imageId}}:
- - unit_tests: passed
-{% endraw %}
-{% endhighlight %}
-
-## Running other steps
-
-If you want to run another step in the pipeline when another step fails or succeeds you need to use [conditional execution of steps]({{site.baseurl}}/docs/codefresh-yaml/conditional-execution-of-steps/) and the `fail_fast` property. You can also use [step hooks]({{site.baseurl}}/docs/codefresh-yaml/hooks/) for dedicated post step actions.
-
-{% highlight yaml %}
-{% raw %}
-run_tests:
- title: Running unit tests
- image: node:11
- fail_fast: false
- commands:
- - npm install
- - npm run test
-print_error_message:
- image: alpine:latest
- title: Marking pipeline status
- commands:
- - echo "Unit tests failed"
- when:
- condition:
- all:
- myCondition: run_tests.result == 'failure'
-{% endraw %}
-{% endhighlight %}
-
-In this example the step `print_error_message` will only run if step `run_tests` has failed.
-
-See also [advanced workflows]({{site.baseurl}}/docs/codefresh-yaml/advanced-workflows/#single-step-dependencies) and [Pipeline/Step hooks]({{site.baseurl}}/docs/codefresh-yaml/hooks/).
-
-## What to read next
-
-* [Conditional Execution of Steps]({{site.baseurl}}/docs/codefresh-yaml/conditional-execution-of-steps/)
-* [Condition Expression Syntax]({{site.baseurl}}/docs/codefresh-yaml/condition-expression-syntax/)
-* [Working Directories]({{site.baseurl}}/docs/codefresh-yaml/working-directories/)
-* [Annotations]({{site.baseurl}}/docs/codefresh-yaml/annotations/)
-* [Pipeline/Step hooks]({{site.baseurl}}/docs/codefresh-yaml/hooks/)
-
-
diff --git a/_docs/codefresh-yaml/stages.md b/_docs/codefresh-yaml/stages.md
deleted file mode 100644
index aac05a2ea..000000000
--- a/_docs/codefresh-yaml/stages.md
+++ /dev/null
@@ -1,193 +0,0 @@
----
-title: "Pipeline Stages"
-description: "Grouping steps in stages for better visualization"
-group: codefresh-yaml
-toc: true
----
-
-With Codefresh you can [create really complex pipelines]({{site.baseurl}}/docs/configure-ci-cd-pipeline/pipelines/) with any number of steps. To better visualize the pipeline, you can group several steps into a single _stage_ that will show up as a separate column in the [pipeline view]({{site.baseurl}}/docs/configure-ci-cd-pipeline/monitoring-pipelines/).
-
-{% include
-image.html
-lightbox="true"
-file="/images/codefresh-yaml/stages/complex-pipeline.png"
-url="/images/codefresh-yaml/stages/complex-pipeline.png"
-alt="Complex pipeline"
-caption="Complex pipeline"
-max-width="70%"
-%}
-
-In this example there are 4 pipeline stages.
-
-## Assigning steps to a stage.
-
-Stages are completely optional and for really small pipelines they are not needed at all.
-By default, all pipeline steps are shown one after the other.
-
-{% include
-image.html
-lightbox="true"
-file="/images/codefresh-yaml/stages/linear-view.png"
-url="/images/codefresh-yaml/stages/linear-view.png"
-alt="Default pipeline view"
-caption="Default pipeline view"
-max-width="50%"
-%}
-
-This view works ok for small pipelines, but for a big number of steps it is better to group them into pipeline *stages* like shown below:
-
-{% include
-image.html
-lightbox="true"
-file="/images/codefresh-yaml/stages/example.png"
-url="/images/codefresh-yaml/stages/example.png"
-alt="Different pipeline stages"
-caption="Different pipeline stages"
-max-width="80%"
-%}
-
-The number of stages (i.e columns) and their titles is completely configurable.
-To enable this view, you need to make two modifications at the `codefresh.yml` file:
-
-Here is the skeleton:
-
- `codefresh.yml`
-{% highlight yaml %}
-version: '1.0'
-stages:
- - [stage-name-1]
- - [stage-name-2]
-
-steps:
- step-name:
- [step-contents]
- stage: [name-of-stage]
- another-step:
- [step-contents]
- stage: [name-of-stage]
- the-very-last-step:
- [step-contents]
- stage: [name-of-stage]
-{% endhighlight %}
-
-As you can see the modifications needed are:
-
-1. To list all the stage names at the root of the pipeline file
-1. To use the `stage` property on each step to assign it to a stage
-
->This updated pipeline view is only a nice way to visualize the pipeline. It does not affect the order of step execution. Steps will still execute in the same order listed in the `codefresh.yml` file. If you wish to use parallel execution and advanced workflows see the [parallel steps]({{site.baseurl}}/docs/codefresh-yaml/advanced-workflows/) page.
-
-
-## Example pipeline with several stages
-
-Here is a more concrete example that you can use as a starting point:
-
- `codefresh.yml`
-{% highlight yaml %}
-{% raw %}
-version: '1.0'
-stages:
- - prepare
- - test
- - build
- - scan
- - integration
- - deploy
-steps:
- step1:
- stage: 'prepare'
- image: node
- commands:
- - 'echo "Hello Step 1!"'
- step2:
- image: node
- stage: 'prepare'
- commands:
- - 'echo "Hello Step 2!"'
- step3:
- image: node
- stage: 'test'
- commands:
- - 'echo "Hello Step 3!"'
- step4:
- image: node
- stage: 'build'
- commands:
- - 'echo "Hello Step 4!"'
- step5:
- image: node
- stage: 'scan'
- commands:
- - 'echo "Hello Step 5!"'
- step6:
- image: node
- stage: 'scan'
- commands:
- - 'echo "Hello Step 6!"'
- step7:
- image: node
- stage: 'integration'
- commands:
- - 'echo "Hello Step 7!"'
- step8:
- image: node
- stage: 'deploy'
- commands:
- - 'echo "Hello Step 8!"'
- step9:
- image: node
- stage: 'deploy'
- commands:
- - 'echo "Hello Step 9!"'
-{% endraw %}
-{% endhighlight %}
-
-If you run the pipeline you will see this view
-
-{% include
-image.html
-lightbox="true"
-file="/images/codefresh-yaml/stages/complex.png"
-url="/images/codefresh-yaml/stages/complex.png"
-alt="Complex Pipeline view"
-caption="Complex Pipeline view"
-max-width="80%"
-%}
-
-Remember that the assignment of a step to a stage is happening only for graphical grouping purposes. It does
-not affect the way your steps run. All steps will still run in the same order mentioned in the `codefresh.yml` file.
-
-Also notice if you enable this view a stage called *default* will show all build steps that are not explicitly assigned to a stage.
-
-## Using spaces in stage names
-
-If you wish to have spaces in stage names you need to quote them like this:
-
- `codefresh.yml`
-{% highlight yaml %}
-{% raw %}
-version: '1.0'
-stages:
-- 'my build phase'
-- 'my test phase'
-steps:
- MyAppDockerImage:
- title: Building Docker Image
- stage: 'my build phase'
- type: build
- image_name: my-app
- dockerfile: Dockerfile
- MyUnitTests:
- title: Unit testing
- stage: 'my test phase'
- image: ${{MyAppDockerImage}}
- commands:
- - npm run test
-{% endraw %}
-{% endhighlight %}
-
-
-## What to read next
-
-* [Pipeline steps]({{site.baseurl}}/docs/codefresh-yaml/steps/)
-* [Parallel workflows]({{site.baseurl}}/docs/codefresh-yaml/advanced-workflows/)
diff --git a/_docs/codefresh-yaml/steps/approval.md b/_docs/codefresh-yaml/steps/approval.md
deleted file mode 100644
index 1d5286560..000000000
--- a/_docs/codefresh-yaml/steps/approval.md
+++ /dev/null
@@ -1,350 +0,0 @@
----
-title: "Approval"
-description: "How to Pause Pipelines for Manual Approval"
-group: codefresh-yaml
-sub_group: steps
-toc: true
----
-
-The approval step allows you to pause a pipeline and wait for human intervention before going on.
-
-{% include
-image.html
-lightbox="true"
-file="/images/codefresh-yaml/approval/approval-waiting.png"
-url="/images/codefresh-yaml/approval/approval-waiting.png"
-alt="Manual Approval step"
-caption="Manual Approval step"
-max-width="80%"
-%}
-
-Some example scenarios for using the approval step:
-
-* Pause before deploying to production
-* Pause before destroying an environment
-* Pause for some manual smoke tests or metric collection
-
-## Usage
-
- `YAML`
-{% highlight yaml %}
-{% raw %}
-step_name:
- type: pending-approval
- title: Step Title
- description: Step description
- timeout:
- duration: 2
- finalState: approved
- timeUnit: minutes
- when:
- branch:
- only: [ master ]
-
-{% endraw %}
-{% endhighlight %}
-
-## Fields
-
-{: .table .table-bordered .table-hover}
-| Field | Description | Required/Optional/Default |
-| ------------------------------------------ | ---------------------------------------------- | ------------------------- |
-| `title` | The free-text display name of the step. | Optional |
-| `description` | A basic, free-text description of the step. | Optional |
-| `timeout` | Defines an automatic approval/rejection if a specified amount of time has passed. The `duration` field is hours. By default it is set to 168 (i.e, 7 days). The `finalState` field defines what will happen after the duration time has elapsed. Possible values are `approved`/`denied`/`terminated` | Optional |
-| `timeUnit` | This field defines possible options of `minutes`, or `hours`. If the field is not set, the default is `hours` | Optional
-| `fail_fast` | If set to false, the pipeline will continue even when the step is rejected | Optional |
-| `stage` | Parent group of this step. See [using stages]({{site.baseurl}}/docs/codefresh-yaml/stages/) for more information. | Optional |
-| `when` | Define a set of conditions that need to be satisfied in order to execute this step. You can find more information in the [Conditional Execution of Steps]({{site.baseurl}}/docs/codefresh-yaml/conditional-execution-of-steps/) article. | Optional |
-
-
-## Pausing the Pipeline
-
-Once the pipeline reaches an approval step it will stop. At this point it **does not** consume any resources.
-In the Codefresh UI you will see the *Approve/Reject* buttons.
-
-{% include
-image.html
-lightbox="true"
-file="/images/codefresh-yaml/approval/build-waiting.png"
-url="/images/codefresh-yaml/approval/build-waiting.png"
-alt="Build waiting for input"
-caption="Build waiting for input"
-max-width="80%"
-%}
-
-Once you click any of them the pipeline will continue. Further steps in the pipeline can be enabled/disabled
-according to the approval result.
-
-## Automatic Approvals/Rejections
-
-By default, a pipeline that contains an approval step will pause for 7 days (168 hours) onces it reaches that step. If you want some automatic action to happen after a specified time period you can define it in advance with the `timeout` property:
-
-`codefresh.yml`
-{% highlight yaml %}
-{% raw %}
-version: '1.0'
-steps:
- waitForInputBeforeProduction:
- type: pending-approval
- title: Deploy to Production?
- timeout:
- duration: 2
- finalState: denied
-{% endraw %}
-{% endhighlight %}
-
-This pipeline will wait for approval for two hours. If somebody approves it, it will continue. If nothing happens after two hours
-the approval step will be automatically rejected.
-
-## Approval Restrictions
-
-By default, any Codefresh user can approve any pipeline that is paused at the approval state. If you want to restrict
-the approval action to a subset of people, you can use the [Access Control facilities]({{site.baseurl}}/docs/enterprise/access-control/) that Codefresh provides.
-
-This is a two-step process. First you need to tag your pipeline with one or more tags (tag names are arbitrary). You can edit tags in the pipeline settings screen.
-
-{% include
-image.html
-lightbox="true"
-file="/images/codefresh-yaml/approval/pipeline-tag.png"
-url="/images/codefresh-yaml/approval/pipeline-tag.png"
-alt="Marking a pipeline with tags"
-caption="Marking a pipeline with tags"
-max-width="40%"
-%}
-
-Once you have tagged your pipelines you can create one or more access rules that restrict approval to specific teams within your organization.
-
-{% include
-image.html
-lightbox="true"
-file="/images/codefresh-yaml/approval/approval-rule.png"
-url="/images/codefresh-yaml/approval/approval-rule.png"
-alt="Rules for approvals"
-caption="Rules for approvals"
-max-width="80%"
-%}
-
-
-For more details on access control and users see also the [access control page]({{site.baseurl}}/docs/administration/access-control/).
-
-## Keeping the Shared Volume after an Approval
-
-As soon as a pipeline starts waiting for an approval, all contents of the [shared Codefresh volume]({{site.baseurl}}/docs/configure-ci-cd-pipeline/introduction-to-codefresh-pipelines/#sharing-the-workspace-between-build-steps) are lost. Once the pipeline continues running all files that were created manually inside the volume are not available any more.
-
-If you want to keep any temporary files that were there before the approval, you need to enable the respective policy in your [pipeline settings]({{site.baseurl}}/docs/configure-ci-cd-pipeline/pipelines/#policies).
-
-You can either set this option differently per pipeline, or globally in your account at your [account settings](https://g.codefresh.io/account-admin/account-conf/pipeline-settings).
-
-{% include
-image.html
-lightbox="true"
-file="/images/codefresh-yaml/approval/keep-volume.png"
-url="/images/codefresh-yaml/approval/keep-volume.png"
-alt="Preserve Codefresh volume after an approval"
-caption="Preserve Codefresh volume after an approval"
-max-width="90%"
-%}
-
->Notice that if you do decide to keep the volume after an approval, the pipeline will still count as "running" against your pricing plan (if you use the SAAS version of Codefresh). If you don't keep the volume, the pipeline is stopped/paused while it is waiting for approval and doesn't count against your pricing plan. We advise you to keep the volume only for pipelines that really need this capability.
-
->Notice also that you if you use the [Hybrid version]({{site.baseurl}}/docs/administration/behind-the-firewall/) of Codefresh and your [Runner]({{site.baseurl}}/docs/administration/codefresh-runner/) is setup with local volumes, then the volume will only be present if the dind pod
-is scheduled in the same node once the pipeline resumes. Otherwise the volume will not be reused.
-
-## Controlling the Rejection Behavior
-
-By default if you reject a pipeline, it will stop right away and it will be marked as failed. All subsequent steps after the approval one will not run at all.
-
-You might want to continue running the pipeline even when it is rejected by adding the `fail_fast` property in the approval step:
-
-`codefresh.yml`
-{% highlight yaml %}
-{% raw %}
-version: '1.0'
-steps:
- waitForInputBeforeProduction:
- fail_fast: false
- type: pending-approval
- title: Deploy to Production?
-{% endraw %}
-{% endhighlight %}
-
-In this case you can also read the approval result and make the pipeline work differently according to each choice (demonstrated in the following section).
-
-
-## Getting the Approval Result
-
-As also explained in [step dependencies]({{site.baseurl}}/docs/codefresh-yaml/advanced-workflows/#custom-steps-dependencies) all steps in the Codefresh pipeline belong to a global object
-called `steps` (indexed by name). You can read the `result` property for an approval step to see if it was approved or rejected.
-
-Here is an example:
-
-`codefresh.yml`
-{% highlight yaml %}
-{% raw %}
-version: '1.0'
-steps:
- askForPermission:
- type: pending-approval
- title: Destroy QA environment?
- destroyQaEnvNow:
- image: alpine:3.8
- title: Destroying env
- commands:
- - echo "Destroy command running"
- when:
- steps:
- - name: askForPermission
- on:
- - approved
-{% endraw %}
-{% endhighlight %}
-
-In this example the second step that is destroying an environment will only run if the user
-approves the first step. In case of rejection the second step will be skipped.
-
-You can follow the same pattern for running steps when an approval step was rejected.
-Here is a full example with both cases.
-
-`codefresh.yml`
-{% highlight yaml %}
-{% raw %}
-version: '1.0'
-stages:
-- prepare
-- yesPleaseDo
-- noDont
-
-steps:
- step_1:
- image: alpine:3.8
- title: building chart
- stage: prepare
- commands:
- - echo "prepare"
- deployToProdNow:
- fail_fast: false
- type: pending-approval
- title: Should we deploy to prod
- stage: prepare
- step_2:
- image: alpine:3.8
- title: prepare environment
- stage: yesPleaseDo
- commands:
- - echo "world"
- when:
- steps:
- - name: deployToProdNow
- on:
- - approved
- step_3:
- image: alpine:3.8
- title: deploy to production
- stage: yesPleaseDo
- commands:
- - echo "world"
- when:
- steps:
- - name: deployToProdNow
- on:
- - approved
- step_4:
- image: alpine:3.8
- title: prepare environment
- stage: noDont
- commands:
- - echo "world"
- when:
- steps:
- - name: deployToProdNow
- on:
- - denied
- step_5:
- image: alpine:3.8
- title: deploy to staging
- stage: noDont
- commands:
- - echo "world"
- when:
- steps:
- - name: deployToProdNow
- on:
- - denied
-{% endraw %}
-{% endhighlight %}
-
-Here is the pipeline state after a rejection:
-
-{% include
-image.html
-lightbox="true"
-file="/images/codefresh-yaml/approval/pipeline-rejected.png"
-url="/images/codefresh-yaml/approval/pipeline-rejected.png"
-alt="Rejecting a pipeline"
-caption="Rejecting a pipeline"
-max-width="80%"
-%}
-
->Note that we have added the `fail_fast` property in the approval step because we want the pipeline to continue even when the step is rejected.
-
-
-You can see that only two steps were ignored. If you rerun the pipeline and approve
-it, the other two steps will be ignored.
-
-## Define Concurrency Limits
-
-Codefresh has the ability to limit the amount of running builds for a specific pipeline with several concurrency policies in the pipeline settings. You can choose if a build that is in a pending approval state will count against the concurrency limits or not.
-
-As an example let's say that the concurrency limit for a specific pipeline is set to 2. Currently there is one active/running build and a second build that is pending approval.
-
-1. If the pipeline settings define that builds in pending approval **count** against concurrency, then if you launch a third build it will wait until one of the first two has finished
-1. If the pipeline settings define that builds in pending approval **do not** count against concurrency, then if you launch a third build it will execute right away.
-
-There isn't a correct or wrong way to set this option. It depends on your organization and if your consider builds pending approval as "active" or not.
-
-You can either set this option [differently per pipeline]({{site.baseurl}}/docs/configure-ci-cd-pipeline/pipelines/#policies), or globally in your account at your [account settings](https://g.codefresh.io/account-admin/account-conf/pipeline-settings).
-
-
-## Slack Integration
-
-If you also enable [Slack integration]({{site.baseurl}}/docs/integrations/notifications/slack-integration/) in Codefresh you will have the choice of approving/rejecting a pipeline
-via a Slack channel
-
-{% include
-image.html
-lightbox="true"
-file="/images/codefresh-yaml/approval/slack-approval.png"
-url="/images/codefresh-yaml/approval/slack-approval.png"
-alt="Approval step in a slack channel"
-caption="Approval step in a slack channel"
-max-width="80%"
-%}
-
-To enable this behavior, you need to activate it in the Slack settings page:
-
-{% include
-image.html
-lightbox="true"
-file="/images/codefresh-yaml/approval/slack-settings.png"
-url="/images/codefresh-yaml/approval/slack-settings.png"
-alt="Slack settings"
-caption="Slack settings"
-max-width="50%"
-%}
-
-Also, if you run a pipeline manually that includes an approval step you should check
-the "Report notification of pipeline execution" checkbox as explained in [Monitoring Pipelines](
-{{site.baseurl}}/docs/configure-ci-cd-pipeline/monitoring-pipelines/#monitoring-pipelines-outside-the-codefresh-ui).
-
-
-
-## What to read next
-
-- [Post-Step Operations]({{site.baseurl}}/docs/codefresh-yaml/post-step-operations/)
-- [Advanced Workflows ]({{site.baseurl}}/docs/codefresh-yaml/advanced-workflows/)
-- [Conditional Execution of Steps]({{site.baseurl}}/docs/codefresh-yaml/conditional-execution-of-steps/)
-- [Creating pipelines]({{site.baseurl}}/docs/configure-ci-cd-pipeline/pipelines/)
-
-
diff --git a/_docs/codefresh-yaml/steps/build.md b/_docs/codefresh-yaml/steps/build.md
deleted file mode 100644
index e432275c4..000000000
--- a/_docs/codefresh-yaml/steps/build.md
+++ /dev/null
@@ -1,380 +0,0 @@
----
-title: "Build"
-description: "Building Docker images in Codefresh pipelines"
-group: codefresh-yaml
-sub_group: steps
-redirect_from:
- - /docs/build-1/
- - /docs/codefresh-yaml/steps/build-1/
-toc: true
----
-Use Docker to build an image and store it in Codefresh.
-
-## Purpose of build steps
-
-In Codefresh, docker containers are first-class citizens
-and special typed steps are offered for the most usual docker commands. Build steps are a secure replacement for `docker build` commands.
-
-Therefore, this command on your local workstation:
-
-```
-docker build . -t my-app-image:1.0.1
-```
-
-will become in Codefresh the following build step.
-
-```yaml
-BuildMyImage:
- title: Building My Docker image
- type: build
- image_name: my-app-image
- tag: 1.0.1
-```
-
-## Usage
-
- `YAML`
-{% highlight yaml %}
-step_name:
- type: build
- title: Step Title
- description: Free text description
- working_directory: {% raw %}${{clone_step_name}}{% endraw %}
- dockerfile: path/to/Dockerfile
- image_name: owner/new-image-name
- tag: develop
- build_arguments:
- - key=value
- target: stage1
- no_cache: false
- no_cf_cache: false
- tag_policy: original
- fail_fast: false
- metadata:
- set:
- - qa: pending
- when:
- condition:
- all:
- noDetectedSkipCI: "includes('{% raw %}${{CF_COMMIT_MESSAGE}}{% endraw %}', '[skip ci]') == false"
- on_success:
- ...
- on_fail:
- ...
- on_finish:
- ...
- retry:
- ...
-{% endhighlight %}
-
-## Fields
-
-{: .table .table-bordered .table-hover}
-| Field | Description | Required/Optional/Default |
-| ------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------- |
-| `title` | The free-text display name of the step. | Optional |
-| `description` | A basic, free-text description of the step. | Optional |
-| `stage` | Parent group of this step. See [using stages]({{site.baseurl}}/docs/codefresh-yaml/stages/) for more information. | Optional |
-| `working_directory` | The directory in which the build command is executed. It can be an explicit path in the container's file system, or a variable that references another step. The default is {% raw %} `${{main_clone}}` {% endraw %}. This only changes the Docker build context and is unrelated to the `WORKDIR` inside the Dockerile | Default |
-| `dockerfile` | The path to the `Dockerfile` from which the image is built. The default is `Dockerfile`. | Default |
-| `image_name` | The name for the image you build. | Required |
-| `region` | Relevant only for [Amazon ECR]({{site.baseurl}}/docs/integrations/docker-registries/amazon-ec2-container-registry/) integrations using either service accounts or explicit credentials. The names of the regions for which to perform cross-region replication. The names of the source region and the destination region name must be defined in separate steps. | Optional |
-| `tag` | The tag that is assigned to the image you build. The default is the name of the branch or revision that is built. | Default |
-| `tags` | Multiple tags under which to push the image. Use either this or `tag`. This is an array, so should be of the following style: {::nomarkdown}
tags: -tag1 -tag2 -{% raw %}${{CF_BRANCH_TAG_NORMALIZED}}{% endraw %} -tag4
{:/}or {::nomarkdown}
tags:['tag1','tag2','{% raw %}${{CF_BRANCH_TAG_NORMALIZED}}{% endraw %}','tag4']
{:/} | Optional |
-| `registry` | The registry logical name of one of the inserted registries from the integration view. The default value will be your default registry [if you have more than one]({{site.baseurl}}/docs/docker-registries/external-docker-registries/). | Optional |
-| `registry_contexts` | Advanced property for resolving Docker images when [working with multiple registries with the same domain]({{site.baseurl}}/docs/docker-registries/working-with-docker-registries/#working-with-multiple-registries-with-the-same-domain) | Optional |
-|`disable_push` | Do not push to any registry automatically. | Optional |
-|`tag_policy` | Push the tag name without change or lowercase it automatically. By default `tag: MixedCase` will be pushed as `image_name:mixedcase`. Possible options are `original` and `lowercase`. Default is `lowercase` | Default |
-| `no_cache` | Disable Docker engine cache for the build [more info](https://codefresh.io/docs/docs/troubleshooting/common-issues/disabling-codefresh-caching-mechanisms/) | Optional |
-| `no_cf_cache` | Disable Codefresh build optimization for the build [more info](https://codefresh.io/docs/docs/troubleshooting/common-issues/disabling-codefresh-caching-mechanisms/)
-| `build_arguments` | A set of [Docker build arguments](https://docs.docker.com/engine/reference/commandline/build/#set-build-time-variables-build-arg) to pass to the build process. | Optional |
-| `target` | target stage in a multistage build (build will run until this stage) | Optional |
-| `fail_fast` | If a step fails, and the process is halted. The default value is `true`. | Default |
-| `when` | Define a set of conditions that need to be satisfied in order to execute this step. You can find more information in the [Conditional Execution of Steps]({{site.baseurl}}/docs/codefresh-yaml/conditional-execution-of-steps/) article. | Optional |
-| `metadata` | Annotate the built image with [key-value metadata]({{site.baseurl}}/docs/docker-registries/metadata-annotations/). | Optional |
-| `on_success`, `on_fail` and `on_finish` | Define operations to perform upon step completion using a set of predefined [Post-Step Operations]({{site.baseurl}}/docs/codefresh-yaml/post-step-operations/). | Optional |
-| `retry` | Define retry behavior as described in [Retrying a step]({{site.baseurl}}/docs/codefresh-yaml/what-is-the-codefresh-yaml/#retrying-a-step). | Optional |
-| `buildkit` | Set to `true` to enable [Buildkit]({{site.baseurl}}/docs/codefresh-yaml/steps/build/#buildkit-support) and all of its enhancements | Optional |
-
-**Exported resources:**
-- Working Directory
-- Image ID
-
-## Examples
-
-Build an image using a Dockerfile in the root project folder:
-
-`codefresh.yml`
-{% highlight yaml %}
-version: '1.0'
-steps:
- BuildMyImage:
- title: Building My Docker image
- image_name: my-app-image
- type: build
-{% endhighlight %}
-
-Build an image using a different Dockerfile and a specific version tag
-
-`codefresh.yml`
-{% highlight yaml %}
-version: '1.0'
-steps:
- BuildMyImage:
- title: Building My Docker image
- type: build
- image_name: my-app-image
- dockerfile: my-custom.Dockerfile
- tag: 1.0.1
-{% endhighlight %}
-
-Build an image using a different Dockerfile and push multiple tags to the default registry.
-
-`codefresh.yml`
-{% highlight yaml %}
-{% raw %}
-version: '1.0'
-steps:
- BuildMyImage:
- title: Building My Docker image
- type: build
- image_name: my-app-image
- dockerfile: my-custom.Dockerfile
- tags:
- - latest
- - ${{CF_BRANCH_TAG_NORMALIZED_LOWER_CASE}}
- - v1.1
-{% endraw %}
-{% endhighlight %}
-
-Build an image and automatically push to the [registry]({{site.baseurl}}/docs/docker-registries/external-docker-registries/) with name `my-registry`.
-
-`codefresh.yml`
-{% highlight yaml %}
-version: '1.0'
-steps:
- BuildMyImage:
- title: Building My Docker image
- type: build
- image_name: my-app-image
- dockerfile: my-custom.Dockerfile
- tag: 1.0.1
- registry: my-registry
-{% endhighlight %}
-
-Build two images in two different folders using [Codefresh variables]({{site.baseurl}}/docs/codefresh-yaml/variables/) as tags.
-
-`codefresh.yml`
-{% highlight yaml %}
-{% raw %}
-version: '1.0'
-steps:
- BuildNodeImage:
- title: Building My Node app
- type: build
- image_name: my-department/my-team/my-node-image
- dockerfile: Dockerfile
- working_directory: ./project1
- tag: ${{CF_BRANCH_TAG_NORMALIZED}}-${{CF_SHORT_REVISION}}
- BuildGoImage:
- title: Building My Go app
- type: build
- image_name: my-company/my-go-image
- dockerfile: Dockerfile
- working_directory: ./project2
- tag: ${{CF_BRANCH_TAG_NORMALIZED_LOWER_CASE}}
-{% endraw %}
-{% endhighlight %}
-
-It also possible to build Docker images in [parallel]({{site.baseurl}}/docs/codefresh-yaml/advanced-workflows/) for faster builds.
-
-### Inline Dockerfile
-
-If your project does not already have a Dockerfile, you can also define one within the pipeline:
-
-`codefresh.yml`
-{% highlight yaml %}
-{% raw %}
-version: '1.0'
-steps:
- BuildingDockerImage:
- title: Building Docker Image
- type: build
- image_name: my-own-go-app
- working_directory: ./
- tag: '${{CF_BRANCH_TAG_NORMALIZED}}'
- dockerfile:
- content: |-
- # ---
- # Go Builder Image
- FROM golang:1.8-alpine AS builder
- # set build arguments: GitHub user and repository
- ARG GH_USER
- ARG GH_REPO
- # Create and set working directory
- RUN mkdir -p /go/src/github.com/$GH_USER/$GH_REPO
- # copy file from builder image
- COPY --from=builder /go/src/github.com/$GH_USER/$GH_REPO/dist/myapp
- /usr/bin/myapp
- CMD ["myapp", "--help"]
-{% endraw %}
-{% endhighlight %}
-
-Use this technique only as a last resort. It is better if the Dockerfile exists as an actual file in source control.
-
-
-## Automatic pushing
-
-All images built successfully with the build step, will be automatically pushed to the default Docker registry in your account. This behavior is completely automatic and happens without any extra configuration on your part. If you want to disable this then add the `disable_push` property in your build step.
-
->Notice that the [push step]({{site.baseurl}}/docs/codefresh-yaml/steps/push/) in Codefresh is optional and is only needed if you want to push to [external Docker registries]({{site.baseurl}}/docs/docker-registries/external-docker-registries/).
-
-{%
- include image.html
- lightbox="true"
- file="/images/artifacts/cfcr/codefresh-registry-list.png"
- url="/images/artifacts/cfcr/codefresh-registry-list.png"
- alt="Docker Images pushed automatically"
- caption="Docker Images pushed automatically"
- max-width="80%"
-%}
-
-## Buildkit support
-
-Codefresh also allows you to use [buildkit](https://github.com/moby/buildkit) with all its [enhancements](https://docs.docker.com/develop/develop-images/build_enhancements/) and [experimental features](https://github.com/moby/buildkit/blob/master/frontend/dockerfile/docs/experimental.md#experimental-syntaxes).
-
-Using buildkit you can get:
-
-* Improved build output logs
-* Mounting of external secrets that will never be stored in the image
-* Access to SSH keys and sockets from within the Dockerfile
-* Use cache and bind-mounts at build time
-
-These capabilities are offered as extra arguments in the build step and using any of them will automatically enable buildkit. You can utilize the different mount-options for the Dockerfile instruction `RUN` as long as buildkit is enabled for your build step. Mounts of type [`cache`](https://github.com/moby/buildkit/blob/master/frontend/dockerfile/docs/experimental.md#example-cache-go-packages) work out of the box and are persisted between pipeline runs.
-
-The simplest way to use buildkit is by enabling it explicitly:
-
-`codefresh.yml`
-{% highlight yaml %}
-version: '1.0'
-steps:
- BuildMyImage:
- title: Building My Docker image
- image_name: my-app-image
- type: build
- buildkit: true
-{% endhighlight %}
-
-Buildkit is also automatically enabled if you use any of its features such as the `progress` property:
-
-`codefresh.yml`
-{% highlight yaml %}
-version: '1.0'
-steps:
- BuildMyImage:
- title: Building My Docker image
- image_name: my-app-image
- type: build
- progress: tty
-{% endhighlight %}
-
-Possible values for `progress` are `tty` and `plain`.
-
-For secrets you can either mention them in a single line:
-
-`codefresh.yml`
-{% highlight yaml %}
-version: '1.0'
-steps:
- BuildMyImage:
- title: Building My Docker image
- image_name: my-app-image
- type: build
- secrets:
- - id=secret1,src=./my-secret-file1.txt
- - id=secret2,src=./my-secret-file2.txt
-{% endhighlight %}
-
-or multiple lines:
-
-`codefresh.yml`
-{% highlight yaml %}
-version: '1.0'
-steps:
- BuildMyImage:
- title: Building My Docker image
- image_name: my-app-image
- type: build
- secrets:
- - id: secret1
- src: ./my-secret-file1.txt
- - id: secret2
- src: ./my-secret-file2.txt
-{% endhighlight %}
-
-For the SSH connection you can either use the default:
-
-`codefresh.yml`
-{% highlight yaml %}
-version: '1.0'
-steps:
- BuildMyImage:
- title: Building My Docker image
- image_name: my-app-image
- type: build
- ssh: default
-{% endhighlight %}
-
-
-or define different keys:
-
-`codefresh.yml`
-{% highlight yaml %}
-version: '1.0'
-steps:
- BuildMyImage:
- title: Building My Docker image
- image_name: my-app-image
- type: build
- ssh:
- - github=~/.ssh/github_rsa
- - bitbucket=~/.ssh/bitbucket_rsa
-{% endhighlight %}
-
-You might want to use an environment variable to store and retrieve a ssh key. This can be achieved by converting you ssh key into a one-line string:
-```
-tr '\n' ',' < /path/to/id_rsa
-```
-
-Copy the output and place it an [environment variable]({{site.baseurl}}/docs/codefresh-yaml/variables/#user-provided-variables). To make the SSH key availabe to the build step, you can write it to the codefresh volume:
-`codefresh.yml`
-{% highlight yaml %}
-{% raw %}
-version: '1.0'
-steps:
- SetupSshKeys:
- title: Setting up ssh key
- image: alpine:latest
- commands:
- - mkdir /codefresh/volume/keys
- - echo "${SSH_KEY}" | tr ',' '\n' > /codefresh/volume/keys/github_rsa
-
- BuildMyImage:
- title: Building My Docker image
- image_name: my-app-image
- type: build
- tag: latest
- ssh:
- - github=/codefresh/volume/keys/github_rsa
-{% endraw %}
-{% endhighlight %}
-
-
-You can combine all options (`ssh`, `progress`, `secrets`) in a single build step if desired.
-
-
-
-## What to read next
-
-* [Codefresh YAML]({{site.baseurl}}/docs/codefresh-yaml/what-is-the-codefresh-yaml/)
-* [Pipeline Steps]({{site.baseurl}}/docs/codefresh-yaml/steps/)
diff --git a/_docs/codefresh-yaml/steps/git-clone.md b/_docs/codefresh-yaml/steps/git-clone.md
deleted file mode 100644
index 9dbbe7db6..000000000
--- a/_docs/codefresh-yaml/steps/git-clone.md
+++ /dev/null
@@ -1,441 +0,0 @@
----
-title: "Git-Clone"
-description: "Checkout code in your pipelines"
-group: codefresh-yaml
-sub_group: steps
-redirect_from:
- - /docs/git-clone/
-toc: true
----
-Clones a Git repository to the filesystem.
-
-A pipeline can have any number of git clone steps (even none). You can check out code from any private or public repository. Cloning a repository is not constrained to the trigger of a pipeline. You can trigger a pipeline from a commit that happened on Git repository A while the pipeline is checking out code from Git Repository B.
-
->Notice that if you are an existing customer before May 2019, Codefresh will automatically check out the code from a [connected git repository]({{site.baseurl}}/docs/integrations/git-providers/) when a pipeline is created on that repository. In this case an implicit git clone step is included in your pipeline. You can still override it with your own git clone step as explained in this page
-
-## Usage
-
- `YAML`
-{% highlight yaml %}
-step_name:
- type: git-clone
- title: Step Title
- description: Step description
- working_directory: /path
- repo: owner/repo
- depth: 3
- git: my-git-provider
- revision: abcdef12345'
- use_proxy: false
- credentials:
- username: user
- password: credentials
- fail_fast: false
- when:
- branch:
- ignore: [ develop ]
- on_success:
- ...
- on_fail:
- ...
- on_finish:
- ...
- retry:
- ...
-{% endhighlight %}
-
-## Fields
-
-
-{: .table .table-bordered .table-hover}
-| Field | Description | Required/Optional/Default |
-| ------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------- |
-| `title` | The free-text display name of the step. | Optional |
-| `description` | A basic, free-text description of the step. | Optional |
-| `stage` | Parent group of this step. See [using stages]({{site.baseurl}}/docs/codefresh-yaml/stages/) for more information. | Optional |
-| `working_directory` | The directory to which the repository is cloned. It can be an explicit path in the container's file system, or a variable that references another step. The default value is {% raw %}`${{main_clone}}`{% endraw %}, but note that the default will only be used if you name your step `main_clone`. See the example on [working inside the cloned directory]({{site.baseurl}}/docs/yaml-examples/examples/git-checkout/#working-inside-the-cloned-directory) for more information. | Default |
-| `git` | The name of the [git integration]({{site.baseurl}}/docs/integrations/git-providers/) you want to use. If left empty, Codefresh will attempt to use the git provider that was used during account sign-up. Note that this might have unexpected results if you are changing your Git integrations.| Required|
-| `repo` | The path of the repository without the domain name in the form of `my_username/ my_repo`. {::nomarkdown} Note: To clone a GitHub wiki, specify the full URL of the wiki,{:/} for example, `"https://github.com/wikis/examples.wiki"`. | Required |
-| `revision` | The revision of the repository you are checking out. It can be a revision hash or a branch name. The default value is the branch you have specified in your Git provider (e.g `master` or `main`). | Default |
-| `depth` | The number of commits to pull from the repo to create a shallow clone. Creating a shallow clone truncates the history to the number of commits specified, instead of pulling the entire history. | Optional |
-| `use_proxy` | If set to true the Git clone process will honor `HTTP_PROXY` and `HTTPS_PROXY` variables if present for [working via a proxy](#using-git-behind-a-proxy). Default value is `false`. | Default |
-| `credentials` | Credentials to access the repository, if it requires authentication. It can an object containing `username` and `password` fields. Credentials are optional if you are using the [built-in git integrations]({{site.baseurl}}/docs/integrations/git-providers/) . | Optional |
-| `fail_fast` | If a step fails and the process is halted. The default value is `true`. | Default |
-| `when` | Define a set of conditions that need to be satisfied in order to execute this step. You can find more information in the [Conditional Execution of Steps]({{site.baseurl}}/docs/codefresh-yaml/conditional-execution-of-steps/) article. | Optional |
-| `on_success`, `on_fail` and `on_finish` | Define operations to perform upon step completion using a set of predefined [Post-Step Operations]({{site.baseurl}}/docs/codefresh-yaml/post-step-operations/). | Optional |
-| `retry` | Define retry behavior as described in [Retrying a step]({{site.baseurl}}/docs/codefresh-yaml/what-is-the-codefresh-yaml/#retrying-a-step). | Optional |
-
-**Exported resources:**
-- Working Directory
-
-{{site.data.callout.callout_info}}
-If you want to extend the git-clone step you can use the freestyle step. Example how to do it you can find [here]({{site.baseurl}}/docs/yaml-examples/examples/git-clone-private-repository-using-freestyle-step/)
-{{site.data.callout.end}}
-
-## Basic clone step (project-based pipeline)
-
-The easiest way to use a git clone step is to use your default git provider as configured in [built-in git integrations]({{site.baseurl}}/docs/integrations/git-providers/).
-
-Here is an example of a pipeline that will automatically check out the repository that triggered it (i.e. a commit happened on that repository).
-
->Notice that the name of the clone step is `main_clone`. This will automatically set the working directory of all other steps that follow it **inside** the folder of the project that was checked out. This only applies to [built-in]({{site.baseurl}}/docs/codefresh-yaml/steps/#built-in-steps) Codefresh steps and not [custom plugins]({{site.baseurl}}/docs/codefresh-yaml/steps/#creating-a-typed-codefresh-plugin). This is normally what you want for a pipeline that only checks out a single project. If you use any other name apart from `main_clone` the working directory for all subsequent steps will not be affected and it will default on the [shared volume]({{site.baseurl}}/docs/configure-ci-cd-pipeline/introduction-to-codefresh-pipelines/#sharing-the-workspace-between-build-steps) which is the [parent folder]({{site.baseurl}}/docs/configure-ci-cd-pipeline/introduction-to-codefresh-pipelines/#cloning-the-source-code) of checkouts.
-
-
-
-`codefresh.yml`
-{% highlight yaml %}
-{% raw %}
-version: '1.0'
-steps:
- main_clone:
- title: 'Cloning main repository...'
- type: git-clone
- repo: '${{CF_REPO_OWNER}}/${{CF_REPO_NAME}}'
- revision: '${{CF_REVISION}}'
- git: my-git-provider
- PrintFileList:
- title: 'Listing files'
- image: alpine:latest
- commands:
- - 'ls -l'
-{% endraw %}
-{% endhighlight %}
-
-The CF values will be automatically filled by Codefresh from the git trigger. See the [variables page]({{site.baseurl}}/docs/codefresh-yaml/variables/) for more details.
-
-## Choosing a specific git provider (project-based pipeline)
-
-If you don't want to use the default git provider you can explicitly set the provider by using the same name of the integration as it is shown in [the git integrations page]({{site.baseurl}}/docs/integrations/git-providers/).
-
-{% include
-image.html
-lightbox="true"
-file="/images/codefresh-yaml/steps/example-git-providers.png"
-url="/images/codefresh-yaml/steps/example-git-providers.png"
-alt="Example git integrations"
-caption="Example git integrations"
-max-width="40%"
-%}
-
-Here is an example for an integration with the GitLab provider already connected:
-
-`codefresh.yml`
-{% highlight yaml %}
-{% raw %}
-version: '1.0'
-steps:
- main_clone:
- title: 'Cloning main repository...'
- type: git-clone
- repo: '${{CF_REPO_OWNER}}/${{CF_REPO_NAME}}'
- revision: '${{CF_REVISION}}'
- git: my-gitlab
- PrintFileList:
- title: 'Listing files'
- image: alpine:latest
- commands:
- - 'ls -l'
-{% endraw %}
-{% endhighlight %}
-
-## Checkout a specific repository/revision (project based pipeline)
-
-If you want to check out a specific git repository regardless of what repository actually created the trigger
-you can just define all values in a non-static manner. For example, if you want your pipeline to always checkout git repository `foo` even when the trigger happened from repository `bar` you can define the checkout step as below:
-
-`codefresh.yml`
-{% highlight yaml %}
-{% raw %}
-version: '1.0'
-steps:
- main_clone:
- title: 'Cloning main repository...'
- type: git-clone
- repo: 'my-github-username/foo'
- revision: '${{CF_REVISION}}'
- git: my-github-integration
- PrintFileList:
- title: 'Listing files'
- image: alpine:latest
- commands:
- - 'ls -l'
-{% endraw %}
-{% endhighlight %}
-
-In a similar manner you can also define that the pipeline will always checkout master, regardless of the commit that actually triggered it.
-
-`codefresh.yml`
-{% highlight yaml %}
-{% raw %}
-version: '1.0'
-steps:
- main_clone:
- title: 'Cloning main repository...'
- type: git-clone
- repo: '${{CF_REPO_OWNER}}/${{CF_REPO_NAME}}'
- revision: 'master'
- git: my-git-provider
- PrintFileList:
- title: 'Listing files'
- image: alpine:latest
- commands:
- - 'ls -l'
-{% endraw %}
-{% endhighlight %}
-
-## Checkout code using the Codefresh Runner
-
-If you are using the [Hybrid version]({{site.baseurl}}/docs/enterprise/installation-security/#hybrid-installation) of Codefresh and a have a [Codefresh runner]({{site.baseurl}}/docs/enterprise/codefresh-runner/) installed, you need to use
-the fully qualified path of the git repository:
-
-`codefresh.yml`
-{% highlight yaml %}
-{% raw %}
-version: '1.0'
-steps:
- main_clone:
- title: 'Cloning main repository...'
- type: git-clone
- repo: https://github-internal.example.com/my-username/my-app
- revision: '${{CF_REVISION}}'
- git: my-internal-git-provider
- PrintFileList:
- title: 'Listing files'
- image: alpine:latest
- commands:
- - 'ls -l'
-{% endraw %}
-{% endhighlight %}
-
-More details can be found in the [private Git instructions page]({{site.baseurl}}/docs/enterprise/behind-the-firewall/#checking-out-code-from-a-private-git-repository).
-
-
-## Checking multiple git repositories
-
-It is very easy to checkout additional repositories in a single pipeline by adding more `git-clone` steps.
-In that case you should use different names for the steps (instead of `main_clone`) as this will make the working
-folder for all steps the [shared volume]({{site.baseurl}}/docs/configure-ci-cd-pipeline/introduction-to-codefresh-pipelines/#sharing-the-workspace-between-build-steps).
-
-`codefresh.yml`
-{% highlight yaml %}
-{% raw %}
-version: '1.0'
-steps:
- my_first_checkout:
- title: 'Cloning first repository...'
- type: git-clone
- repo: 'my-gitlab-username/foo'
- revision: '${{CF_REVISION}}'
- git: my-gitlab-integration
- my_second_checkout:
- title: 'Cloning second repository...'
- type: git-clone
- repo: 'my-github-username/bar'
- revision: '${{CF_REVISION}}'
- git: my-github-integration
- PrintFileList:
- title: 'Listing files'
- image: alpine:latest
- commands:
- - 'ls -l'
-{% endraw %}
-{% endhighlight %}
-
-
-## Skip or customize default clone (repository-based pipeline)
-
-If you have existing pipelines connected to repositories (only for Codefresh accounts created before May 2019)
-a git clone step is transparently added to git attached pipelines without you having to explicitly add a step into the pipeline. This is a convenience to enable easy CI pipelines.
-If you do not require git cloning, or you would like to customize the implicit git cloning behavior, you can choose to skip the automatically added git clone step.
-
-There are 2 ways to do that:
-
-1. Add a pipeline environment variable called `CF_SKIP_MAIN_CLONE` with value of `true`.
-
--or-
-
-2. Add a step with key `main_clone` to your pipeline. This step can be of any type and can do any action. This step will override the default clone implementation. for example:
-
-```yaml
-version: '1.0'
-steps:
- main_clone:
- title: Checking out code
- image: alpine/git:latest
- commands:
- - git clone ...
- another_step:
- ...
-```
-
-## Reuse a Git token from Codefresh integrations
-
-You also have the capability to use one of your existing [git integrations]({{site.baseurl}}/docs/integrations/git-providers/)
-as an authentication mechanism.
-
-The [Codefresh CLI](https://codefresh-io.github.io/cli/) can read one of the connected [git authentication contexts](https://codefresh-io.github.io/cli/contexts/get-context/) and use that token for a custom clone step.
-
-Here is an example for GitHub
-
-
-```yaml
-version: '1.0'
-steps:
- get_git_token:
- title: Reading GitHub token
- image: codefresh/cli
- commands:
- - cf_export GITHUB_TOKEN=$(codefresh get context github --decrypt -o yaml | yq -r .spec.data.auth.password)
- main_clone:
- title: Checking out code
- image: alpine/git:latest
- commands:
- - git clone https://my-github-username:$GITHUB_TOKEN@github.com/my-github-username/my-repo.git
- another_step:
- ...
-```
-
-## Working with GIT submodules
-
-To checkout a git project including its submodules you can use the [Codefresh submodule plugin](https://github.com/codefresh-io/plugins/tree/master/plugins/gitsubmodules). This plugin is already offered as a public docker image at [Dockerhub](https://hub.docker.com/r/codefresh/cfstep-gitsubmodules/tags).
-
-To use this module in your pipeline, add a new step like the one shown below.
-
-```yaml
-version: '1.0'
-steps:
- updateSubmodules:
- image: codefresh/cfstep-gitsubmodules
- environment:
- - GITHUB_TOKEN=
- - CF_SUBMODULE_SYNC=
- - CF_SUBMODULE_UPDATE_RECURSIVE=
-```
-
-The GitHub token can be either defined in the pipeline on its own as an environment variable, or fetched from
-the existing [GIT integration]({{site.baseurl}}/docs/integrations/git-providers/) as shown in the previous section.
-
-Here is full pipeline example:
-
- `codefresh.yml`
-{% highlight yaml %}
-{% raw %}
-version: '1.0'
-stages:
- - checkout
- - prepare
- - build
-steps:
- clone:
- title: Cloning the repository
- type: git-clone
- stage: checkout
- arguments:
- repo: '${{CF_REPO_OWNER}}/${{CF_REPO_NAME}}'
- git: github
- revision: '${{CF_REVISION}}'
-
- updateSubmodules:
- image: codefresh/cfstep-gitsubmodules
- stage: prepare
- working_directory: '${{clone}}'
- environment:
- - GITHUB_TOKEN=${{MY_GITHUB_TOKEN}}
- docker_build:
- title: Building docker image
- type: build
- stage: build
- working_directory: '${{clone}}/k8s/docker'
- tag: current
- disable_push: true
- image_name: 'my-docker-image'
-
-{% endraw %}
-{% endhighlight %}
-
-This pipeline does the following:
-
-1. Clones the main source code
-1. Updates submodules
-1. Creates a docker image
-
-
-## Use an SSH key with Git
-
-It is also possible to use an SSH key with git. When [creating your pipeline]({{site.baseurl}}/docs/configure-ci-cd-pipeline/pipelines/) add your SSH key as an encrypted
-environment variable after processing it with `tr`:
-
-```
-cat ~/.ssh/my_ssh_key_file | tr '\n' ','
-```
-
-
-Then in the pipeline use it like this:
-
-`codefresh.yml`
-{% highlight yaml %}
-{% raw %}
-version: '1.0'
-steps:
- main_clone:
- title: Checking out code
- image: alpine/git:latest
- commands:
- - mkdir -p ~/.ssh
- - echo "${SSH_KEY}" | tr \'"${SPLIT_CHAR}"\' '\n' > ~/.ssh/id_rsa
- - chmod 600 ~/.ssh/id_rsa
- - git clone git@github.com:my-github-username/my-repo.git
- # can also use go get or other similar command that uses git internally
- another_step:
- ...
-{% endraw %}
-{% endhighlight %}
-
-## Using Git behind a proxy
-
-If you use the [Codefresh Runner]({{site.baseurl}}/docs/administration/codefresh-runner/) and need to use a network proxy in your clone step you need to set the [variables]({{site.baseurl}}/docs/codefresh-yaml/variables/) `HTTP_PROXY` and/or `HTTPS_PROXY` in the pipeline
-and then activate the property `use_proxy: true` in the clone step. Example:
-
-`codefresh.yml`
-{% highlight yaml %}
-{% raw %}
-version: "1.0"
-steps:
- clone:
- title: "Cloning repository"
- type: "git-clone"
- repo: "https://github.com/my-github-user/my-repo/"
- revision: "master"
- use_proxy: true
- git: my-git-provider
-{% endraw %}
-{% endhighlight %}
-
-For setting the values of the proxy variables you can use any of the supported methods for defining variables such as [shared configuration]({{site.baseurl}}/docs/configure-ci-cd-pipeline/shared-configuration/).
-
-
-{% include
-image.html
-lightbox="true"
-file="/images/codefresh-yaml/steps/proxy-variables.png"
-url="/images/codefresh-yaml/steps/proxy-variables.png"
-alt="Pipeline variable"
-caption="Pipeline variable"
-max-width="40%"
-%}
-
-For more details see the [behind the firewall page]({{site.baseurl}}/docs/administration/behind-the-firewall/).
-
-
-## What to read next
-
-- [Creating pipelines]({{site.baseurl}}/docs/configure-ci-cd-pipeline/pipelines/)
-- [Git integrations]({{site.baseurl}}/docs/integrations/git-providers/)
-- [YAML steps]({{site.baseurl}}/docs/codefresh-yaml/steps/)
-- [Git Checkout Examples]({{site.baseurl}}/docs/yaml-examples/examples/git-checkout/)
-- [Custom Git Commands]({{site.baseurl}}/docs/yaml-examples/examples/git-checkout-custom/)
-
-
-
-
-
diff --git a/_docs/codefresh-yaml/steps/launch-composition.md b/_docs/codefresh-yaml/steps/launch-composition.md
deleted file mode 100644
index e2bd5d486..000000000
--- a/_docs/codefresh-yaml/steps/launch-composition.md
+++ /dev/null
@@ -1,93 +0,0 @@
----
-title: "Launch-Composition"
-description: "Create a test environment with its dependencies in Codefresh infrastructure"
-group: codefresh-yaml
-sub_group: steps
-redirect_from:
- - /docs/launch-composition-2/
- - /docs/codefresh-yaml/steps/launch-composition-2/
-toc: true
----
-The launch composition step provides the ability to launch long term running environments that can live outside the context of a running pipeline.
-You can use this step to automate your test environment creation through a codefresh.yml file instead of manually launching an environment from the UI.
-
->Note that "launch-composition" creates a permanent test environment that keeps running even after a pipeline has finished. If you just want temporary test environments that run *only while* a pipeline is running, see [service containers]({{site.baseurl}}/docs/codefresh-yaml/service-containers/) and the documentation page for [integration tests]({{site.baseurl}}/docs/testing/integration-tests/).
-
-## Usage
-
- `ui defined composition`
-{% highlight yaml %}
-step_name:
- title: Step Title
- type: launch-composition
- composition: 'ui_defined_composition_name'
- environment_name: 'environment name'
- on_success:
- ...
- on_fail:
- ...
- on_finish:
- ...
-{% endhighlight %}
-
- `inline composition`
-{% highlight yaml %}
-step_name:
- type: launch-composition
- composition:
- version: '2'
- services:
- app:
- image: owner/app:latest
- db:
- image: mongo
- environment_name: 'environment name'
- on_success:
- ...
- on_fail:
- ...
- on_finish:
- ...
- retry:
- ...
-{% endhighlight %}
-
- `from file composition`
-{% highlight yaml %}
-step_name:
- type: launch-composition
- working_directory: ${{a_clone_step}}
- composition: './path/to/docker-compose.yaml'
- environment_name: 'environment name'
- on_success:
- ...
- on_fail:
- ...
- on_finish:
- ...
-{% endhighlight %}
-
-## Fields
-
-{: .table .table-bordered .table-hover}
-| Field | Description | Required/Optional/Default |
-| ------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------- |
-| `title` | The free-text display name of the step. | Optional |
-| `description` | A basic, free-text description of the step. | Optional |
-| `stage` | Parent group of this step. See [using stages]({{site.baseurl}}/docs/codefresh-yaml/stages/) for more information. | Optional |
-| `working_directory` | The directory in which to search for the composition file. It can be an explicit path in the container's file system, or a variable that references another step. The default is {% raw %}`${{main_clone}}`{% endraw %}. | Default |
-| `composition` | The composition you want to run. It can be an inline YAML definition, a path to a composition file on the file system, or the logical name of a composition stored in the Codefresh system. | Required |
-| `environment_name` | The environment name that will be given. In case a previous environment exists with the same name, it will first be terminated. The default value will the be the name/path provided in the 'composition' field. | Default |
-| `composition_variables` | A set of environment variables to substitute in the composition. | Optional |
-| `fail_fast` | If a step fails, and the process is halted. The default value is `true`. | Default |
-| `when` | Define a set of conditions which need to be satisfied in order to execute this step. You can find more information in the [[Conditional Execution of Steps]({{ site.baseurl }}/docs/codefresh-yaml/conditional-execution-of-steps/) article. | Optional |
-| `on_success`, `on_fail` and `on_finish` | Define operations to perform upon step completion using a set of predefined [Post-Step Operations]({{ site.baseurl }}/docs/codefresh-yaml/post-step-operations/). | Optional |
-| entry_point | The name of main service | Optional |
-| `retry` | Define retry behavior as described in [Retrying a step]({{site.baseurl}}/docs/codefresh-yaml/what-is-the-codefresh-yaml/#retrying-a-step). | Optional |
-
-## What to read next
-
-* [Preview environments]({{site.baseurl}}/docs/getting-started/on-demand-environments/)
-* [Launch Composition example]({{site.baseurl}}/docs/yaml-examples/examples/launch-composition/)
-* [Integration tests]({{site.baseurl}}/docs/testing/integration-tests/)
-* [Service Containers]({{site.baseurl}}/docs/codefresh-yaml/service-containers/)
\ No newline at end of file
diff --git a/_docs/codefresh-yaml/steps/push.md b/_docs/codefresh-yaml/steps/push.md
deleted file mode 100644
index 2f5356eab..000000000
--- a/_docs/codefresh-yaml/steps/push.md
+++ /dev/null
@@ -1,257 +0,0 @@
----
-title: "Push step"
-description: "Pushing Docker images from your pipeline"
-group: codefresh-yaml
-sub_group: steps
-redirect_from:
- - /docs/push-1/
- - /docs/codefresh-yaml/steps/push-1/
-toc: true
----
-
-{{site.data.callout.callout_info}}
-
-If you use only the default Docker registry of your account this step is optional as all successful Codefresh pipelines automatically push the Docker image they create in the default Docker registry. No further configuration is needed to achieve this behavior.
-{{site.data.callout.end}}
-
-Push a built image to a remote Docker registry with one or more tags. Supports standard Docker registries and ECR.
-
-Notice that when you use [any external registry]({{site.baseurl}}/docs/docker-registries/external-docker-registries/), you need to comply to the naming pattern used by that registry, otherwise the build step will fail. For example, if your Codefresh image is tagged as `foo_username/my_image` but your Dockerhub account is `bar_username` then the build will fail and you need to customize the push step to use `bar_username` instead. This is a limitation of external registries such as Dockerhub.
-
-## Usage
-
- `YAML`
-{% highlight yaml %}
-step_name:
- type: push
- title: Step Title
- description: Free text description
- candidate: {% raw %}${{build_step_name}}{% endraw %}
- tag: latest
- image_name: codefresh/app
- registry: my-registry
- fail_fast: false
- when:
- branch:
- only:
- - /FB-/i
- on_success:
- ...
- on_fail:
- ...
- on_finish:
- ...
- retry:
- ...
-
-{% endhighlight %}
-
-## Fields
-
-{: .table .table-bordered .table-hover}
-| Field | Description | Required/Optional/Default |
-| ------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------- |
-| `title` | The free-text display name of the step. | Optional |
-| `description` | A basic, free-text description of the step. | Optional |
-| `stage` | Parent group of this step. See [using stages]({{site.baseurl}}/docs/codefresh-yaml/stages/) for more information. | Optional |
-| `candidate` | The identifier of the image to push to the remote Docker registry. It can be an explicit identifier of an image to push, or a variable that references a `Build` step. | Required |
-| `tag` | The tag under which to push the image. Use either this or `tags`. The default is `latest`. | Default |
-| `region` | Relevant only for [Amazon ECR]({{site.baseurl}}/docs/integrations/docker-registries/amazon-ec2-container-registry/) integrations using either service accounts or explicit credentials. The names of the regions for which to perform cross-region replication. The names of the source region and the destination region name must be defined in separate steps. | Optional |
-| `role_arn` | Relevant only for [Amazon ECR]({{site.baseurl}}/docs/integrations/docker-registries/amazon-ec2-container-registry/) integrations using either service accounts or explicit credentials. The role with the required permissions to use to pull the image. For example, `arn:aws:iam:::role/` | Required |
-| `aws_session_name` | Relevant only for [Amazon ECR]({{site.baseurl}}/docs/integrations/docker-registries/amazon-ec2-container-registry/) integrations using either service accounts or explicit credentials. The name of the AWS session. If not defined, `default-session-name` is used. | Default |
-| `aws_duration_seconds` | Relevant only for [Amazon ECR]({{site.baseurl}}/docs/integrations/docker-registries/amazon-ec2-container-registry/) integrations using either service accounts or explicit credentials. The length of time, in seconds, for which the role credentials are considered valid, and must be between `900-3600` seconds. If not defined, the duration is set to the default of `3600` seconds. | Default |
-| `tags` | Multiple tags under which to push the image. Use either this or `tag`. This is an array, so should be of the following style: {::nomarkdown}
tags: -tag1 -tag2 -{% raw %}${{CF_BRANCH_TAG_NORMALIZED_LOWER_CASE}}{% endraw %} -tag4
{:/}or {::nomarkdown}
tags:['tag1','tag2','{% raw %}${{CF_BRANCH_TAG_NORMALIZED_LOWER_CASE}}{% endraw %}','tag4']
{:/} | Default |
-| `image_name` | The tagged image name that will be used The default value will be the same image name as of the candidate. | Default |
-| `registry` | The registry logical name of one of the inserted registries from the integration view. The default value will be your default registry [if you have more than one]({{site.baseurl}}/docs/docker-registries/external-docker-registries/). | Default |
-| `registry_context` | Advanced property for resolving Docker images when [working with multiple registries with the same domain]({{site.baseurl}}/docs/docker-registries/working-with-docker-registries/#working-with-multiple-registries-with-the-same-domain) | Optional |
-| `fail_fast` | If a step fails, and the process is halted. The default value is `true`. | Default |
-| `when` | Define a set of conditions which need to be satisfied in order to execute this step. You can find more information in the [Conditional Execution of Steps]({{site.baseurl}}/docs/codefresh-yaml/conditional-execution-of-steps/) article. | Optional |
-| `on_success`, `on_fail` and `on_finish` | Define operations to perform upon step completion using a set of predefined [Post-Step Operations]({{site.baseurl}}/docs/codefresh-yaml/post-step-operations/). | Optional |
-| `retry` | Define retry behavior as described in [Retrying a step]({{site.baseurl}}/docs/codefresh-yaml/what-is-the-codefresh-yaml/#retrying-a-step). | Optional |
-
-## Examples
-
-Push an image to a registry connected with the [integration name]({{site.baseurl}}/docs/docker-registries/external-docker-registries/) of `myazureregistry`.
-
-`codefresh.yml`
-{% highlight yaml %}
-{% raw %}
-version: '1.0'
-stages:
-- 'my build phase'
-- 'my push phase'
-steps:
- MyAppDockerImage:
- title: Building Docker Image
- stage: 'my build phase'
- type: build
- image_name: my-app-image
- dockerfile: Dockerfile
- pushToMyRegistry:
- stage: 'my push phase'
- type: push
- title: Pushing to a registry
- candidate: ${{MyAppDockerImage}}
- tag: ${{CF_SHORT_REVISION}}
- registry: myazureregistry
-{% endraw %}
-{% endhighlight %}
-
-Push an image as the name of the branch in the [external registry]({{site.baseurl}}/docs/docker-registries/external-docker-registries/) and also use a different image than the default. The same image will also by pushed as `latest` in the internal Codefresh registry (with the default name of `my-app-image`).
-
-`codefresh.yml`
-{% highlight yaml %}
-{% raw %}
-version: '1.0'
-stages:
-- 'my build phase'
-- 'my push phase'
-steps:
- MyAppDockerImage:
- title: Building Docker Image
- stage: 'my build phase'
- type: build
- image_name: my-app-image
- dockerfile: Dockerfile
- tag: latest
- pushToMyRegistry:
- stage: 'my push phase'
- type: push
- title: Pushing to a registry
- candidate: ${{MyAppDockerImage}}
- tag: ${{CF_BRANCH_TAG_NORMALIZED_LOWER_CASE}}
- registry: myazureregistry
- image_name: my-user-name/a-different-image-name
-{% endraw %}
-{% endhighlight %}
-
-
-Push an image with multiple tags.
-
-`codefresh.yml`
-{% highlight yaml %}
-{% raw %}
-version: '1.0'
-stages:
-- 'my build phase'
-- 'my push phase'
-steps:
- MyAppDockerImage:
- title: Building Docker Image
- stage: 'my build phase'
- type: build
- image_name: my-app-image
- dockerfile: Dockerfile
- pushToMyRegistry:
- stage: 'my push phase'
- type: push
- title: Pushing to a registry
- candidate: ${{MyAppDockerImage}}
- tags:
- - ${{CF_SHORT_REVISION}}
- - latest
- - 2.0.0
- registry: myazureregistry
-{% endraw %}
-{% endhighlight %}
-
-Push an image with multiple tags to multiple Docker registries in [parallel]({{site.baseurl}}/docs/codefresh-yaml/advanced-workflows/).
-Both registries are connected first in the [integrations page]({{site.baseurl}}/docs/docker-registries/external-docker-registries/).
-
-
-`codefresh.yml`
-{% highlight yaml %}
-{% raw %}
-version: '1.0'
-stages:
-- 'my build phase'
-- 'my push phase'
-steps:
- MyAppDockerImage:
- title: Building Docker Image
- stage: 'my build phase'
- type: build
- image_name: my-app-image
- dockerfile: Dockerfile
- PushingToRegistries:
- type: parallel
- stage: 'push'
- steps:
- PushingToGoogleRegistry:
- type: push
- title: Pushing To Google Registry
- candidate: ${{MyAppDockerImage}}
- tags:
- - ${{CF_BUILD_ID}}
- - latest
- - production
- registry: gcr
- PushingToDockerRegistry:
- type: push
- title: Pushing To Dockerhub Registry
- candidate: ${{MyAppDockerImage}}
- tag: '${{CF_SHORT_REVISION}}'
- image_name: my-docker-hub-username/my-app-name
- registry: dockerhub
-{% endraw %}
-{% endhighlight %}
-
-
-## Using passed credentials without pre-saving them
-
-This option enables you to push your images without pre-saving the credentials in Codefresh's registry integration view.
-
->Note that this method of pushing images is offered as a workaround. The suggested way is to use the [central Codefresh integration for registries]({{site.baseurl}}/docs/docker-registries/external-docker-registries/) as explained in the previous section.
-
- `YAML`
-{% highlight yaml %}
-step_name:
- type: push
- title: Step Title
- description: Free text description
- candidate: {% raw %}${{build_step_name}}{% endraw %}
- tags: [ latest, {% raw %}${{CF_BRANCH}}{% endraw %} ]
- image_name: codefresh/app
- registry: dtr.host.com
- credentials:
- username: subject
- password: credentials
- fail_fast: false
- when:
- branch:
- only:
- - /FB-/i
- on_success:
- ...
- on_fail:
- ...
- on_finish:
- ...
-{% endhighlight %}
-
-{: .table .table-bordered .table-hover}
-| Field | Description | Required/Optional/Default |
-| ------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------- |
-| `title` | The free-text display name of the step. | Optional |
-| `description` | A basic, free-text description of the step. | Optional |
-| `provider` | The type of Docker registry provider. Can currently be either `docker` for a standard Docker registry, or `ecr` for the [Amazon EC2 Container Registry (ECR)](https://aws.amazon.com/ecr/). | Optional *Default value*: `docker` |
-| `candidate` | The identifier of the image to push to the remote Docker registry. It can be an explicit identifier of an image to push, or a variable that references a `Build` step. | Required |
-| `tag` | The tag under which to push the image. Use either this or `tags`. The default is `latest`. | Default |
-| `tags` | Multiple tags under which to push the image. Use either this or 'tag'. This is an array, so should be of the following style: {::nomarkdown}
tags: -tag1 -tag2 -{% raw %}${{CF_BRANCH_TAG_NORMALIZED}}{% endraw %} -tag4
{:/}or {::nomarkdown}
tags:['tag1','tag2','{% raw %}${{CF_BRANCH_TAG_NORMALIZED}}{% endraw %}','tag4']
{:/} | Default |
-| `image_name` | The tagged image name that will be used. The default value will be the same image name as of the candidate. | Default |
-| `registry` | The host address where the registry is located. The default is the registry configured in your Codefresh account, or Dockerhub. | Default **Ignored when provider is** `ecr` |
-| `credentials` | Credentials to access the registry if it requires authentication. It can be a has object containing `username` and `password` fields. The default is the credentials configured in your Codefresh account. | Optional **Ignored when provider is** `ecr` |
-| `accessKeyId` | Your AWS access key. | Optional **Ignored when provider is** `docker` |
-| `secretAccessKey` | Your AWS secret access key. | Optional **Ignored when provider is** `docker` |
-| `region` | The region where the ECR registry is accessible. | Optional **Ignored when provider is** `docker` |
-| `fail_fast` | If a step fails, and the process is halted. The default value is `true`. | Default |
-| `when` | Define a set of conditions which need to be satisfied in order to execute this step. You can find more information in the [Conditional Execution of Steps]({{site.baseurl}}/docs/codefresh-yaml/conditional-execution-of-steps/) article. | Optional |
-| `on_success`, `on_fail` and `on_finish` | Define operations to perform upon step completion using a set of predefined [Post-Step Operations]({{site.baseurl}}/docs/codefresh-yaml/post-step-operations/). | Optional |
-
-**Exported resources:**
-- Image ID.
-
-## What to read next
-- [External Registry integrations]({{site.baseurl}}/docs/docker-registries/external-docker-registries/)
-- [Custom Image annotations]({{site.baseurl}}/docs/docker-registries/metadata-annotations/)
-- [Pipeline steps]({{site.baseurl}}/docs/codefresh-yaml/steps/)
\ No newline at end of file
diff --git a/_docs/codefresh-yaml/variables.md b/_docs/codefresh-yaml/variables.md
deleted file mode 100644
index 5da55e75a..000000000
--- a/_docs/codefresh-yaml/variables.md
+++ /dev/null
@@ -1,340 +0,0 @@
----
-title: "Variables"
-description: ""
-group: codefresh-yaml
-redirect_from:
- - /docs/variables/
-toc: true
----
-Codefresh provides a set of predefined variables automatically in each build, that you can use to parameterize the way your pipeline works. You can also define your own variables. Some common examples of predefined variables include:
-
-* `CF_BRANCH` is the Git branch that was used for this pipeline.
-* `CF_REVISION` is the Git hash that was used for this pipeline.
-* `CF_BUILD_URL` is the url of the pipeline build.
-
-## Using Codefresh variables in your pipelines
-
-There are two ways to use a Codefresh variable in your pipelines:
-
-1. By default all variables will be exposed as UNIX environment variables in all freestyle steps as `$MY_VARIABLE_EXAMPLE`.
-1. Variables can be used in YAML properties with the syntax {% raw %}`${{MY_VARIABLE_EXAMPLE}}`{% endraw %}.
-
-> If you are unsure about which form you need to use, feel free to use {% raw %}`${{MY_VARIABLE_EXAMPLE}}`{% endraw %} everywhere. This is the Codefresh specific form and should function in all sections of `codefresh.yml`.
-
-For example, you can print out the branch as an environment variable like this:
-
-`YAML`
-{% highlight yaml %}
-{% raw %}
-MyOwnStep:
- title: Variable example
- image: alpine
- commands:
- - echo $CF_BUILD_ID
- - echo $CF_BRANCH_TAG_NORMALIZED
-{% endraw %}
-{% endhighlight %}
-
-In the example above we are using simple `echo` commands, but any program or script that reads environment variables could also read them in the same manner.
-
-Using variables directly in yaml properties can be done like this:
-
-`YAML`
-{% highlight yaml %}
-{% raw %}
-MyAppDockerImage:
- title: Building Docker Image
- type: build
- image_name: my-own-app
- tag: ${{CF_BRANCH_TAG_NORMALIZED}}
-{% endraw %}
-{% endhighlight %}
-
-You can also concatenate variables:
-
-`YAML`
-{% highlight yaml %}
-{% raw %}
-MyAppDockerImage:
- title: Building Docker Image
- type: build
- image_name: my-own-app
- tag: ${{CF_BRANCH_TAG_NORMALIZED}}-${{CF_SHORT_REVISION}}
-{% endraw %}
-{% endhighlight %}
-
-This will create docker images with tags such as:
-
-```
-master-df6a04c
-develop-ba1cd68
-feature-vb145dh
-```
-
-
-
-
-Notice that this syntax is specific to Codefresh and is **only** available within the Codefresh YAML file itself. If you want to write scripts or programs that use the Codefresh variables, you need to make them aware of the environment variable form.
-.
-
-## System Provided Variables
-
-All system provided variables will also be automatically injected to any freestyle step as environment variables.
-
-> It is important to understand that all Git related variables such `CF_BRANCH`, `CF_COMMIT_MESSAGE`, `CF_REVISION` etc. are coming directly from the Git provider you use and have the same limitations of that provider. For example GitLab is sending less information in pull request events than normal pushes, and Bitbucket sends only the short hash of a commit in pull request events. We suggest you read the documentation of your Git provider first to understand what information is available for every Git event
-
-{: .table .table-bordered .table-hover}
-| Variable | Description |
-| ------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| {% raw %}`${{CF_REPO_OWNER}} `{% endraw %} | Repository owner. |
-| {% raw %}`${{CF_REPO_NAME}}`{% endraw %} | Repository name. |
-| {% raw %}`${{CF_BRANCH}}`{% endraw %} | Branch name (or Tag depending on the payload json) of the Git repository of the main pipeline, at the time of execution. You can also use {% raw %}`${{CF_BRANCH_TAG_NORMALIZED}}`{% endraw %} to get the branch name normalized. It will be without any chars that are illegal in case the branch name were to be used as the Docker image tag name. You can also use {% raw %}`${{CF_BRANCH_TAG_NORMALIZED_LOWER_CASE}}`{% endraw %} to force lowercase. |
-| {% raw %}`${{CF_BASE_BRANCH}}`{% endraw %} | The base branch used during creation of Tag |
-| {% raw %}`${{CF_PULL_REQUEST_ACTION}}`{% endraw %} | The pull request action. Values are those defined by your Git provider such as [GitHub](https://developer.github.com/webhooks/), [GitLab](https://docs.gitlab.com/ee/user/project/integrations/webhooks.html), [Bitbucket](https://confluence.atlassian.com/bitbucket/manage-webhooks-735643732.html) etc. |
-| {% raw %}`${{CF_PULL_REQUEST_TARGET}}`{% endraw %} | The pull request target branch |
-| {% raw %}`${{CF_PULL_REQUEST_NUMBER}}`{% endraw %} | The pull request number |
-| {% raw %}`${{CF_PULL_REQUEST_ID}}`{% endraw %} | The pull request id |
-| {% raw %}`${{CF_PULL_REQUEST_LABELS}}`{% endraw %} | The labels of pull request (GitHub and GitLab only) |
-| {% raw %}`${{CF_COMMIT_AUTHOR}}`{% endraw %} | Commit author. |
-| {% raw %}`${{CF_BUILD_INITIATOR}}`{% endraw %} | The person (username) that started the build. If the build was started by a Git webhook (e.g. from a Pull request) it will hold the webhook user. Notice that if a build is restarted manually it will always hold the username of the person that restarted it. |
-| {% raw %}`${{CF_ACCOUNT}}`{% endraw %} | Codefresh account for this build |
-| {% raw %}`${{CF_COMMIT_URL}}`{% endraw %} | Commit url. |
-| {% raw %}`${{CF_COMMIT_MESSAGE}}`{% endraw %} | Commit message of the Git repository revision, at the time of execution. The messages quotes are escaped (i.e. ' is not \', " is now \"). |
-| {% raw %}`${{CF_COMMIT_MESSAGE_ESCAPED}}`{% endraw %} | Commit message of the Git repository revision, at the time of execution. Special characters are escaped. |
-| {% raw %}`${{CF_REVISION}}`{% endraw %} | Revision of the Git repository of the main pipeline, at the time of execution. You can also use {% raw %}`${{CF_SHORT_REVISION}}`{% endraw %} to get the abbreviated 7-character revision hash, as used in Git. Note: use this variable as string with quotes to tag the image {% raw %}`${{CF_SHORT_REVISION}}`{% endraw %} |
-| {% raw %}`${{CF_VOLUME_NAME}}`{% endraw %} | Refers to the [shared volume]({{site.baseurl}}/docs/configure-ci-cd-pipeline/introduction-to-codefresh-pipelines/#sharing-the-workspace-between-build-steps) between [freestyle steps]({{site.baseurl}}/docs/codefresh-yaml/steps/freestyle/). Normally you only need to define this in [compositions]({{site.baseurl}}/docs/codefresh-yaml/steps/composition/). In freestyle steps, it is automatically present without any extra configuration. |
-| {% raw %}`${{CF_VOLUME_PATH}}`{% endraw %} | Refers to the mounted path of the [shared volume]({{site.baseurl}}/docs/configure-ci-cd-pipeline/introduction-to-codefresh-pipelines/#sharing-the-workspace-between-build-steps) inside a Freestyle container. In the current implementation it expands to `/codefresh/volume`. |
-| {% raw %}`${{CF_BUILD_TRIGGER}}`{% endraw %} | Will be an indication of the current build was triggered: *build: The build was triggered from the build button* webhook: The build was triggered from a control version webhook |
-| {% raw %}`${{CF_BUILD_ID}}`{% endraw %} | The build id. Note: use this variable as string with quotes to tag the image {% raw %}`${{CF_BUILD_ID}}`{% endraw %} |
-| {% raw %}`${{CF_BUILD_TIMESTAMP}}`{% endraw %} | The timestamp the build was created. Note: use this variable as string with quotes to tag the image {% raw %}`${{CF_BUILD_TIMESTAMP}}`{% endraw %} |
-| {% raw %}`${{CF_BUILD_URL}}`{% endraw %} | The URL to the build in Codefresh |
-| {% raw %}`${{CF_PIPELINE_NAME}}`{% endraw %} | The full path of the pipeline, i.e. "project/pipeline" |
-| {% raw %}`${{CF_STEP_NAME}}`{% endraw %} | the name of the step, i.e. "MyUnitTests" |
-| {% raw %}`${{CF_URL}}`{% endraw %} | The URL of Codefresh system |
-| {% raw %}`${{CI}}`{% endraw %} | The value is always `true` |
-| {% raw %}`${{CF_KUBECONFIG_PATH}}`{% endraw %} | Path to injected kubeconfig if at least one Kubernetes cluster [is configured]({{site.baseurl}}/docs/deploy-to-kubernetes/add-kubernetes-cluster/). You can easily run [custom kubectl commands]({{site.baseurl}}/docs/deploy-to-kubernetes/custom-kubectl-commands/) since it is automatically setup by Codefresh in all pipelines. |
-| Any variable specified in the pipeline settings | For example, if you configure the pipeline settings with a variable named PORT, you can put the variable in your YAML build descriptor as {% raw %}`${{PORT}}`{% endraw %}. |
-
-## Context Related Variables
-Context related variables are created dynamically during the workflow execution and according to the used steps.
-
-{: .table .table-bordered .table-hover}
-| Variable | Description |
-| ------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| **Working Directories** | For example, you can set the working directory of step `A` with a variable named after a previously executed step, step `B`. Therefore, setting step `A` with {% raw %}`working-directory:${{B}}`{% endraw %} means that step `A` executes in the same working directory as step `B`. |
-| **Images** | You can set the candidate field of the push step with a variable named after a previously executed build step. Since the details of a created image are not necessarily known ahead of time, the variable can create an association to an optionally dynamic image name. Therefore, setting push step `A` with {% raw %}`candidate:${{B}}`{% endraw %} means that step `A` will push the image built by step `B`. Note that this capability works only for `candidate` and `image` fields in Codefresh steps. |
-
-A very common pattern in Codefresh pipelines, is to create a Docker image in one step, and then run a command on its container in the next step (e.g. run [unit tests]({{site.baseurl}}/docs/testing/unit-tests/)):
-
-`YAML`
-{% highlight yaml %}
-{% raw %}
-version: '1.0'
-steps:
- MyAppDockerImage:
- title: Building Docker Image
- type: build
- image_name: my-own-app
- MyUnitTests:
- title: Running Unit tests
- image: ${{MyAppDockerImage}}
- commands:
- - ./my-unit-tests.sh
-{% endraw %}
-{% endhighlight %}
-
-In the example above you can see the `MyAppDockerImage` variable that denotes a Docker image created dynamically within this single pipeline. In the second step we use it as a Docker context in order to run unit tests. See also the [unit testing example app]({{site.baseurl}}/docs/yaml-examples/examples/run-unit-tests/).
-
-## Step variables
-
-Every [step]({{site.baseurl}}/docs/codefresh-yaml/steps/) in a Codefresh pipeline also exposes several built-in variables. You can access them via the global `steps` parent variable.
-
- * Each step creates a variable based on the name of the step. You can then use the members of each variable for status conditions such as: `steps.MyUnitTests.result == 'error'` for a step called `MyUnitTests`.
- * To access variables that have a non-standard (i.e. only alphanumeric and _ characters) names, use the Variable() function.
-
-### Step Member variables
-
-Variables that are created by steps can have members. The members depend on the step type. For example if you have a build step named `myBuildStep` you can get the ID of the docker image that gets created with {% raw %}`echo ${{steps.myBuildStep.imageId}}`{% endraw %}
-
-{: .table .table-bordered .table-hover}
-| Step Type | Members |
-| ------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
-| All step types | {::nomarkdown}
{:/} |
-
-
-
-## GitHub Release Variables
-
-GitHub allows you to create [releases](https://help.github.com/articles/creating-releases/) for marking specific Git tags for general availability.
-
-You can set a [trigger]({{site.baseurl}}/docs/configure-ci-cd-pipeline/triggers/git-triggers/) for GitHub releases. When a GitHub release happens, the following variables are also available:
-
-
-
-{: .table .table-bordered .table-hover}
-| Variable | Description |
-| --------------- | ------------------------------------------------------ |
-| {% raw %}`${{CF_RELEASE_NAME}}`{% endraw %} | GitHub release title |
-| {% raw %}`${{CF_RELEASE_TAG}}`{% endraw %} | Git tag version |
-| {% raw %}`${{CF_RELEASE_ID}}`{% endraw %} | Internal ID for this release |
-| {% raw %}`${{CF_PRERELEASE_FLAG}}`{% endraw %} | true if the release if marked as non-production ready, false if it is ready for production |
-
-## GitHub Pull Request Variables
-
-When a pull request is closed in GitHub, the following variables are also available
-
-{: .table .table-bordered .table-hover}
-| Variable | Description |
-| --------------- | ------------------------------------------------------ |
-| {% raw %}`${{CF_PULL_REQUEST_MERGED}}`{% endraw %} | true if the pull request was merged to base branch |
-| {% raw %}`${{CF_PULL_REQUEST_HEAD_BRANCH}}`{% endraw %} | the head branch of the PR (the branch that we want to merge to master) |
-| {% raw %}`${{CF_PULL_REQUEST_MERGED_COMMIT_SHA}}`{% endraw %} | the commit SHA on the base branch after the pull request was merged (in most cases it will be master) |
-| {% raw %}`${{CF_PULL_REQUEST_HEAD_COMMIT_SHA}}`{% endraw %} | the commit SHA on the head branch (the branch that we want to push) |
-
-## User Provided Variables
-
-User provided variables can be defined at 6 levels:
-
-1. Manually within a step using the [export](http://linuxcommand.org/lc3_man_pages/exporth.html) command or in any **subsequent** step with the [cf_export]({{site.baseurl}}/docs/codefresh-yaml/variables/#using-cf_export-command) command
-1. [Freestyle Step Definition]({{site.baseurl}}/docs/codefresh-yaml/steps/freestyle/#examples) (using the `environment` field)
-1. Specific build Execution (after clicking the "Build" button open the "Build Variables" section, or use the [CLI]({{site.baseurl}}/docs/integrations/codefresh-api/#example---triggering-pipelines))
-1. Pipeline Definition (under "Environment variables" section in the [pipeline view]({{site.baseurl}}/docs/configure-ci-cd-pipeline/pipelines/#creating-new-pipelines))
-1. [Shared Configuration]({{site.baseurl}}/docs/configure-ci-cd-pipeline/shared-configuration/) (defined under your account settings, and used using the "Import from shared configuration" button under the "Environment Variables" section in the pipeline view)
-1. Variables defined on the Project level (Under the variables tab on any project view)
-
-The options are listed in order of priority (from the most important to the least important), so in case of multiple variables defined at different locations with the same name, the order of overriding will be as listed here.
-
-For example if a pipeline variable is defined both in project level and as an execution parameter of a specific build, then the final result will be the value defined as a build parameter and the project level variable will not take effect.
-
-## Exporting environment variables from a freestyle step
-
-Steps defined inside steps are scoped to the step they were created in (even if you used the `export` command). In order to allow using variables across steps, we provide a shared file that facilitates variables importing and exporting. There are two ways to add variables to this file:
-
-### Using cf_export command
-Within every freestyle step, the `cf_export` command allows you to export variables across steps (by writing to the shared variables file).
-
-> The variables exported with cf_export overrides those at the pipeline-level.
-
-You can either:
-- Explicitly state a VAR=VAL pair
-- State the name of an existing *exported* environment variable (like EXISTING_VAR).
-
-{% highlight yaml %}
-{% raw %}
-version: '1.0'
-steps:
- freestyle-step-1:
- description: Freestyle step..
- title: Free styling
- image: alpine:latest
- commands:
- # Normal export will only work in a single step
- - export EXISTING_VAR=www.example.com
-
- # CF export will now work in all other subsequent steps
- - cf_export VAR1=alpine:latest VAR2=VALUE2 EXISTING_VAR
-
- freestyle-step-2:
- description: Freestyle step..
- title: Free styling 2
- image: ${{VAR1}}
- commands:
- - echo $VAR2
- - echo http://$EXISTING_VAR/index.php
-{% endraw %}
-{% endhighlight %}
-
-Notice that `cf_export` has the same syntax structure as the [bash export command](https://www.gnu.org/software/bash/manual/html_node/Environment.html). This means that when you use it you **don't** need any dollar signs for the variable created/assigned.
-
-```
-cf_export $MY_VAR # Don't do this
-cf_export MY_VAR # Correct syntax
-```
-
-Also notice that `cf_export` works on *subsequent* steps only. If you want to export a variable right away in the present step and all the rest of the steps you need to do the following:
-
-```
-export MY_VAR='example' # Will make MY_VAR available in this step only
-cf_export MY_VAR='example' # Will also make MY_VAR available to all steps after this one
-```
-
-There is nothing really magic about `cf_export`. It is a normal script. You can see its contents on your own by entering the command `cat /codefresh/volume/cf_export` on any [Codefresh freestyle step]({{site.baseurl}}/docs/codefresh-yaml/steps/freestyle/) inside a pipeline.
-
-For more information on its limitations see the [troubleshooting page]({{site.baseurl}}/docs/troubleshooting/common-issues/cf-export-limitations/).
-
-
-
-### Directly writing to the file
-
-For more advanced use cases, you can write directly to the shared variable file that Codefresh reads to understand which variables need to be available to all steps. This file has a simple format where each line is a variable and its value in the form of `VARIABLE=VALUE`. The `cf_export` command mentioned in the previous section is just a shorthand for writing on this file.
-
-The variables file is available inside freestyle steps in the following path: **`{% raw %}${{CF_VOLUME_PATH}}{% endraw %}/env_vars_to_export`**
-
-{% highlight yaml %}
-{% raw %}
-version: '1.0'
-steps:
- freestyle-step-1:
- description: Freestyle step..
- title: Free styling
- image: alpine:latest
- commands:
- - echo VAR1=192.168.0.1 >> ${{CF_VOLUME_PATH}}/env_vars_to_export
- - echo hey=alpine:3.9 >> ${{CF_VOLUME_PATH}}/env_vars_to_export
-
- freestyle-step-2:
- description: Freestyle step..
- title: Free styling 2
- image: ${{hey}}
- commands:
- - echo http://$VAR1/index.php
-{% endraw %}
-{% endhighlight %}
-
-Use this technique if you have complex expressions that have issues with the `cf_export` command.
-
-## Masking variables in logs
-
-Codefresh has the built-in capabililty to automatically mask variables in logs if they are encrypted. The values of encrypted variables will be replaced with asterisks in build logs.
-
-{% include
-image.html
-lightbox="true"
-file="/images/codefresh-yaml/variables/masked-variables.png"
-url="/images/codefresh-yaml/variables/masked-variables.png"
-alt="Masked variables"
-caption="Masked variables"
-max-width="80%"
-%}
-
-The variables can be defined in any of the usual ways Codefresh offers such as [shared configuration]({{site.baseurl}}/docs/configure-ci-cd-pipeline/shared-configuration/) or [within the pipeline]({{site.baseurl}}/docs/configure-ci-cd-pipeline/pipelines/#pipeline-settings):
-
-{% include
-image.html
-lightbox="true"
-file="/images/codefresh-yaml/variables/encrypted-variables.png"
-url="/images/codefresh-yaml/variables/encrypted-variables.png"
-alt="Encrypted variables"
-caption="Encrypted variables"
-max-width="60%"
-%}
-
->Notice that this feature is currently available only in Enterprise accounts.
-
-
-## Escape Characters
-When passing special characters through environmental variables `\` can be used as an escape character. For example if you were passing a cassandra connection string you might do something like `Points\=hostname\;Port\=16376\;Username\=user\;Password\=password`
-
-This will safely escape `;` and `=`.
-
-## What to read next
-
-* [Pipeline steps]({{site.baseurl}}/docs/codefresh-yaml/steps/)
-* [Codefresh Conditionals]({{site.baseurl}}/docs/codefresh-yaml/conditional-execution-of-steps/)
-* [Expression Syntax]({{site.baseurl}}/docs/codefresh-yaml/condition-expression-syntax/)
diff --git a/_docs/codefresh-yaml/what-is-the-codefresh-yaml.md b/_docs/codefresh-yaml/what-is-the-codefresh-yaml.md
deleted file mode 100644
index 36f3344ff..000000000
--- a/_docs/codefresh-yaml/what-is-the-codefresh-yaml.md
+++ /dev/null
@@ -1,378 +0,0 @@
----
-title: "Codefresh YAML"
-description: "How to define Codefresh pipelines in a declarative manner"
-group: codefresh-yaml
-redirect_from:
- - /docs/codefresh-yaml/
- - /docs/what-is-the-codefresh-yaml
- - /docs/what-is-the-codefresh-yaml/
- - /docs/codefresh-yaml/working-directories/
- - /docs/working-directories/
-toc: true
----
-
-Codefresh offers its own built-in format for creating pipelines. The pipeline specification is
-based on the YAML syntax allowing you to describe your pipelines in a completely declarative manner.
-
-Using Codefresh yaml is the recommended way to [create pipelines]({{site.baseurl}}/docs/configure-ci-cd-pipeline/pipelines/).
-
-## Simple example for codefresh.yml
-
-Here is a very minimal example:
-
- `codefresh.yml`
-{% highlight yaml %}
-version: '1.0'
-steps:
- build_image:
- type: build
- description: Building the image...
- image-name: myuser/myservice
- tag: develop # {% raw %}${{CF_BRANCH}}{% endraw %}
-
- perform_tests:
- image: node:5
- working_directory: {% raw %}${{main_clone}}{% endraw %}
- description: Performing unit tests...
- commands:
- - npm install gulp -g
- - npm install
- - gulp unit_test
-{% endhighlight %}
-
-It contains two [steps]({{site.baseurl}}/docs/codefresh-yaml/steps/), one named *build_image* that creates a docker image, and another one called *perform_tests* that runs unit test with `gulp`.
-
-If you want to know more about how steps work in Codefresh make sure to read [the introduction to Pipelines]({{site.baseurl}}/docs/configure-ci-cd-pipeline/introduction-to-codefresh-pipelines/) first, before moving on.
-
-## Basic pipeline syntax
-
-You can customize your build environment (pipeline) by using the Codefresh YAML file, ```codefresh.yml```. Codefresh uses the build specifications in the ```codefresh.yml``` file to execute your build. The ```codefresh.yml``` can be basic or it can include intricate build specifications.
-
-A YAML file is comprised of a series of steps that are executed in the order in which they are specified.
-
- `codefresh.yml`
-{% highlight yaml %}
-version: '1.0'
-
-steps:
- step-name:
- [step-contents]
- another-step:
- [step-contents]
- the-very-last-step:
- [step-contents]
-{% endhighlight %}
-
-You must define a step type for each step, unless you are using a [freestyle step]({{site.baseurl}}/docs/codefresh-yaml/steps/freestyle/). Each step uses Docker images and containers as facilitators for execution. For example, the [**Freestyle**]({{site.baseurl}}/docs/codefresh-yaml/steps/freestyle/) step spins up a container and executes the specified shell commands from the YAML file.
-
-The step names should be unique within the same pipeline. This mainly affects the visualization of the pipeline when it runs.
-
-Each step produces a resource, which you can [reference](https://github.com/codefresh-contrib/python-flask-sample-app/blob/master/codefresh.yml#L23) in other steps, and are executed in real-time. For example, a [**Freestyle**]({{site.baseurl}}/docs/codefresh-yaml/steps/freestyle/) step can reference an image that was produced by a [**Build**]({{site.baseurl}}/docs/codefresh-yaml/steps/build/) step. This allows you to chain steps together and create highly-customized builds.
-
-
-##### Variables
-
-Steps chaining and referencing is possible due to implementation of variables in yml file - read more on relevant [section]({{site.baseurl}}/docs/codefresh-yaml/variables/)
-
-
-{: .table .table-bordered .table-hover}
-| Step Type | Description |
-| ----------------------------------------------------------------------------------------------------------------- | ---------------------------------------------- |
-| [Freestyle]({{site.baseurl}}/docs/codefresh-yaml/steps/freestyle/) | Executes one or more shell commands in a container similar to `docker run`. |
-| [Build]({{site.baseurl}}/docs/codefresh-yaml/steps/build/) | Builds a Docker image like `docker build`. |
-| [Push]({{site.baseurl}}/docs/codefresh-yaml/steps/push/) | Pushes a Docker image to an external registry similar to `docker tag` and `docker push`. |
-| [Git Clone]({{site.baseurl}}/docs/codefresh-yaml/steps/git-clone/) | Overrides the default git clone behavior. |
-| [Composition]({{site.baseurl}}/docs/codefresh-yaml/steps/composition/) | Starts a Docker Composition like `docker-compose`. Discarded once pipelines finishes. |
-| [Launch Composition]({{site.baseurl}}/docs/codefresh-yaml/steps/launch-composition/) | Starts a long term Docker composition that stays up after the end of the pipeline. |
-| [Deploy]({{site.baseurl}}/docs/codefresh-yaml/steps/deploy/) | Deploys to Kubernetes clusters. |
-| [Approval]({{site.baseurl}}/docs/codefresh-yaml/steps/approval/) | Pauses a pipeline and waits for human intervention. |
-
-
-For more information on creating your own step, see the [steps page]({{site.baseurl}}/docs/codefresh-yaml/steps/).
-
-You can also see the [full YAML specification]({{site.baseurl}}/docs/integrations/codefresh-api/#full-pipeline-specification) supported for pipelines. Note however that several fields are only accessible by using the [Codefresh API]({{site.baseurl}}/docs/integrations/codefresh-api) or [CLI](https://codefresh-io.github.io/cli/).
-
-## Yaml validation
-
-If you are editing Codefresh yaml within the Codefresh GUI, the editor will automatically highlight errors as they happen.
-
-This allows you to make quick edits (and possibly run some builds) straight from the GUI. Once you are happy with your pipeline you should commit it to your repository as `codefresh.yml` (pipeline as code).
-
-{% include
-image.html
-lightbox="true"
-file="/images/codefresh-yaml/inline-editor.png"
-url="/images/codefresh-yaml/inline-editor.png"
-alt="Graphical Inline Yaml Editor"
-caption="Graphical Inline Yaml Editor"
-max-width="50%"
-%}
-
-You can also validate the pipeline yaml outside of the UI by using the [Codefresh CLI](https://codefresh-io.github.io/cli/). The CLI has a [validate parameter](https://codefresh-io.github.io/cli/validation/) that can check one or more files for syntax errors
-
-{% highlight shell %}
-{% raw %}
-$ codefresh validate codefresh.yml
-Yaml not valid:
- - "invalid-property" is not allowed
-{% endraw %}
-{% endhighlight %}
-
-For more information on where the YAML file can be stored see the [creating pipelines page]({{site.baseurl}}/docs/configure-ci-cd-pipeline/pipelines/).
-
-## Execution flow
-
-By default, Codefresh will execute all steps in the yaml file and instantly fail the build, if any step
-presents an error. To change this behavior add the `fail_fast:false` property in any step that you wish to be ignored
-in case of errors.
-
-For example, if you have a [freestyle step]({{site.baseurl}}/docs/codefresh-yaml/steps/freestyle/) that runs integration tests, and you don't want the whole pipeline
-to fail if any of the tests fail, add the `fail_fast` line to that step:
-
-
-{% highlight yaml %}
-perform_tests:
- image: node:9
- description: Running integration tests
- fail_fast: false
- commands:
- - gulp integration_test
-{% endhighlight %}
-
-Now the pipeline will continue to run even if the step `perform_tests` fails.
-
-Notice also that by default Codefresh pipelines run in *sequential mode*. All steps will be executed one after
-the other and in the same order as included in the `codefresh.yml` file.
-
-If you wish to use parallel steps in your pipelines, see the [parallel steps]({{site.baseurl}}/docs/codefresh-yaml/advanced-workflows/) page.
-
-## Working directories
-
-In the context of a step, a working directory can be of the following type:
-
-{: .table .table-bordered .table-hover}
-| Working Directory | Description |
-| --------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Empty | Defaults to the [Codefresh volume]({{site.baseurl}}/docs/configure-ci-cd-pipeline/introduction-to-codefresh-pipelines/#sharing-the-workspace-between-build-steps) (found at `/codefresh/volume`). If there is a [git clone step]({{site.baseurl}}/docs/codefresh-yaml/steps/git-clone/) with the special name `main_clone` then the default working directory for built-in steps is now the [project folder]({{site.baseurl}}/docs/configure-ci-cd-pipeline/introduction-to-codefresh-pipelines/#cloning-the-source-code) that was checked out - this only applies to [built-in]({{site.baseurl}}/docs/codefresh-yaml/steps/#built-in-steps) Codefresh steps and not [custom plugins]({{site.baseurl}}/docs/codefresh-yaml/steps/#creating-a-typed-codefresh-plugin). |
-| Variable that contains the ID of a [Git-Clone]({{site.baseurl}}/docs/codefresh-yaml/steps/git-clone/) step | Runs the step within the cloned directory. |
-| Variable that contains the ID of any other step | Runs the step within the same working directory that the specified was executed. This option is not available for for [**Git-Clone**]({{site.baseurl}}/docs/codefresh-yaml/steps/git-clone/) steps. |
-| Absolute filesystem path | Treated as is within the container. |
-| Relative filesystem path | Treated as relative path from the cloned directory of the service |
-| 'IMAGE_WORK_DIR' | Use this value in order to use the image working directory for example: `working_directory: IMAGE_WORK_DIR` |
-
-## Retrying a step
-
-Sometimes you want to retry a step that has a problem. Network hiccups, transient failures and flaky test environments are common problems that prevent pipelines from working in a predictable manner.
-
-Codefresh allows you to retry any of your steps with the built-in syntax:
-
- `yaml`
-{% highlight yaml %}
-{% raw %}
-step-name:
- [step-contents]
- retry:
- maxAttempts: 5
- delay: 5
- exponentialFactor: 2
-{% endraw %}
-{% endhighlight %}
-
-The `retry:` block has the following parameters:
-
- * `maxAttempts` defines how many times this step will run again if there are execution errors (default is 1 and the Max. is 10).
- * `delay` is the number of seconds to wait before each attempt (default is 5 seconds and the Max. is 60 seconds).
- * `exponentialFactor` defines how many times the delay should be multiplied by itself after each attempt (default is 1 and Max. is 5).
-
-All parameters are optional. The exponentialFactor works like this:
-* exponentialFactor=1, delay=5 => each time wait 5 seconds before trying again, no matter the number of attempts.
-* exponentialFactor=2, delay=5 => first retry will have a delay of 25 seconds, third will have 125 and so on.
-
-
-Here is a full example:
-
- `codefresh.yml`
-{% highlight yaml %}
-{% raw %}
-version: '1.0'
-steps:
- MyAppDockerImage:
- title: Building Docker Image
- type: build
- image_name: my-own-app
- retry:
- maxAttempts: 2
- MyUnitTests:
- title: Running Unit tests
- image: ${{MyAppDockerImage}}
- commands:
- - ./my_unit_tests.sh
- retry:
- maxAttempts: 3
- delay: 5
- PushingToRegistry:
- type: push
- title: Pushing To Registry
- candidate: ${{MyAppDockerImage}}
- tag: '${{CF_BRANCH}}'
- retry:
- maxAttempts: 3
- delay: 3
- exponentialFactor: 2
-{% endraw %}
-{% endhighlight %}
-
-Notice that Codefresh also provides the following variables that allow you change your script/applications according to the retry attempts:
-
-* `CF_CURRENT_ATTEMPT` contains the number of current retry attempt.
-* `CF_MAX_ATTEMPTS` contains all the number of total attempts defined.
-
-The retry mechanism is available for all kinds of [steps]({{site.baseurl}}/docs/codefresh-yaml/steps/).
-
-## Escaping strings
-
-If you want to use strings inside your pipeline that create conflicts with the Codefresh syntax parser (for example they are YAML themselves) you need
-to escape them using multi-line strings with the `>-` and `|-` characters.
-
-The following pipeline is not parsed correctly because the echo command is using the yaml `:` character
-
-{% highlight yaml %}
-{% raw %}
-version: "1.0"
-steps:
- test:
- title: "Running test"
- type: "freestyle"
- image: "alpine:3.9"
- commands:
- - echo hello: world
-{% endraw %}
-{% endhighlight %}
-
-You can fix this issue by using a multi-line YAML string:
-
-{% highlight yaml %}
-{% raw %}
-version: "1.0"
-steps:
- test:
- title: "Running test"
- type: "freestyle"
- image: "alpine:3.9"
- commands:
- - |-
- echo hello: world
-{% endraw %}
-{% endhighlight %}
-
-The `|-` character keeps the line breaks of the text (but removes the last one). Use the `>-` character if you want to convert line breaks to spaces.
-For more information see the [YAML specification](https://yaml.org/spec/1.2/spec.html).
-
-## Using YAML anchors to avoid repetition
-
-Codefresh also supports yaml anchors, references and extends. These allow you to keep
-your pipeline [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself).
-
-For example, let's say that you have two freestyle steps:
-
-1. The first one fills a MySQL server with data.
-1. The second one runs integration tests that use the MySQL server.
-
-Here is the respective pipeline:
-
- `codefresh.yml`
-{% highlight yaml %}
-version: '1.0'
-steps:
- preLoadDatabase:
- title: Loading Data
- image: alpine
- commands:
- - printenv
- - echo "Loading DB"
- environment: &my_common_envs
- - MYSQL_HOST=mysql
- - MYSQL_USER=user
- - MYSQL_PASS=password
- - MYSQL_PORT=3351
- runTests:
- title: Integration tests
- image: alpine
- commands:
- - printenv
- - echo "Running tests"
- environment: *my_common_envs # Same MYSQL_HOST, MYSQL_USER etc.
-{% endhighlight %}
-
-Instead of repeating the same environment variables in both steps, we can create them once and then just reference them in the second step with the `*` character.
-
-You also define anchors at the top of the pipeline in the special `indicators` block:
-
- `codefresh.yml`
-{% highlight yaml %}
-version: '1.0'
-
-indicators:
- - environment: &my_common_envs
- - MYSQL_HOST=mysql
- - MYSQL_USER=user
- - MYSQL_PASS=password
- - MYSQL_PORT=3351
-
-steps:
- preLoadDatabase:
- title: Loading Data
- image: alpine
- commands:
- - printenv
- - echo "Loading DB"
- environment: *my_common_envs # Same MYSQL_HOST, MYSQL_USER etc.
- runTests:
- title: Integration tests
- image: alpine
- commands:
- - printenv
- - echo "Running tests"
- environment: *my_common_envs # Same MYSQL_HOST, MYSQL_USER etc.
-
-{% endhighlight %}
-
-
-Finally. you also extend steps like below:
-
- `codefresh.yml`
-{% highlight yaml %}
-version: '1.0'
-steps:
- deploy_to_k8_staging: &my_basic_deployment
- title: deploying to cluster
- type: deploy
- kind: kubernetes
- cluster: myStagingCluster
- namespace: sales
- service: my-python-app
- deploy_to_k8_prod:
- <<: *my_basic_deployment
- cluster: myProdCluster # only cluster differs, everything else is the same
-
-{% endhighlight %}
-
-Here we deploy to two kubernetes clusters. The first step defines the staging deployment.
-For the second step, we extend the first one and only change the name of the cluster
-to point to production. Everything else (i.e. namespace and service) are exactly the same.
-
-
-## What to read next
-
-* [Pipeline steps]({{site.baseurl}}/docs/codefresh-yaml/steps/)
-* [Variables]({{site.baseurl}}/docs/codefresh-yaml/variables/)
-* [Advanced workflows]({{site.baseurl}}/docs/codefresh-yaml/advanced-workflows/)
-* [Creating pipelines]({{site.baseurl}}/docs/configure-ci-cd-pipeline/pipelines/)
-* [YAML examples]({{site.baseurl}}/docs/yaml-examples/examples/)
-
-
-
-
-
-
-
diff --git a/_docs/configure-ci-cd-pipeline/introduction-to-codefresh-pipelines.md b/_docs/configure-ci-cd-pipeline/introduction-to-codefresh-pipelines.md
deleted file mode 100644
index fd87b5f17..000000000
--- a/_docs/configure-ci-cd-pipeline/introduction-to-codefresh-pipelines.md
+++ /dev/null
@@ -1,341 +0,0 @@
----
-title: "Introduction to Codefresh pipelines"
-description: "Understand how Codefresh pipelines work"
-group: configure-ci-cd-pipeline
-redirect_from:
- - /docs/introduction-to-codefresh-pipelines/
- - /docs/configure-ci-cd-pipeline/
-toc: true
----
-
-
-The central component of the Codefresh Platform are pipelines. Pipelines are workflows that contain individual steps.
-Each step is responsible for a specific action in the process. Pipelines can be used to:
-
-* Compile and package code
-* Build Docker images
-* Push Docker images to any [Docker Registry]({{site.baseurl}}/docs/docker-registries/external-docker-registries/)
-* Deploy applications/artifacts to VMs, Kubernetes clusters, FTP sites, S3 buckets etc.
-* Run [unit tests]({{site.baseurl}}/docs/testing/unit-tests/), [integration tests]({{site.baseurl}}/docs/testing/integration-tests/), acceptance tests etc.
-* Any custom action that you define
-
-{% include
-image.html
-lightbox="true"
-file="/images/codefresh-yaml/stages/complex-pipeline.png"
-url="/images/codefresh-yaml/stages/complex-pipeline.png"
-alt="Codefresh pipelines"
-caption="Codefresh pipelines"
-max-width="90%"
-%}
-
-## Why Codefresh is different
-
-Codefresh offers unique characteristics in pipelines that serve as the cornerstone of the build/deploy process:
-
-1. All [steps]({{site.baseurl}}/docs/codefresh-yaml/steps/) in Codefresh pipelines are executed inside a Docker container of your choosing.
-1. All steps in Codefresh share the same "workspace" in the form of a shared Docker volume.
-1. The shared Docker volume is automatically cached between pipeline executions.
-1. Each successful pipeline automatically pushes its Docker image to the default Docker registry defined in your account.
-1. Codefresh has a distributed Docker cache for all build nodes and caches layers similar to the docker daemon on your workstation. This is fully automated, and no configuration is needed in order to activate it.
-
-### Using Docker containers as build tooling
-
-Unlike traditional solutions, Codefresh was built from the ground up to have full Docker support. All Codefresh pipelines
-deal with Docker images, either using them as runtime tools or creating them as deployment artifacts.
-Everything that happens in Codefresh uses a Docker image behind the scenes.
-
-It is important that you understand how to take advantage of Docker-based pipelines as they are much more powerful than
-traditional VM solutions. The capability to define your own tooling cannot be understated. It is the fastest way to take
-full control of your build tools and to upgrade them easily.
-
-With traditional VM-based build solutions you are constrained on the build and deployment tools provided by the vendor.
-If for example you need a new version of Node/Java/Python other than the one that is provided on the build slave, you have to wait for your vendor to add it. If you need to use a special tool (e.g terraform, gcloud) and the vendor does
-not support it you are out of luck.
-
-With Codefresh you don't care about what is installed in the runners that execute your builds. They can run *any* Docker image of your choosing. You are free to update the version of the image used at any given time.
-
-Here is an example:
-
-{% include
-image.html
-lightbox="true"
-file="/images/pipeline/introduction/steps-example1.png"
-url="/images/pipeline/introduction/steps-example1.png"
-alt="Codefresh steps example 1"
-caption="Pipeline with 3 steps"
-max-width="70%"
-%}
-
-
-1. The first step runs under the context of a Node image that prepares the application and runs [unit tests]({{site.baseurl}}/docs/testing/unit-tests/).
-1. The second step uses an image with s3 command line tools and uploads the test results to a bucket that holds test reports.
-1. The helm step creates a Helm chart and pushes it to a Helm repository.
-
-You don't need to contact Codefresh and ask them to add the s3 executable on the build runners. You just use a premade Docker image that contains it. The version used for Node is defined by you and if you wish to upgrade to another version
-you simply change the definition of the pipeline.
-
-
-Here is another example:
-
-{% include
-image.html
-lightbox="true"
-file="/images/pipeline/introduction/steps-example2.png"
-url="/images/pipeline/introduction/steps-example2.png"
-alt="Codefresh steps example 2"
-caption="Pipeline with 4 steps"
-max-width="70%"
-%}
-
-1. The first step runs under the context of a Maven image that compiles the code and creates an executable.
-1. The second step uses a Docker image that contains terraform and creates a single ECS instance in AWS.
-1. The third step uses a custom Docker image that deploys to the ECS container that was just created.
-1. The last step uploads the Maven reports that were created in step 1 to an FTP site.
-
-You should now start seeing the endless possibilities. You can mix and match any Docker image (either a public one
-or your own) to use a build context in your step. This makes Codefresh a future-proof solution for all build tools
-that exist now and all of them that will appear in the future. As long as there is a Docker image for a tool, Codefresh
-can use it in a pipeline without any extra configuration.
-
-Codefresh also offers a [plugin marketplace](https://codefresh.io/steps/) with several existing plugins.
-
-{% include
-image.html
-lightbox="true"
-file="/images/pipeline/plugin-directory.png"
-url="/images/pipeline/plugin-directory.png"
-alt="Codefresh steps directory"
-caption="Codefresh steps directory"
-max-width="80%"
-%}
-
-
-All plugins in the marketplace are open-source and we accept external contributions so you can easily add your own.
-
-
-### Sharing the workspace between build steps
-
-We have seen in the previous section that Codefresh can use Docker images as the context of a build step. The second
-important point to understand regarding Codefresh pipelines is that the default workspace of each step is shared between all steps in a pipeline.
-
-This happens via a Docker volume which is attached to all Docker containers that represent each step. This volume is
-always available at `/codefresh/volume` and is used as the parent folder where the project is cloned.
-
-{% include
-image.html
-lightbox="true"
-file="/images/pipeline/introduction/codefresh-volume.png"
-url="/images/pipeline/introduction/codefresh-volume.png"
-alt="Codefresh volume"
-caption="All steps share the same volume"
-max-width="90%"
-%}
-
-Anything that is placed on this volume will be available to all steps of the pipeline (as well as to subsequent executions of the same pipeline as we will see later).
-
-Again, this places Codefresh ahead of traditional solutions that execute build steps in a completely isolated manner.
-In traditional VM-based builds, using artifacts produced from one step to another, is a complicated process as one
-must declare which artifact folders should be re-used. Artifact re-use sometimes happens with compression/decompression
-of the respective folder resulting in really slow builds if a project is very big.
-
-Codefresh does not need to bother the user with artifact reuse across steps. *Anything* that is placed in the shared Codefresh volume will automatically be available to the next steps in the pipeline without any extra configuration.
-
-Example 1
-
-{% include
-image.html
-lightbox="true"
-file="/images/pipeline/introduction/codefresh-volume-example1.png"
-url="/images/pipeline/introduction/codefresh-volume-example1.png"
-alt="Codefresh volume example 1"
-caption="Re-using Node Modules"
-max-width="90%"
-%}
-
-1. The first step runs `npm install` and downloads all libraries in `node_modules` into the shared Codefresh volume.
-1. The second step runs `npm test`. The folder `node_modules` is still present from the previous step.
-
-Example 2
-
-{% include
-image.html
-lightbox="true"
-file="/images/pipeline/introduction/codefresh-volume-example2.png"
-url="/images/pipeline/introduction/codefresh-volume-example2.png"
-alt="Codefresh volume example 2"
-caption="Re-using Test reports"
-max-width="90%"
-%}
-
-1. The first step runs `mvn test` and produces some test reports in `target/surefire-reports` into the shared Codefresh volume.
-1. The next step uploads these reports using FTP to an external site.
-
-
-The common volume shared among build steps makes it very easy to create pipelines that work in a gradual manner
-where any step in the pipeline is using artifacts produced by a previous one.
-
->The shared volume is **NOT available** in [build steps]({{site.baseurl}}/docs/codefresh-yaml/steps/build/). This is not a Codefresh limitation. Docker itself [does not allow volumes during builds](https://github.com/moby/moby/issues/14080). There is no folder `/codefresh/volume` inside a Dockerfile for you to access.
-
-You can also use [environment variables]({{site.baseurl}}/docs/codefresh-yaml/variables/) to share information between steps. All predefined environment variables
-are available to all steps, and each individual step can use `cf_export` to inject dynamically during the build process
-extra environment variables.
-
-
-## Working with Codefresh pipelines
-
-Now that we know the basics, we can see how you can take advantage of Docker-based pipelines in order
-to build and deploy your projects.
-
-
-### Cloning the source code
-
-You can clone source code using the built-in [git-clone step]({{site.baseurl}}/docs/codefresh-yaml/steps/git-clone/) as the first step in a Pipeline or run manually your own git clone commands in a freestyle step. Codefresh has built-in [Git integration]({{site.baseurl}}/docs/integrations/git-providers/) with all popular git providers (both cloud and on-premises installations).
-
-Codefresh uses the shared volume as the parent folder of the project. So if your pipeline is connected to a GIT repo that contains `my-project` the following will happen:
-
-* `/codefresh/volume` is the shared directory for all steps
-* `/codefresh/volume/my-project` is where the source code exists. This is also the current working directory
-* Any other directory (e.g. `/bin`, `/var`, `/opt`) depends on the current container image that is used as build context
-
-{% include
-image.html
-lightbox="true"
-file="/images/pipeline/introduction/checkout.png"
-url="/images/pipeline/introduction/checkout.png"
-alt="Codefresh checkout folder"
-caption="Codefresh checkout folder"
-max-width="80%"
-%}
-
-There are three important points to consider regarding these folders.
-
-First, the [working directory]({{ site.baseurl }}/docs/codefresh-yaml/what-is-the-codefresh-yaml/#working-directories) of each step is by default the project folder (e.g. `/codefresh/volume/my-project`). Therefore
-your build step can run commands exactly as you would run them locally (e.g. `npm install, pip install, mvn package, bundle install`).
-
-Secondly, notice that the project folder is placed on the Codefresh volume, so by default it is also available to all other steps. The code that you checkout in the beginning, as well as all other files that are created on it, will
-be available to all steps. Once you create `node_modules`, or any other folder that exists inside the project folder, it will automatically persist for all other steps.
-
-Finally, `/codefresh/volume` is an internal folder name and you should use `{% raw %}${{CF_VOLUME_PATH}}{% endraw %}` in your codefresh.yml file
-if you really want to reference this folder. You can also reference your project folder as `{% raw %}${{CF_VOLUME_PATH}}/${{CF_REPO_NAME}}{% endraw %}` if you need it.
-
-See the [System Provided Variables]({{site.baseurl}}/docs/codefresh-yaml/variables/#system-provided-variables) section for more information.
-
-### Working with Docker inside a Codefresh pipeline
-
-We have already seen that Codefresh pipelines are based on Docker images and that each step runs inside the context of a Docker container. You might be wondering how you can run Docker commands directly inside a Codefresh pipeline.
-
-The answer is that you don't. Even though in the future Codefresh might allow for Docker-in-Docker capabilities, at the moment this is not supported for security reason (only enterprise customers have access to the underlying Docker daemon). Any scripts that you already have that run Docker commands on their own will need to be adapted to Codefresh pipelines.
-
-Usually you want to run a docker command for four reasons:
-
-1. To build a Docker image
-1. To push a Docker image
-1. To run a docker-compose setup
-1. To run a Docker container
-
-For all these situations Codefresh gives you special pipeline steps that perform the respective action. These are:
-
-1. The [build step]({{site.baseurl}}/docs/codefresh-yaml/steps/build/)
-1. The [push step]({{site.baseurl}}/docs/codefresh-yaml/steps/push/)
-1. The [compositions step]({{site.baseurl}}/docs/codefresh-yaml/steps/composition/)
-1. The [freestyle step]({{site.baseurl}}/docs/codefresh-yaml/steps/freestyle/)
-
-The commands you define in a freestyle step run automatically in a Docker container that is attached to that step once the pipeline executes.
-
-Therefore, this command on your local workstation:
-
-```
-docker run python:3.6.4-alpine3.6 pip install .
-```
-
-will become in Codefresh
-
-```
-CollectAllMyDeps:
- title: Install dependencies
- image: python:3.6.4-alpine3.6
- commands:
- - pip install .
-```
-For the plugins in the [Step Marketplace](https://codefresh.io/steps/) we already give an example of the YAML part that must be included in your pipeline:
-
-{% include
-image.html
-lightbox="true"
-file="/images/pipeline/plugin-example.png"
-url="/images/pipeline/plugin-example.png"
-alt="Codefresh steps directory"
-caption="Codefresh steps directory"
-max-width="50%"
-%}
-
-Each plugin also defines its input/output in the form of environment variables and files.
-
-### Creating Docker images dynamically as build tools
-
-
-Now we reach one of the most powerful features of Codefresh pipelines. We have already seen that [freestyle pipeline steps]({{site.baseurl}}/docs/codefresh-yaml/steps/freestyle/) are just a series of commands that run inside the context of a Docker container. In most cases the images used
-for the freestyle steps are known in advance and come from public (e.g. Dockerhub) or [private Docker registries]({{site.baseurl}}/docs/docker-registries/external-docker-registries/).
-
-Codefresh is one the few CI/CD solutions that not only offers easy Docker registry integration
- accessible to all pipelines
-but also allows you to **build docker images on demand in the same pipeline where they are required**.
-
-This means that you can create a special Docker image in an early step inside a Codefresh pipeline and then reference it in a later step in the same pipeline.
-
-{% include
-image.html
-lightbox="true"
-file="/images/pipeline/introduction/dynamic-docker-builds.png"
-url="/images/pipeline/introduction/dynamic-docker-builds.png"
-alt="Codefresh dynamic docker builds"
-caption="Creating dynamically Docker images as build steps"
-max-width="90%"
-%}
-
-Let's say for example that you are moving a legacy application to Codefresh which is deployed using a special Python script. Your main application is a Ruby-On-Rails app. Both applications exist in the same git repository (we mention this for simplicity reasons, Codefresh also supports checking out code from multiple repositories).
-
-You can create a single pipeline with Codefresh that does the following:
-
-1. Checks out the code
-1. Creates a Docker image based on Python for the deployment tool
-1. Uploads the Python tool Docker image to the internal registry
-1. Builds the Ruby application using a freestyle step with the R-O-R image from Dockerhub
-1. Deploys the Ruby application by running the Python based deployment tool image (after pulling it first)
-
-This concept is ground-breaking as it allows you to automatically update your build tools that are used in any pipeline.
-Even though you could manually create the Docker images yourself before-hand, it is better to completely automate them
-inside the pipeline they are actually needed. This ensures that both the application and its tooling are always at the latest version.
-
-### How caching works in Codefresh
-
-Codefresh employs several caching mechanisms for both Dockerized and non-dockerized applications. The shared volume is also cached behind the scenes automatically. See our [caching guide]({{site.baseurl}}/docs/configure-ci-cd-pipeline/pipeline-caching/) for more details.
-
-### Calling other pipelines
-
-It is also possible to chain multiple Pipelines together in Codefresh. To accomplish this, Codefresh offers
-a special Docker image that contains the [Codefresh CLI](https://codefresh-io.github.io/cli/) and allows you to trigger another pipeline using its name.
-
-{% include
-image.html
-lightbox="true"
-file="/images/pipeline/introduction/call-pipeline.png"
-url="/images/pipeline/introduction/call-pipeline.png"
-alt="Codefresh call pipeline"
-caption="Calling another pipeline"
-max-width="80%"
-%}
-
-Notice that each Pipeline in Codefresh is completely isolated from the other. They use a different Docker volume so the build context of each one cannot access files from the other. This may change in the future, but for the time being
-you should know that only steps within the same pipeline can share artifacts.
-
-## What to read next
-
-* [Creating pipelines]({{site.baseurl}}/docs/configure-ci-cd-pipeline/pipelines/)
-* [Codefresh YAML]({{site.baseurl}}/docs/codefresh-yaml/what-is-the-codefresh-yaml/)
-* [Pipeline steps]({{site.baseurl}}/docs/codefresh-yaml/steps/)
-* [Build and Docker caching]({{site.baseurl}}/docs/configure-ci-cd-pipeline/pipeline-caching/)
-
-
-
diff --git a/_docs/configure-ci-cd-pipeline/pipelines.md b/_docs/configure-ci-cd-pipeline/pipelines.md
deleted file mode 100644
index eede4361d..000000000
--- a/_docs/configure-ci-cd-pipeline/pipelines.md
+++ /dev/null
@@ -1,436 +0,0 @@
----
-title: "Creating Pipelines"
-description: "How to define Pipelines in Codefresh"
-group: configure-ci-cd-pipeline
-redirect_from:
- - /docs/pipeline
- - /docs/pipeline/
- - /docs/pipelines
- - /docs/pipelines/
- - /docs/pipelines/introduction/
- - /docs/pipelines/introduction
- - /docs/inline-yaml-editing
- - /docs/inline-yaml-editing/
-toc: true
----
-
-Before reading this page make sure that you are familiar with the theory behind Codefresh pipelines at the [introduction page]({{site.baseurl}}/docs/configure-ci-cd-pipeline/introduction-to-codefresh-pipelines/).
-
-## Pipeline Concepts
-
-The aim of Codefresh pipelines is to have re-usable sequences of steps that can be used for different applications (or micro-services) via the use of git triggers.
-
-All the main concepts are shown below:
-
-{% include
-image.html
-lightbox="true"
-file="/images/pipeline/create/concepts.png"
-url="/images/pipeline/create/concepts.png"
-alt="Pipeline concepts"
-caption="Pipeline concepts"
-max-width="60%"
-%}
-
-* **Projects**: the top-level concept in Codefresh. You can create projects to group pipelines that are related. In most cases a single project will be a single application (that itself contains many micro-services). You are free to use projects as you see fit. For example, you could create a project for a specific Kubernetes cluster or a specific team/department.
-
-* **Pipelines**: each project can have multiple pipelines. Pipelines that belong to a single project are easily managed all together. It is also very easy to create a new pipeline in a project by copying an existing pipeline. Notice that unlike other CI solutions a pipeline in Codefresh is **NOT** tied to a specific git repository. You should try to make your pipelines generic enough so that they can be reused for similar applications even when they exist in different git repositories (a fairly typical setup for microservices).
-
-* **Pipeline Steps**: each pipeline has a definition that defines the [pipeline steps]({{site.baseurl}}/docs/codefresh-yaml/steps/) that are executed each time this pipeline is triggered. The definition of a pipeline is described in a special [codefresh.yml]({{site.baseurl}}/docs/codefresh-yaml/what-is-the-codefresh-yaml/) file. The `codefresh.yml` file can be fetched from the same repository of the source code, from a completely different repository or even defined in-place in the Codefresh pipeline editor. Again, notice that it is possible to have a pipeline that checks out its source code from git repository A, but actually defines its steps in a `codefresh.yml` file that is fetched from git repository B.
-
-* **Triggers**: each pipeline can have zero, one, or more [triggers]({{site.baseurl}}/docs/configure-ci-cd-pipeline/triggers/). Codefresh supports several kinds of triggers such as Git, Cron or Docker push triggers. Triggers that happen with Git webhooks can come from the same git repository that contains the git code **OR** any other completely different repository. Triggers are the linking medium between a pipeline and a git repository. You can have a pipeline with many triggers so it will be executed when a code change happens to any of them.
-
-With these basic building blocks, you can define many complex workflows. In particular, it is very easy in Codefresh to create a scenario where:
-
-1. A pipeline is launched because a trigger exists for Git repository A
-1. The pipeline reads its `codefresh.yml` file from Git repository B
-1. The pipeline clones source code from Git repository C (and starts packaging/compiling it)
-
-Of course, it also possible to have a simpler scenario where the trigger, the pipeline steps and the source code of the application are all defined for the same GIT repository.
-
-
-## Creating New Pipelines
-
-You can create new projects by clicking on *Projects* in the left sidebar and then selecting the *New Project* button on the top right corner. A dialog will appear that will ask you for the project name and optional tags that you can use for [access control]({{site.baseurl}}/docs/enterprise/access-control/).
-
-Once you are inside the project view you can start editing pipelines with a UI environment that works similar to a traditional IDE.
-
-{% include
-image.html
-lightbox="true"
-file="/images/pipeline/create/pipeline-manager.png"
-url="/images/pipeline/create/pipeline-manager.png"
-alt="Pipeline manager"
-caption="Pipeline manager"
-max-width="70%"
-%}
-
-1. On the top left you can see your current project. You can also change it by clicking on the drop-down on the top left corner.
-
-1. On the left side of the screen you can see all pipelines that currently belong to this project. Click on each one to edit it.
-On the bottom part of this panel the *New pipeline* button allows you to create a new pipeline on the same project either from scratch
-or by copying an existing one from the same project or a completely different project.
-
-1. The name of the currently edited pipeline is shown at the top of the window.
-
-1. The main window shows the definition of the current pipeline. The screenshot shows the inline editor but pipelines can also be defined from external files (checked into source control) as explained later.
-
-1. The right part of the window shows extra settings for this pipeline such as [premade steps]({{site.baseurl}}/docs/codefresh-yaml/steps/), [triggers]({{site.baseurl}}/docs/configure-ci-cd-pipeline/triggers/) and launch variables/parameters.
-
-
-
-
-### Using the Inline Pipeline Editor
-
-When first creating a pipeline you will see an inline editor that allows you to define the [pipeline yml]({{site.baseurl}}/docs/codefresh-yaml/what-is-the-codefresh-yaml/) right there in the Codefresh UI. This is great when you are starting a new project because it offers you really quick feedback. You can edit the yml steps, run a build, edit again, run a build and so on.
-
-
-{% include
-image.html
-lightbox="true"
-file="/images/pipeline/create/inline-editor.png"
-url="/images/pipeline/create/inline-editor.png"
-alt="Inline Pipeline editor"
-caption="Inline Pipeline editor"
-max-width="60%"
-%}
-
-On the top right of the panel you have additional controls:
-
-* The *import* button allows you to bring a `codefresh.yml` from your local workstation into the editor
-* The *comment* button allows you to quickly comment/uncomment the currently selected text. The hotkey `Ctrl-/` also performs the same action
-* The *formatting* button enriches the editor with special symbols for line breaks, spaces and tabs. This allows you to easily fix common formatting errors
-* The *copy* button quickly copies the **whole** pipeline text in your clipboard
-* You can use `Ctrl-]` and `Ctrl-[` to change indentation of the current line (use the Command key instead on MacOsX)
-
-
-Notice that in the editor you can expand/collapse individual yaml blocks using the arrow triangles on the left of each blocks. The initial pipeline presented in the editor is suggested by Codefresh according to the contents of your Git repository.
-
-> You can also see the suggested Codefresh pipeline for any public git repository by using the [analyze option](https://codefresh-io.github.io/cli/analyzer/) of the Codefresh CLI.
-
-
-## Loading codefresh.yml from Version Control
-
-Working with the inline editor is very convenient in the beginning, but it makes your pipeline definition only exist within the Codefresh UI and therefore goes against the basic principles of [infrastructure as code](https://en.wikipedia.org/wiki/Infrastructure_as_Code). Once you are happy with how your pipeline works you should commit it to a Git repository (which can be the same one that has the source code of the application or a completely different one).
-
-You can click on the *Inline YAML* header and switch it to *Use YAML from URL* or *Use YAML from Repository*.
-
-{% include
-image.html
-lightbox="true"
-file="/images/pipeline/create/pipeline-git-options.png"
-url="/images/pipeline/create/pipeline-git-options.png"
-alt="Pipeline resource options"
-caption="Pipeline resource options"
-max-width="60%"
-%}
-
-### Using another Git repository
-
-Loading the pipeline from a Git repository is the recommended way to associate a pipeline with a project once you are finished with it. Even though the inline editor is great for quick prototyping and experimentation, ideally all your pipelines should be under source control.
-
-When you click this option from the drop-down menu you will can select any Git repository already connected to Codefresh along with a preview of the pipeline.
-
-{% include
-image.html
-lightbox="true"
-file="/images/pipeline/create/pipeline-per-branch.png"
-url="/images/pipeline/create/pipeline-per-branch.png"
-alt="Load pipeline from Git"
-caption="Load pipeline from Git"
-max-width="60%"
-%}
-
-Note that unlike other CI options the Git repository that contains the pipeline can be completely different from the Git repository that has the source code of your application.
-
-The **Use branch from Git trigger** option is very important and defines from which branch of the Git repo the pipeline will be loaded from. In most cases you want to keep this enabled as it will make the pipeline load from the same branch that triggered the build.
-
-For example if you open a new pull request for a branch named `feature-x` that has changes both in source code and in the pipeline definition itself, ideally you would want the pipeline responsible for the build to be the same one that contains the new changes in the `feature-x` branch.
-
-If you disable this option then you can select a specific branch from the field directly above the switch. The option is great for organizations that want to lock down their pipelines.
-
-For example, if you define `master` as the branch that will be used for this pipeline, then even if a developer creates a custom branch for their source code changes, they will not be able to change the pipeline itself to do something different. Their pipeline changes in their own branch will be ignored as all builds will always load the pipeline from `master`. This can be very useful for security sensitive pipelines.
-
-
-### Using any public URL
-
-The URL option allows you to load the pipeline definition from any _public_
-
-{% include
-image.html
-lightbox="true"
-file="/images/pipeline/create/pipeline-from-internal-repo.png"
-url="/images/pipeline/create/pipeline-from-internal-repo.png"
-alt="Pipeline from internal repo"
-caption="Pipeline from internal repo"
-max-width="70%"
-%}
-
-You can then copy and paste a URL to a raw Codefresh YAML file. This will allow you to load a Codefresh YAML from any URL.
-
-
-Notice that a raw URL is needed in the case of GitHub.
-
-As an example, instead of using `https://github.com/codefresh-contrib/example-voting-app/blob/master/codefresh.yml` you should enter `https://raw.githubusercontent.com/codefresh-contrib/example-voting-app/master/codefresh.yml`
-
-## Pipeline Settings
-
-Once you create your pipeline you can also click on the top tab called *Settings* for some extra parameters.
-
-### General
-
-- **Pipeline Name**: the name of your pipeline (useful for working with the [Codefresh CLI](https://codefresh-io.github.io/cli/))
-- **Pipeline ID**: the ID of your pipeline (useful for working with the [Codefresh CLI](https://codefresh-io.github.io/cli/))
-> Note that the Pipeline Name and ID are interchangeable when working with the Codefresh CLI
-- **Pipeline Description**: a freetext pipeline description
-- **Pipeline Tags**: One or more tags used for [access control]({{site.baseurl}}/docs/enterprise/access-control/)
-- **Public Build Logs**: If enabled, the builds of this pipeline will be [viewable by users without a Codefresh account]({{site.baseurl}}/docs/configure-ci-cd-pipeline/build-status/#public-build-logs
-)
-- **Template**: Convert this pipeline to a template (see the next section for details on templates)
-- **Badges**: simple images that show you the last [build status]({{site.baseurl}}/docs/configure-ci-cd-pipeline/build-status/)
-
-### Policies
-
-- **Kubernetes clusters**: Control pipeline access to Kubernetes clusters integrated with Codefresh.
- * To allow the pipeline access to _all_ the cluster contexts integrated with Codefresh (the default), toggle **Inject all Kubernetes cluster context to pipeline builds** to ON.
- * To allow the pipeline access to _only_ specific clusters, start typing in the name of the cluster as defined in its integration settings, and select it from the list displayed by Codefresh.
- When defined, the initialization step in the pipeline displays the clusters selected for it.
- See [Select Kubernetes cluster contexts](#select-kubernetes-cluster-contexts).
-
-
-
-- **Pipeline Concurrency**: the maximum number of concurrent builds (0-30 or unlimited) -- set this when your pipeline has only one trigger
- > A Pipeline Concurrency of **0** freezes execution of the pipeline, switching it to maintenance mode. Use this concurrency setting to modify existing pipelines and freeze execution until you complete the changes.
-- **Trigger Concurrency**: the maximum number of concurrent builds per trigger (1-31 or unlimited) -- set this when your pipeline has multiple triggers
-- **Branch Concurrency**: the maximum number of concurrent builds per branch (1-31 or unlimited) -- set this when your pipeline can build different branches
-- **Build Termination**: various toggles for when a build from the pipeline should terminate
- - Once a build is created terminate previous builds from the same branch
- - Once a build is created terminate previous builds only from a specific branch (name matches a regular expression)
- - Once a build is created, terminate all other running builds
- - Once a build is terminated, terminate all child builds initiated from it
-- **Pending approval volume**: choose what happens with the [pipeline volume]({{site.baseurl}}/docs/configure-ci-cd-pipeline/introduction-to-codefresh-pipelines/#sharing-the-workspace-between-build-steps) when a pipeline is waiting for [approval]({{site.baseurl}}/docs/codefresh-yaml/steps/approval/#keeping-the-shared-volume-after-an-approval)
- - Keep the volume available
- - Discard the volume
- - Honor the option defined globally in your Codefresh account
-- **Pending approval concurrency limit effect**: decide if a build that is pending approval [counts against]({{site.baseurl}}/docs/codefresh-yaml/steps/approval/#define-concurrency-limits) the concurrency limits or not
- - Builds in pending approval will **not** be counted when determining the concurrency limit for a pipeline
- - Builds in pending approval will **be** counted when determining the concurrency limit for a pipeline
- - Honor the option defined globally in your Codefresh account
-
-
-#### Select Kubernetes cluster contexts
-By default, all clusters integrated with Codefresh are automatically available for all pipelines in the account.
-The inject cluster option when enabled for the account allows you to selectively restrict the clusters which can be accessed from pipelines created for the user account.
-> This option is only available for Enterprise customers.
-
-Increase security by restricting access to users from different teams.
-Codefresh authenticates the credentials of each cluster during the build initialization phase. Fewer clusters mean shorter initializations and reduced build durations.
-
-**Prerequisites**
-* Account-level pipeline setting **Kubernetes cluster context pipeline injection** enabled
- The option to select clusters for a pipeline is available only when the account-level pipeline setting is enabled. See [Enabling cluster contexts for pipelines]({{site.baseurl}}/docs/administration/pipeline-settings/#enabling-cluster-contexts-for-pipelines).
-
-* **Update Cluster** permission for users in the Codefresh UI through [Permissions](https://g.codefresh.io/account-admin/permissions/teams){:target="\_blank"}.
- For more information, see [Access Control](https://codefresh.io/docs/docs/administration/access-control/#access-to-kubernetes-clusters-and-pipelines).
-
-As part of the Pipeline > Policies, you can either allow access to all clusters (the default), or only specific clusters as in the example below.
-
-{% include
-image.html
-lightbox="true"
-file="/images/pipeline/create/inject-cluster-contexts.png"
-url="/images/pipeline/create/inject-cluster-contexts.png"
-alt="Inject Kubernetes cluster contexts into pipeline"
-caption="Inject Kubernetes cluster contexts into pipeline"
-max-width="60%"
-%}
-
-When specific clusters are defined:
-* All users in the account with the Update Cluster permission have access only to the selected clusters.
-* The cluster contexts are injected during the build
-* The initialization step displays the selected cluster contexts
-
-
-{% include
-image.html
-lightbox="true"
-file="/images/pipeline/create/cluster-contexts-in-init-step.png"
-url="/images/pipeline/create/cluster-contexts-in-init-step.png"
-alt="Imported cluster contexts in pipeline's init step"
-caption="Imported cluster contexts in pipeline's init step"
-max-width="60%"
-%}
-
-
-
-
-
-#### Pipeline concurrency
- **Pipeline and Trigger Concurrency** limits are very important as they allow you to define how many instances of a pipeline can run in parallel when multiple commits or multiple pull requests take place.
-
-> Notice that these limits are *unrelated* to [parallelism within a single pipeline]({{site.baseurl}}/docs/codefresh-yaml/advanced-workflows/).
-
-Some common scenarios are:
-
-* a pipeline that uses a shared resource such as a database or queue and you want to limit how many pipelines can access it
-* a pipeline that deploys to a single production environment (in most cases you only want one active pipeline touching production
-
-
-#### Build termination
-The **Build Termination** settings are useful for pipelines where you commit too fast (i.e. faster then the actual runtime of the pipeline).
-All these settings allow you to lesser the build instance for pipelines when too many triggers are launched at the same time.
-You will find them very useful in cases where too many developers are performing small commits and builds take a long time to finish (i.e. build takes 10 minutes to finish and developers perform multiple pushes every 2 minutes)
-
-Some common scenarios are:
-
-* You are interested only on the latest commit of a branch. If pipelines from earlier commits are still running you want to terminate them.
-* You don't want to wait for children pipelines to finish (i.e. when a pipeline calls another pipeline) or when a new build starts for a parent pipeline.
-
-For the volume behavior during approvals, notice that if [you keep the volume available]({{site.baseurl}}/docs/codefresh-yaml/steps/approval/#keeping-the-shared-volume-after-an-approval) on the pipeline while it is waiting for approval it will still count as "running" against your pricing tier limit.
-
-### External Resources
-
-In a big organization you might have some reusable scripts or other resources (such as Dockerfiles) that you want to use in multiple pipelines. Instead of fetching them manually in freestyle steps you can simply define them as *external resources*. When a pipeline runs, Codefresh will fetch them automatically and once the pipeline starts the files/folders will already be available in the paths that you define.
-
-{% include
-image.html
-lightbox="true"
-file="/images/pipeline/create/external-resources.png"
-url="/images/pipeline/create/external-resources.png"
-alt="Bringing external resources into a pipeline"
-caption="Bringing external resources into a pipeline"
-max-width="80%"
-%}
-
-Currently Codefresh supports the automatic fetching of files or folders from another Git repository. To create an external resource click the *Add Resource* button and choose:
-
-* The Git repository that contains the files/folder you wish to bring in the pipeline workspace
-* The branch from the Git repository that contains the files/folders you wish to bring in the pipeline workspace
-* The source folder in the GIT repo (use relative path)
-* The target folder in the pipeline workspace where the file folder will be copied to (use absolute path)
-
-Once the pipeline starts, all files will be available to all freestyle steps in the paths mentioned in the target folder field.
-You can define multiple external resources in a single pipeline.
-
-### Runtime
-
-- **Runtime Environment**: (by default this is set to SaaS)
-- **Runtime OS**: (by default this is set to Linux)
-- **Resources Size**:
- - Small (recommended for 1-2 concurrent steps)
- - Medium (recommended 3-4 steps)
- - Large (recommended 5-6 steps)
-
-#### Set minimum disk space for a pipeline build
-To speed up builds and improve performance, Codefresh caches different types of data during pipeline execution for reuse across builds. Image-caching is one example of cached data, where Codefresh pulls the required images during the first build and caches them for reuse in future builds. For more info, see [Pipeline caching]({{site.baseurl}}docs/configure-ci-cd-pipeline/pipeline-caching).
-Because a portion of the disk space is already utilized by cache, a build can run out of disk space and fail with the 'no space left on device' error.
-
-To prevent out-of-space scenarios that lead to failed builds, you can set the minimum disk space you need for the pipeline's build volume. Defining the minimum disk space ensures that Codefresh assigns either a cached disk with sufficient disk space or a new empty disk at the start of the build.
-
-The disk space set for the pipeline is inherited by all the builds run for the pipeline.
-You can also configure the disk space for a [specific trigger]({{site.baseurl}}/docs/configure-ci-cd-pipeline/triggers/git-triggers/#set-minimum-disk-space-for-build-volume-by-trigger) used by the pipeline or for a specific run, and override what's set for the pipeline.
-
-1. Select the pipeline for which to set the minimum disk space.
-1. Select **Settings**, and then **Runtime**.
-1. Enable **Set minimum required disk space**, and either retain the default displayed or change as needed.
-
-{% include
-image.html
-lightbox="true"
-file="/images/pipeline/create/set-build-disk-space.png"
-url="/images/pipeline/create/set-build-disk-space.png"
-alt="Set disk space for pipeline builds"
-caption="Set disk space for pipeline builds"
-max-width="60%"
-%}
-
-> Track the actual disk usage in Builds > Metrics.
-
-## Using Pipeline Templates
-
-Codefresh also supports the creation of pipeline "templates" which are blueprints for creating new pipelines. To enable the creation of pipelines from templates first visit the global pipeline configuration at [https://g.codefresh.io/account-admin/account-conf/pipeline-settings](https://g.codefresh.io/account-admin/account-conf/pipeline-settings) and toggle the *Enable Pipeline Templates* button.
-
-The easiest way to create a new template is by clicking the "3 dots menu" on the pipeline name:
-
-{% include
-image.html
-lightbox="true"
-file="/images/pipeline/create/create-template-menu.png"
-url="/images/pipeline/create/create-template-menu.png"
-alt="The template menu"
-caption="The template menu"
-max-width="30%"
-%}
-
-From the dialog you can select if you want to copy this pipeline as a brand new template, or simply convert the pipeline itself to a template:
-
-{% include
-image.html
-lightbox="true"
-file="/images/pipeline/create/template-dialog.png"
-url="/images/pipeline/create/template-dialog.png"
-alt="The template dialog"
-caption="The template dialog"
-max-width="80%"
-%}
-
-Once the template is created, you can edit it like any other pipeline. Pipeline templates are marked with the `template` tag and also have a special mark in the pipeline menu:
-
-{% include
-image.html
-lightbox="true"
-file="/images/pipeline/create/template-tag.png"
-url="/images/pipeline/create/template-tag.png"
-alt="template identification"
-caption="template identification"
-max-width="90%"
-%}
-
-Now when you create a new pipeline, you can also select which pipeline template will be used as an initial pipeline definition:
-
-{% include
-image.html
-lightbox="true"
-file="/images/pipeline/create/use-template.png"
-url="/images/pipeline/create/use-template.png"
-alt="Using a template"
-caption="Using a template"
-max-width="70%"
-%}
-
->Notice that templates only take effect during pipeline creation. Changing a template afterwards, has no effect on pipelines that are already created from it.
-
-You can also quickly convert a pipeline to a template, by visiting the pipeline settings and clicking the *template* button under the *General* tab.
-
-
-## Pipelines that do not belong to any project
-
-Although we recommend adding all your pipelines to a project, this is not a hard requirement. You can create pipelines that do not belong to a project from the *Pipelines* section on the left sidebar.
-If you have a Codefresh account created before May 2019 you might already have several pipelines that are like this.
-
-If you change your mind, you can also add detached pipelines (i.e. pipelines that are not part of a project) manually from the 3-dot menu that is found on the right of each pipeline.
-
-{% include
-image.html
-lightbox="true"
-file="/images/pipeline/create/add-pipeline-to-project.png"
-url="/images/pipeline/create/add-pipeline-to-project.png"
-alt="Changing the project of a pipeline"
-caption="Changing the project of a pipeline"
-max-width="90%"
-%}
-
-Pipelines that belong to a project will mention it below their name so it is very easy to understand which pipelines belong to a project and which do not.
-
-
-## What to read next
-
-* [Codefresh YAML]({{site.baseurl}}/docs/codefresh-yaml/what-is-the-codefresh-yaml/)
-* [Pipeline steps]({{site.baseurl}}/docs/codefresh-yaml/steps/)
-* [External Docker Registries]({{site.baseurl}}/docs/docker-registries/external-docker-registries/)
-* [YAML Examples]({{site.baseurl}}/docs/yaml-examples/examples/)
-
-
-
-
-
diff --git a/_docs/configure-ci-cd-pipeline/secrets-store.md b/_docs/configure-ci-cd-pipeline/secrets-store.md
deleted file mode 100644
index 8162db01a..000000000
--- a/_docs/configure-ci-cd-pipeline/secrets-store.md
+++ /dev/null
@@ -1,96 +0,0 @@
----
-title: "Using secrets"
-description: "Use Kubernetes secrets in Codefresh"
-group: configure-ci-cd-pipeline
-toc: true
----
-
-Once you have [connected Codefresh to your secrets storage]({{site.baseurl}}/docs/integrations/secret-storage/), you can use them in any pipeline or GUI screen.
-
-> Note: This feature is for Enterprise accounts only.
-
-## Using secrets in pipelines
-
-The syntax for using the secret is {% raw %}`${{secrets.NAME_IN_CODEFRESH.KEY}}`{% endraw %}.
-
-> Note that if you did not include the resource-name as a part of your secret store context creation, the syntax for using your secret differs slightly:
-The syntax is: {% raw %}${{secrets.NAME_IN_CODEFRESH.RESOURCE-NAME@KEY}}{% endraw %} The previous KEY portion is now made of two parts separated using @, where the left side is the name of the resource in the namespace, and the right side the key in that resource.
-
-To use the secret in your pipeline, you have two options:
-
-Define it as a pipeline variable:
-
-{% include
-image.html
-lightbox="true"
-file="/images/pipeline/secrets/secrets-pipeline-var.png"
-url="/images/pipeline/secrets/secrets-pipeline-var.png"
-alt="Secrets Pipeline Variable"
-caption="Secrets stored in Pipeline Variable"
-max-width="80%"
-%}
-
-`codefresh.yaml`
-{% highlight yaml %}
-{% raw %}
-version: '1.0'
-steps:
- step:
- type: freestyle
- arguments:
- image: alpine
- commands:
- - echo $SECRET
-{% endraw %}
-{% endhighlight %}
-
-Or use it directly in your yaml
-
-`codefresh.yaml`
-{% highlight yaml %}
-{% raw %}
-version: '1.0'
-steps:
- step:
- type: freestyle
- arguments:
- image: alpine
- environment:
- - SECRET=${{secrets.test.key1}}
- commands:
- - echo $SECRET
-{% endraw %}
-{% endhighlight %}
-
-
-## Using secrets in the Codefresh GUI
-
-You can also use secrets in the GUI screens that support them. Currently you can use secrets in:
-
-* Values in [shared configuration]({{site.baseurl}}/docs/configure-ci-cd-pipeline/shared-configuration/)
-* Integration with [cloud storage]({{site.baseurl}}/docs/testing/test-reports/#connecting-your-storage-account)
-
-Where secret integration is supported, click on the lock icon and enable the toggle button. You will get a list of your connected secrets:
-
-
-{% include
-image.html
-lightbox="true"
-file="/images/pipeline/shared-configuration/shared-conf-secret-integration.png"
-url="/images/pipeline/shared-configuration/shared-conf-secret-integration.png"
-alt="Using external secrets in shared configuration values"
-caption="Using external secrets in shared configuration values"
-max-width="50%"
-%}
-
-If you have already specified the resource field during secret definition the just enter on the text field the name of the secret directly, i.e. `my-secret-key`.
-If you didn't include a resource name during secret creation then enter the full name in the field like `my-secret-resource@my-secret-key`.
-
-
-## What to Read Next
-
-* [Shared Configuration]({{site.baseurl}}/docs/configure-ci-cd-pipeline/shared-configuration/)
-* [Git triggers]({{site.baseurl}}/docs/configure-ci-cd-pipeline/triggers/git-triggers/)
-* [Running pipelines locally]({{site.baseurl}}/docs/configure-ci-cd-pipeline/running-pipelines-locally/)
-* [Debugging Pipelines]({{site.baseurl}}/docs//yaml-examples/examples/trigger-a-k8s-deployment-from-docker-registry/)
-
diff --git a/_docs/configure-ci-cd-pipeline/shared-configuration.md b/_docs/configure-ci-cd-pipeline/shared-configuration.md
deleted file mode 100644
index 5f47aff62..000000000
--- a/_docs/configure-ci-cd-pipeline/shared-configuration.md
+++ /dev/null
@@ -1,265 +0,0 @@
----
-title: "Shared configuration"
-description: "How to keep your pipelines DRY"
-group: configure-ci-cd-pipeline
-toc: true
----
-
-After creating several pipelines in Codefresh you will start to notice several common values between them. Common examples are access tokens, environment URLs, configuration properties etc.
-
-Codefresh allows you to create those shared values in a central place and then reuse them in your pipelines
-avoiding the use of copy-paste.
-
-You can share:
-
-* Environment parameters (easy)
-* Helm values (easy)
-* Any kind of YAML data (advanced)
-
-
-## Creating shared configuration
-
-From the left sidebar click *Account settings* to enter your global settings. Then choose *Shared Configuration* from the left menu.
-
-{% include
-image.html
-lightbox="true"
-file="/images/pipeline/shared-configuration/shared-configuration.png"
-url="/images/pipeline/shared-configuration/shared-configuration.png"
-alt="Creating shared configuration snippets"
-caption="Creating shared configuration snippets"
-max-width="50%"
-%}
-
-You can create four types of shared configuration:
-
-* **Shared Configuration**: for environment variables
-* **Shared Secret**: for encrypted environment variables of sensitive data (access tokens, etc.)
-* **YAML**: for Helm values or any other generic information
-* **Secret YAML**: for above, but encrypts the contents
-
->RBAC is supported for all types of shared configurations.
-
-You can create as many shared snippets as you want (with unique names).
-
-### Using external secrets as values
-
-Note that the default "shared secrets" and "secret yaml" entities use the built-in secret storage of Codefresh. You can also
-use any [external secrets that you have defined]({{site.baseurl}}/docs/integrations/secret-storage/) (such as Kubernetes secrets), by using the normal entities and then clicking on the lock icon that appears.
-
-{% include
-image.html
-lightbox="true"
-file="/images/pipeline/shared-configuration/shared-conf-secret-integration.png"
-url="/images/pipeline/shared-configuration/shared-conf-secret-integration.png"
-alt="Using external secrets in shared configuration values"
-caption="Using external secrets in shared configuration values"
-max-width="50%"
-%}
-
-If you have already specified the resource field during secret definition the just enter on the text field the name of the secret directly, i.e. `my-secret-key`.
-If you didn't include a resource name during secret creation then enter the full name in the field like `my-secret-resource@my-secret-key`.
-
-### Level of access
-
-For each set of values you can toggle the level of access by [non-admin users]({{site.baseurl}}/docs/administration/access-control/#users-and-administrators). If it is off, users will **not** be able to use the [CLI](https://codefresh-io.github.io/cli/) or [API]({{site.baseurl}}/docs/integrations/codefresh-api/)
-to access these [values](https://codefresh-io.github.io/cli/contexts/). If it is on, all users from all your Codefresh teams will be able to access this set of values
-with CLI commands or API calls.
-
-{% include
-image.html
-lightbox="true"
-file="/images/pipeline/shared-configuration/shared-config-access.png"
-url="/images/pipeline/shared-configuration/shared-config-access.png"
-alt="Allow access to non-admin users"
-caption="Allow access to non-admin users"
-max-width="60%"
-%}
-
-We recommend that you disable access for all values of type *shared secret* and *secret YAML* unless your organization has different needs.
-
-
-## Using shared environment variables
-
-Each pipeline has a set of environment variables that can be defined in the *Workflow* screen.
-To import a shared configuration open the pipeline editor, and from the tabs on the right side select *VARIABLES*. Then click the gear icon to *Open Advanced Options*:
-
-{% include
-image.html
-lightbox="true"
-file="/images/pipeline/shared-configuration/environment-variables.png"
-url="/images/pipeline/shared-configuration/environment-variables.png"
-alt="Pipeline environment variables"
-caption="Pipeline environment variables"
-max-width="50%"
-%}
-
-To use your shared configuration, click the *Import from shared configuration* button and select the snippet from the list:
-
-{% include
-image.html
-lightbox="true"
-file="/images/pipeline/shared-configuration/import-variables.png"
-url="/images/pipeline/shared-configuration/import-variables.png"
-alt="Importing shared configuration"
-caption="Importing shared configuration"
-max-width="50%"
-%}
-
-Once you click *Add* the values from the shared configuration will be appended to the ones
-you have in your pipelines. In case of similar values the shared configuration will follow the [precedence rules]({{site.baseurl}}/docs/codefresh-yaml/variables/#user-provided-variables).
-
-
-## Using shared Helm values
-
-To use a shared YAML snippet for Helm values you can install a new Helm chart either from:
-
-* The [Helm chart list]({{site.baseurl}}/docs/new-helm/add-helm-repository/#install-chart-from-your-helm-repository)
-* The [Helm environment board]({{site.baseurl}}/docs/new-helm/helm-environment-promotion/#moving-releases-between-environments).
-
-In both cases, when you see the Helm installation dialog you can import any of your YAML snippets
-to override the default chart values.
-
-{% include
-image.html
-lightbox="true"
-file="/images/pipeline/shared-configuration/helm-import.png"
-url="/images/pipeline/shared-configuration/helm-import.png"
-alt="Importing Helm values"
-caption="Importing Helm values"
-max-width="50%"
-%}
-
-From the same dialog you can also create a brand-new shared configuration snippet of type YAML.
-Not only it will be used for this Helm chart, but it will be added in your global shared configuration as well.
-
-## Using values from the Shared Configuration in your Helm step
-
-Additionally, you can define shared variables in your account settings and reuse those across your Helm steps, and specifically, in your [custom Helm values](https://codefresh.io/docs/docs/new-helm/using-helm-in-codefresh-pipeline/#helm-values).
-
-Under *Account Setting* > *Shared Configuration*, add the variable to your shared configuration.
-
-{% include
-image.html
-lightbox="true"
-file="/images/pipeline/shared-configuration/helm-shared-variables.png"
-url="/images/pipeline/shared-configuration/helm-version-shared.png"
-alt="Adding shared configuration variables"
-caption="Adding shared configuration variables"
-max-width="50%"
-%}
-
-Go to the workflow of the Codefresh pipeline to which you want to add the variable. Then select *variables* from the right sidebar. *Open advanced configuration* and select *Import from shared configuration*.
-
-{% include
-image.html
-lightbox="true"
-file="/images/pipeline/shared-configuration/environment-variables.png"
-url="/images/pipeline/shared-configuration/environment-variables.png"
-alt="Pipeline environment variables"
-caption="Pipeline environment variables"
-max-width="50%"
-%}
-
-This will allow you to add shared variables.
-
-{% include
-image.html
-lightbox="true"
-file="/images/pipeline/shared-configuration/shared-helm-variables.png"
-url="/images/pipeline/shared-configuration/shared-helm-variables.png"
-alt="Shared helm variable"
-caption="Shared helm variable"
-max-width="50%"
-%}
-
-Add the shared variables to your Helm step:
-
-{% highlight shell %}
-{% raw %}
-deploy:
- type: "helm"
- working_directory: "./react-article-display"
- stage: "deploy"
- arguments:
- action: "install"
- chart_name: "charts/example-chart"
- release_name: "test-chart"
- helm_version: "${{HELM_VERSION}}"
- kube_context: "anais-cluster@codefresh-sa"
- custom_values:
- - 'pullPolicy=${{PULL_POLICY}}'
-{% endraw %}
-{% endhighlight %}
-
-The shared variables can now be used across your pipelines.
-
-## Sharing any kind of YAML data in pipelines
-
-All the snippets from shared configuration are also available as context in the [Codefresh CLI](https://codefresh-io.github.io/cli/contexts/)
-
-This means that you can manipulate them programmatically and read their values in the pipeline in any way you see fit.
-
-If for example you have a shared configuration named `my-global-config` you can easily read its contents programmatically using the CLI:
-
-{% highlight shell %}
-$codefresh get context my-global-config --output=yaml
-
-apiVersion: v1
-kind: context
-metadata:
- default: false
- system: false
- name: my-global-config
-type: config
-spec:
- type: config
- data:
- foo: bar
-{% endhighlight %}
-
-### Example - custom value manipulation
-
-Let's say that you have a YAML segment with the following contents:
-
-{% highlight yaml %}
-favorite:
- drink: coffee
- food: pizza
-{% endhighlight %}
-
-Here is a pipeline step that is reading the yaml snippet and extracts a value
-
- `YAML`
-{% highlight yaml %}
-{% raw %}
-version: '1.0'
-steps:
- MyFavoriteFoodStep:
- title: Favorite food
- image: codefresh/cli
- commands:
- - echo I love eating $(codefresh get context my-food-values --output=json | jq -r '.spec.data.favorite.food')
-{% endraw %}
-{% endhighlight %}
-
-Once the pipeline runs, you will see in the logs:
-
-```
-I love eating pizza
-```
-
-## Manipulating shared configuration programmatically
-
-You can also create/update/delete shared configuration via the [Codefresh CLI](https://codefresh-io.github.io/cli/) or [API]({{site.baseurl}}/docs/integrations/codefresh-api/).
-
-See the [context section](https://codefresh-io.github.io/cli/contexts/create-context/) in the CLI documentation.
-
-
-
-## What to read next
-
-* [Variables]({{site.baseurl}}/docs/codefresh-yaml/variables/)
-* [Codefresh YAML]({{site.baseurl}}/docs/codefresh-yaml/what-is-the-codefresh-yaml/)
-* [Pipeline steps]({{site.baseurl}}/docs/codefresh-yaml/steps/)
-
diff --git a/_docs/configure-ci-cd-pipeline/triggers.md b/_docs/configure-ci-cd-pipeline/triggers.md
deleted file mode 100644
index 5494ef3a3..000000000
--- a/_docs/configure-ci-cd-pipeline/triggers.md
+++ /dev/null
@@ -1,121 +0,0 @@
----
-title: "Pipeline Triggers"
-description: "Choose when your pipelines should run"
-group: configure-ci-cd-pipeline
-redirect_from:
- - /docs/pipeline-triggers/
- - /docs/pipeline-triggers/introduction-triggers/
-toc: true
----
-
-
-To create an effective CI/CD process, it should be possible to trigger Codefresh pipelines not only on code repository events (like `push` or `PR`), but also on any "interesting" CD-related event, coming from some external system.
-
-Codefresh not only allows you to define different pipelines on a single project but also offers you the capability to trigger them with completely separate mechanisms. You can even skip triggering a pipeline by including predefined flags in the commit message.
-
-
-## Codefresh Trigger Types
-
-Trigger types currently supported by Codefresh are:
-
-* [Git Triggers](git-triggers)
-* [Dockerhub Triggers](dockerhub-triggers)
-* [Azure Registry Triggers](azure-triggers)
-* [Quay Triggers](quay-triggers)
-* [Helm Triggers](helm-triggers)
-* [Artifactory Triggers](jfrog-triggers)
-* [Cron Trigger](cron-triggers)
-* [API/CLI Trigger]({{site.baseurl}}/docs/integrations/codefresh-api/)
-
-As an example, this project contains 4 pipelines:
-
-{% include image.html
-lightbox="true"
-file="/images/pipeline/triggers/pipeline-examples.png"
-url="/images/pipeline/triggers/pipeline-examples.png"
-alt="Sample pipelines"
-caption="Sample pipelines"
-max-width="70%"
-%}
-
-Behind the scenes these pipelines are triggered from different events:
-
-* Pipeline "CI-build" is using a GIT trigger and starts after every commit to the code repository
-* Pipeline "Sonarcloud" is executed every weekend using a cron (timed) trigger
-* Pipeline "integration-test" is executed whenever a commit happens in a Pull request on the code
-* Pipeline "deploy-prod-k8s" is executed whenever a Docker image is pushed to the Docker registry
-
-This is just an example. You are free to create your own triggers that match your own internal process.
-It is also possible to add multiple triggers for a pipeline so that it is executed for more than one type of events.
-
-If a pipeline has no defined trigger you can still start it manually.
-
-For all trigger types you can also use the [Codefresh CLI](https://codefresh-io.github.io/cli/triggers/) to manage them.
-
-
-
-## Creating a new trigger for a pipeline
-
-By default, when you create a new project from a GIT provider it will start with a GIT trigger that runs on every commit.
-
-{% include image.html
-lightbox="true"
-file="/images/pipeline/triggers/default-git-trigger.png"
-url="/images/pipeline/triggers/default-git-trigger.png"
-alt="Default GIT Trigger"
-caption="Default GIT Trigger"
-max-width="50%"
-%}
-
-You can either delete this trigger, modify it, or add new ones.
-
-To add a new trigger, go to the *Triggers* tab in your pipeline editor and click the *Add Trigger* button. This will bring up the respective dialog where you are adding a new trigger.
-
-{% include image.html
-lightbox="true"
-file="/images/pipeline/triggers/add-trigger-dialog.png"
-url="/images/pipeline/triggers/add-trigger-dialog.png"
-alt="Adding new Trigger dialog"
-caption="Adding new Trigger dialog"
-max-width="70%"
-%}
-
-For more information see:
-
-* [Git Triggers](git-triggers)
-* [Dockerhub Triggers](dockerhub-triggers)
-* [Azure Registry Triggers](azure-triggers)
-* [Quay Triggers](quay-triggers)
-* [Helm Triggers](helm-triggers)
-* [Artifactory Triggers](jfrog-triggers)
-* [Cron Trigger](cron-triggers)
-
-## Disabling triggers
-
-You can easily disable a trigger manually if you don't want to be active anymore.
-On the triggers tab click the gear icon on the top right (*Open advanced options*).
-
-
-
-{% include image.html
-lightbox="true"
-file="/images/pipeline/triggers/enable-triggers.png"
-url="/images/pipeline/triggers/enable-triggers.png"
-alt="Toggle a trigger on/off"
-caption="Toggle a trigger on/off"
-max-width="70%"
-%}
-
-
-Then click the toggle switch on each trigger that you want to enable/disable. You can later enable the same trigger again
-by clicking the same switch.
-
->For Git triggers, you can also skip triggering the pipeline without disabling the trigger by adding a predefined string to the commit message. See [Skip triggering pipeline on commit]({{site.baseurl}}/docs/configure-ci-cd-pipeline/triggers/git-triggers/#skip-triggering-pipeline-on-commit).
-
-
-## What to read next
-
-* [Creating pipelines]({{site.baseurl}}/docs/configure-ci-cd-pipeline/pipelines/)
-* [Git triggers](git-triggers)
-* [Running pipelines locally]({{site.baseurl}}/docs/configure-ci-cd-pipeline/running-pipelines-locally/)
-* [Trigger a Kubernetes Deployment from a Dockerhub Push Event]({{site.baseurl}}/docs//yaml-examples/examples/trigger-a-k8s-deployment-from-docker-registry/)
diff --git a/_docs/configure-ci-cd-pipeline/triggers/azure-triggers.md b/_docs/configure-ci-cd-pipeline/triggers/azure-triggers.md
deleted file mode 100644
index f80f971c7..000000000
--- a/_docs/configure-ci-cd-pipeline/triggers/azure-triggers.md
+++ /dev/null
@@ -1,85 +0,0 @@
----
-title: "Azure Registry Trigger"
-description: "Learn how to trigger Codefresh pipelines from Azure Registry events"
-group: configure-ci-cd-pipeline
-sub_group: triggers
-redirect_from:
- - /docs/pipeline-triggers/configure-azure-trigger/
-toc: true
----
-
-It is possible to define and manage Azure Registry Pipeline triggers with the Codefresh UI.
-
-This allows you to trigger Codefresh pipelines when an Azure Registry event happens (e.g. a new Docker image is uploaded).
-
-## Manage Azure Triggers with Codefresh UI
-
-
-The process involves two parts:
-
-1. Creating a trigger in Codefresh. This will result in a special Codefresh webhook URL
-1. Creating a new notification in the Azure Registry that will use this URL to call Codefresh
-
-Make sure that you have an Azure cloud account and have already [created a registry](https://docs.microsoft.com/en-us/azure/container-registry/).
-
-
-### Create a new Azure Trigger
-
-To add a new Azure trigger, navigate to a Codefresh Pipeline *Configuration* view and expand the *Triggers* section. Press the `Add Trigger` button and select a `Registry` trigger type to add.
-
-{% include image.html
-lightbox="true"
-file="/images/pipeline/triggers/add-trigger-dialog.png"
-url="/images/pipeline/triggers/add-trigger-dialog.png"
-alt="Adding new Trigger dialog"
-max-width="40%"
-%}
-
-Fill the following information:
-
-* Registry Provider - select `Azure`.
-* *Name of Registry* - put Azure name of registry (without `.azurecr.io`).
-* *Image Repository Name* - Azure image repository name.
-* *Action* - select `Push Image` action.
-* *Tags* - optional filter to specify which image *tags* will trigger pipeline execution: [Re2](https://github.com/google/re2/wiki/Syntax) regular expression.
-
-{% include image.html
-lightbox="true"
-file="/images/pipeline/triggers/azure/add-trigger-dialog.png"
-url="/images/pipeline/triggers/azure/add-trigger-dialog.png"
-alt="Azure Registry settings"
-max-width="50%"
-%}
-
-Click next and a new Dialog will appear that shows you the Codefresh webhook URL. Copy it to your clipboard.
-
-
-{% include image.html
-lightbox="true"
-file="/images/pipeline/triggers/azure/view-trigger-dialog.png"
-url="/images/pipeline/triggers/azure/view-trigger-dialog.png"
-alt="Codefresh webhook URL"
-max-width="50%"
-%}
-
-Now we must set Azure to call this URL when an event takes place.
-
-### Setup Azure Notification
-
-The easiest way to create an Azure trigger is with the [Azure CLI](https://docs.microsoft.com/en-us/cli/azure/acr/webhook?view=azure-cli-latest#az-acr-webhook-create) (Also available in the Azure portal)
-
-Here is the command
-
-{% highlight shell %}
-{% raw %}
-az acr webhook create -n MyWebhook -r kostisregistry --uri "https://g.codefresh.io/nomios/azure?account=409f15bdd444&secret=7zyg5Zhb8xYBn4ms" --actions push delete
-{% endraw %}
-{% endhighlight %}
-
-The name can be anything you want. The URI is the Codefresh URL that was created in the previous step.
-
-
-### Triggering a Codefresh pipeline with Azure push
-
-Now, every time you push a new Docker image to the selected Azure Docker repository, manually, with Codefresh or any other CI/CD tool, Codefresh will trigger execution of all pipelines associated with that Azure Push trigger event.
-
diff --git a/_docs/configure-ci-cd-pipeline/triggers/dockerhub-triggers.md b/_docs/configure-ci-cd-pipeline/triggers/dockerhub-triggers.md
deleted file mode 100644
index 71dda94a7..000000000
--- a/_docs/configure-ci-cd-pipeline/triggers/dockerhub-triggers.md
+++ /dev/null
@@ -1,149 +0,0 @@
----
-title: "DockerHub Trigger"
-description: ""
-group: configure-ci-cd-pipeline
-sub_group: triggers
-redirect_from:
- - /docs/configure-dockerhub-trigger/
- - /docs/pipeline-triggers/configure-dockerhub-trigger/
-toc: true
----
-
-## Manage DockerHub Triggers with Codefresh UI
-
-It is possible to define and manage DockerHub pipeline triggers with Codefresh UI.
-
-### Create a new DockerHub Trigger
-
-To add a new DockerHub trigger, navigate to Codefresh Pipeline *Configuration* view and expand *Triggers* section. Press the `Add Trigger` button and select a `Registry` trigger type to add.
-
-{% include image.html
-lightbox="true"
-file="/images/pipeline/triggers/add-trigger-dialog.png"
-url="/images/pipeline/triggers/add-trigger-dialog.png"
-alt="Adding new Trigger dialog"
-max-width="60%"
-%}
-
-Fill the following information:
-
-* *Registry Provider* - select `DockerHub`.
-* *User/Organization Name* - put DockerHub user name or organization name here.
-* *Image Repository Name* - DockerHub image repository name.
-* *Action* - select `Push Image` action.
-* *Tag* - optional filter to specify which image *tags* will trigger pipeline execution: [Re2](https://github.com/google/re2/wiki/Syntax) regular expression.
-
-{% include image.html
-lightbox="true"
-file="/images/pipeline/triggers/dockerhub/dockerhub_trigger_1.png"
-url="/images/pipeline/triggers/dockerhub/dockerhub_trigger_1.png"
-alt="Add Registry Trigger"
-max-width="70%"
-%}
-
-### Setup DockerHub Webhook
-
-Currently Codefresh does not support to automatically setup a DockerHub webhook. You need to do this manually. Press the *Next* button and see detailed instructions with URL links and secrets of how-to setup a DockerHub Webhook.
-
-
-{% include image.html
-lightbox="true"
-file="/images/pipeline/triggers/dockerhub/dockerhub_trigger_2.png"
-url="/images/pipeline/triggers/dockerhub/dockerhub_trigger_2.png"
-alt="Add Webhook"
-max-width="70%"
-%}
-
-1. Copy `Endpoint` URL
-1. Visit DockerHub image settings page following link in help
-1. Add a new DockerHub Webhook with previously copied `Endpoint` URL
-
-### Triggering Codefresh pipeline with DockerHub push
-
-Now, every time you push a new Docker image to selected DockerHub repository, manually, with Codefresh or any other CI/CD tool, Codefresh will trigger execution of all pipelines associated with this DockerHub Push trigger event.
-
-## Manage DockerHub Triggers with Codefresh CLI
-
-It is possible to use `codefresh` command line client (`CLI`) to manage DockerHub pipeline triggers.
-
-### Docker Hub Trigger
-
-It is possible to trigger a Codefresh CD pipeline(s) when a new Docker image pushed into DockerHub.
-
-You can use [Codefresh CLI](https://cli.codefresh.io/) to setup a Codefresh trigger for DockerHub.
-
-#### Create DockerHub trigger-event
-
-First, create a `trigger-event` for every DockerHub image, you would like to setup a Codefresh trigger.
-
-```sh
-# create DockerHub trigger event for codefresh/fortune
-codefresh create trigger-event --type registry --kind dockerhub --value namespace=codefresh --value name=fortune --value action=push
-
-# on success trigger-event UID will be printed out
-Trigger event: registry:dockerhub:codefresh:fortune:push:107e9db97062 was successfully created.
-```
-
-#### Setup DockerHub Webhook
-
-Currently, an additional manual work is required to bind DockerHub `push` image event to the Codefresh `trigger-event`.
-
-```sh
-# get trigger-event details for previously created trigger-event
-codefresh get trigger-event -o yaml registry:dockerhub:codefresh:fortune:push:107e9db97062
-```
-
-... command output:
-
-```yaml
-uri: 'registry:dockerhub:codefresh:fortune:push:107e9db97062'
-type: registry
-kind: dockerhub
-public: false
-secret: aGao5weuez2G6WF9
-status: active
-endpoint: >-
- https://g.codefresh.io/nomios/dockerhub?account=107e9db97062&secret=aGao5weuez2G6WF9
-description: Docker Hub codefresh/fortune push event
-help: >-
- Docker Hub webhooks fire when an image is built in, pushed or a new tag is
- added to, your repository.
-
-
- Configure Docker Hub webhooks on
- https://hub.docker.com/r/codefresh/fortune/~/settings/webhooks/
-
-
- Add following Codefresh Docker Hub webhook endpoint
- https://g.codefresh.io/nomios/dockerhub?account=107e9db97062&secret=aGao5weuez2G6WF9
-```
-
-1. Copy `endpoint` URL
-1. Visit DockerHub settings page [https://hub.docker.com/r/codefresh/fortune/~/settings/webhooks/](https://hub.docker.com/r/codefresh/fortune/~/settings/webhooks/)
-1. Add a new Webhook with previously copied `endpoint` URL
-
-
-#### Setup pipeline trigger
-
-Now, lets setup a new pipeline trigger, linking previously defined DockerHub push `codefresh/fortune` `trigger-event` to one ore more Codefresh pipelines.
-
-```sh
-# create trigger, linking trigger-event UID to the pipeline UID
-codefresh create trigger "registry:dockerhub:codefresh:fortune:push:107e9db97062" 7a5622e4b1ad5ba0018a3c9c
-
-# create another trigger, linking the same trigger-event to another pipeline
-codefresh create trigger "registry:dockerhub:codefresh:fortune:push:107e9db97062" 4a5634e4b2cd6baf021a3c0a
-```
-
-From now on, Codefresh will trigger pipeline execution when new `codefresh/fortune` image is pushed to the DockerHub.
-
-#### DockerHub Event payload
-
-The following variables will be available for any Codefresh pipeline linked to a DockerHub `trigger-event`:
-
-- `EVENT_NAMESPACE` - DockerHub namespace (alias `organization`).
-- `EVENT_NAME` - DockerHub image name (alias `repository`).
-- `EVENT_TAG` - Docker image tag.
-- `EVENT_PUSHER` - user who pushed this Docker image.
-- `EVENT_PUSHED_AT` - timestamp for push event.
-- `EVENT_PAYLOAD` - original DockerHub Webhook JSON payload.
diff --git a/_docs/configure-ci-cd-pipeline/triggers/helm-triggers.md b/_docs/configure-ci-cd-pipeline/triggers/helm-triggers.md
deleted file mode 100644
index a29563730..000000000
--- a/_docs/configure-ci-cd-pipeline/triggers/helm-triggers.md
+++ /dev/null
@@ -1,62 +0,0 @@
----
-title: "Helm Trigger"
-description: ""
-group: configure-ci-cd-pipeline
-sub_group: triggers
-toc: true
----
-
-Codefresh has the option to create pipelines that respond to Helm events. For instance, one pipeline can be set-up to create a Docker image and chart. Once those are created, another pipeline will be triggered that will take over the actual deployment.
-
-## Manage Helm Triggers with Codefresh UI
-
-It is possible to define and manage Helm pipeline triggers with the Codefresh UI.
-
-### Create a new Helm Trigger
-
-To add a new Helm trigger, navigate to Codefresh Pipeline *Configuration* view and expand *Triggers* section. Press the `Add Trigger` button and select the `Helm` trigger type to add.
-
-{% include image.html
-lightbox="true"
-file="/images/pipeline/triggers/add-trigger-dialog.png"
-url="/images/pipeline/triggers/add-trigger-dialog.png"
-alt="Adding new Trigger dialog"
-max-width="60%"
-%}
-
-Fill the following information:
-* *Helm Provider* - select `JFrog Artifactory`.
-* *Repository* - put JFrog name of the Artifactory repository.
-* *Chart Name* - put name of the chart in the Artifactory repository.
-* *Action* - select `Push Chart` action.
-
-{% include image.html
-lightbox="true"
-file="/images/pipeline/triggers/jfrog/configure-artifactory.png"
-url="/images/pipeline/triggers/jfrog/configure-artifactory.png"
-alt="Helm Artifactory settings"
-max-width="50%"
-%}
-
-Click next and a new Dialog will appear that shows you the Codefresh webhook URL. Copy it to your clipboard.
-
-
-{% include image.html
-lightbox="true"
-file="/images/pipeline/triggers/jfrog/view-trigger-dialog.png"
-url="/images/pipeline/triggers/jfrog/view-trigger-dialog.png"
-alt="Codefresh webhook URL"
-max-width="50%"
-%}
-
-Now we must set JFrog Artifactory to call this URL when an event takes place. This can either be done through the [JFrog Artifactory webhook plugin](https://codefresh.io/docs/docs/configure-ci-cd-pipeline/triggers/jfrog-triggers/) or through [setting up Webhooks](https://www.jfrog.com/confluence/display/JFROG/Webhooks) in the UI.
-
-### Triggering a Codefresh pipeline with an Artifactory push
-
-Now, every time you push a Helm chart to the selected Artifactory repository, manually, with Codefresh or any other CI/CD tool, Codefresh will trigger execution of all pipelines associated with that Artifactory Push trigger event.
-
-## What to read next
-
-* [Git triggers](https://codefresh.io/docs/docs/configure-ci-cd-pipeline/triggers/git-triggers/)
-* [Helm Releases management](https://codefresh.io/docs/docs/new-helm/helm-releases-management/)
-* [Custom Helm uploads](https://codefresh.io/docs/docs/new-helm/custom-helm-uploads/)
\ No newline at end of file
diff --git a/_docs/configure-ci-cd-pipeline/triggers/jfrog-triggers.md b/_docs/configure-ci-cd-pipeline/triggers/jfrog-triggers.md
deleted file mode 100644
index 4a86b5037..000000000
--- a/_docs/configure-ci-cd-pipeline/triggers/jfrog-triggers.md
+++ /dev/null
@@ -1,98 +0,0 @@
----
-title: "Artifactory Trigger"
-description: "How to trigger Codefresh pipelines from Artifactory"
-group: configure-ci-cd-pipeline
-sub_group: triggers
-redirect_from:
- - /docs/pipeline-triggers/configure-jfrog-trigger/
-toc: true
----
-
-It is possible to define and manage Artifactory pipeline triggers with the Codefresh UI.
-This allows you to trigger Codefresh pipelines when a Artifactory event happens (i.e. a new Docker image is uploaded).
-
-## Manage Artifactory Triggers with Codefresh UI
-
-
-The process involves two parts:
-
-1. Creating a trigger in Codefresh. This will result in a special Codefresh webhook URL
-1. Activating the [webhook plugin](https://github.com/jfrog/artifactory-user-plugins/tree/master/webhook) in Artifactory and setting it up to call the Codefresh URL
-
-Make sure that you have admin access to your Artifactory instance in order to setup its webhook plugin.
-
-### Create a new Artifactory Trigger
-
-To add a new Artifactory trigger, navigate to a Codefresh Pipeline *Configuration* view and expand the *Triggers* section. Press the `Add Trigger` button and select a `Registry` trigger type to add.
-
-{% include image.html
-lightbox="true"
-file="/images/pipeline/triggers/add-trigger-dialog.png"
-url="/images/pipeline/triggers/add-trigger-dialog.png"
-alt="Adding new Trigger dialog"
-max-width="40%"
-%}
-
-Fill the following information:
-
-* *Registry Provider* - select `JFrog`.
-* *Repository Name* - put JFrog name of repository.
-* *Docker Image Name* - put name of Docker image.
-* *Action* - select `Push Image` action.
-* *Tag* - optional filter to specify which image *tags* will trigger pipeline execution: [Re2](https://github.com/google/re2/wiki/Syntax) regular expression.
-
-{% include image.html
-lightbox="true"
-file="/images/pipeline/triggers/jfrog/configure-trigger.png"
-url="/images/pipeline/triggers/jfrog/configure-trigger.png"
-alt="Artifactory Registry settings"
-max-width="50%"
-%}
-
-Click next and a new Dialog will appear that shows you the Codefresh webhook URL. Copy it to your clipboard.
-
-
-{% include image.html
-lightbox="true"
-file="/images/pipeline/triggers/jfrog/view-trigger-dialog.png"
-url="/images/pipeline/triggers/jfrog/view-trigger-dialog.png"
-alt="Codefresh webhook URL"
-max-width="50%"
-%}
-
-Now we must set JFrog Artifactory to call this URL when an event takes place.
-
-### Setup JFrog Artifactory webhook plugin
-
-The [webhook functionality](https://github.com/jfrog/artifactory-user-plugins/tree/master/webhook) in JFrog artifactory comes in plugin.
-You can read [detailed documentation](https://www.jfrog.com/confluence/display/RTF/User+Plugins) for JFrog plugins but in summary:
-
-* The file `webhook.groovy` needs to be copied to `ARTIFACTORY_HOME/etc/plugins` (the plugin itself)
-* A file `webhook.config.json` should also be placed in the same folder (the plugin setup)
-
-Here is an example for Codefresh.
-
-`webhook.config.json`
-{% highlight json %}
-{% raw %}
-{
- "webhooks": {
- "mywebhook": {
- "url": "https://g.codefresh.io/nomios/jfrog?account=2dfdf89f235bfe&sefgt=EvQf9bBS55UPekCu",
- "events": [
- "docker.tagCreated"
- ]
- }
- },
- "debug": false,
- "timeout": 15000
-}
-{% endraw %}
-{% endhighlight %}
-
-
-
-### Triggering a Codefresh pipeline with an Artifactory push
-
-Now, every time you push/tag a Docker image to the selected Artifactory repository, manually, with Codefresh or any other CI/CD tool, Codefresh will trigger execution of all pipelines associated with that Artifactory Push trigger event.
-
diff --git a/_docs/dashboards/dora-metrics.md b/_docs/dashboards/dora-metrics.md
new file mode 100644
index 000000000..a4bf9e13b
--- /dev/null
+++ b/_docs/dashboards/dora-metrics.md
@@ -0,0 +1,97 @@
+---
+title: "DORA metrics"
+description: "Get insights into your deployments"
+group: dashboards
+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 optimize your workflows at technical or organizational levels.
+Codefresh offers support for DORA metrics out of the box.
+
+* In the Codefresh UI, from Artifacts & Insights in the sidebar, select [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 multiselect.
+More than one option within the same filter type has an OR relationship. Multiple filter types 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/deployments/gitops/applications-dashboard/#applications-dashboard-information) in the Applications dashboard, clicking {::nomarkdown}{:/} in DORA metrics, displays DORA 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 are key to performance insights with DORA metrics. The metrics are 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
+
+>Tip:
+ Remember that the graphs for the DORA metrics reflect metrics of application deployments, not workflows.
+
+### Deployment Frequency
+ The frequency at which applications are deployed to production, including both successful (Healthy) and failed (Degraded), deployments. A deployment is considered an Argo CD sync where there was a change in the application source code that resulted in a new deployment of the application to production.
+
+ The X-axis charts the time based on the granularity selected, and the Y-axis charts the number of deployments. The number shown on the top right is the average deployment frequency based on granularity.
+
+### Lead Time for Changes
+ The average number of days from the first commit for a PR (pull request) until the deployment date for the same PR. The key term here is _deployment_. Lead Time for Changes considers only those changes to workflows that result in a deployment. Making a change to a repo that does not result in a deployment is not included when calculating Lead Time for Changes.
+
+ The X-axis charts the time based on the granularity selected, 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.
+
+### Change Failure Rate
+ The failure or rollback rate in percentage for applications whose health status changed to Degraded on deployment. The key term here is _on deployment_. For example, bumping an image tag with one that does not exist, results in the application being Degraded on deployment, and designated as failed.
+
+
+ The Change Failure Rate is derived by dividing the number of Degraded (failed/rollback) deployments with the total number of deployments.
+ The X-axis charts the time based on the granularity selected, 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.
+
+### Time to Restore Service
+ The average number of hours taken for the status of Degraded deployments to return to Healthy. Again, similar to the Change Failure Rate, Time to Restore Service includes only deployments that became Degraded. It is derived by dividing the total number of hours for all Degraded deployments to return to Healthy by the total number of Degraded deployments.
+
+ 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.
+
+## Related articles
+[GitOps Overview dashboard]({{site.baseurl}}/docs/dashboards/home-dashboard)
+[Monitoring applications]({{site.baseurl}}/docs/deployments/gitops/applications-dashboard/)
+
diff --git a/_docs/dashboards/home-dashboard.md b/_docs/dashboards/home-dashboard.md
new file mode 100644
index 000000000..ba618ab85
--- /dev/null
+++ b/_docs/dashboards/home-dashboard.md
@@ -0,0 +1,118 @@
+---
+title: "GitOps Overview dashboard"
+description: ""
+group: dashboards
+toc: true
+---
+
+Get a global picture of runtimes, managed clusters, deployments, and applications in the GitOps Overview dashboard. Get system-wide visualization in real-time for GitOps.
+
+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/gitops-overview-dashboard.png"
+ url="/images/reporting/gitops-overview-dashboard.png"
+ alt="GitOps Overview dashboard: Global enterprise analytics for GitOps"
+ caption="GitOps Overview dashboard: Global enterprise analytics for GitOps"
+ max-width="70%"
+ %}
+
+### Global filters
+Filter the view in the GitOps Overview dashboard by runtimes and date range.
+
+{% include
+ image.html
+ lightbox="true"
+ file="/images/reporting/global-filters.png"
+ url="/images/reporting/global-filters.png"
+ alt="GitOps Overview dashboard: Global filters"
+ caption="GitOps Overview 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 GitOps Overview dashboard"
+ caption="Runtimes and Managed Clusters in the GitOps Overview dashboard"
+ max-width="80%"
+ %}
+
+{: .table .table-bordered .table-hover}
+| Item | Description |
+| ------------------------| ---------------- |
+|**Runtimes** | Identify failed runtimes.|
+|**Managed Clusters** |{::nomarkdown}
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.
{:/}|
+
+
+### Deployments
+
+Identify trends for deployments.
+
+
+
+ {% include
+ image.html
+ lightbox="true"
+ file="/images/reporting/deployments-widget.png"
+ url="/images/reporting/deployments-widget.png"
+ alt="Deployments in the GitOps Overview dashboard"
+ caption="Deployments in the GitOps Overview dashboard"
+ max-width="70%"
+ %}
+
+{: .table .table-bordered .table-hover}
+| Item | Description |
+| ------------------------| ---------------- |
+|**Daily/Weekly/Monthly** | Granularity for deployment views that affects the average number of deployments and the comparison to the reference period.|
+|**Number and Comparison Average** | The number on the top right is the number of successful/failed/rollback deployments for the selected granularity. The percentage is the comparison to the reference period, also for the selected granularity. |
+|**Successful** | The number of successful deployments per day, week, or month according to the selected granularity. |
+|**Failed Deployments** | The number of successful deployments per day, week, or month according to the selected granularity. |
+|**Rollbacks** | The number of successful deployments per day, week, or month according to the selected granularity. |
+
+
+
+### Applications
+
+Displays up to five of the most active applications and their current deployment status.
+
+{% include
+ image.html
+ lightbox="true"
+ file="/images/reporting/applications-widget.png"
+ url="/images/reporting/applications-widget.png"
+ alt="Applications in the GitOps Overview dashboard"
+ caption="Applications in the GitOps Overview dashboard"
+ max-width="70%"
+ %}
+
+{: .table .table-bordered .table-hover}
+
+| Item | Description |
+| ------------------------| ---------------- |
+|**Filter** | Filter applications by the cluster on which they are deployed. |
+|**View** | Click to go to the Applications dashboard. See |
+|**Application Name** | The name of the application, and the names of the runtime and cluster on which it is deployed. Click the name to drill down into the application in the Applications dashboard. |
+|**Health status** | The health status of the application, and can be either:{::nomarkdown}
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.
To see the breakdown by health status, mouse over the chart. 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. {:/} |
+
+
+
+
+
+### Related articles
+[DORA metrics]({{site.baseurl}}/docs/dashboards/dora-metrics/)
+[Monitoring applications]({{site.baseurl}}/docs/deployments/gitops/applications-dashboard/)
+[Images in Codefresh]({{site.baseurl}}/docs/dashboards/images/)
+
+
diff --git a/_docs/dashboards/images.md b/_docs/dashboards/images.md
new file mode 100644
index 000000000..cf0acab1f
--- /dev/null
+++ b/_docs/dashboards/images.md
@@ -0,0 +1,143 @@
+---
+title: "Images in Codefresh"
+description: ""
+group: deployments
+sub_group: gitops
+toc: true
+---
+
+Images from connected registries are displayed in a
+
+
+## Access the Images dashboard
+
+
+* In the Codefresh UI, from Artifacts in the sidebar, select [Images](https://g.codefresh.io/2.0/images){:target="\_blank"}.
+
+
+
+Image views to show multiple levels of data:
+
+1. Repository and application deployment
+1. Tags
+1. Summary with metadata and binary information
+1. Dockerfile info
+1. Layers
+
+## Filters for Image views
+As with any resource in Codefresh, the Images dashboard supports filters that allow you focus on the data that's important to you.
+Most image filters support multi-selection. Unless otherwise indicated, the filters are common to all view levels.
+
+{: .table .table-bordered .table-hover}
+| Filter | Description|
+| -------------- | -------------- |
+| **Repository Names** | The Git repository or repositories that contain the image. |
+| **Tag** | The tag by which to filter. |
+| **Registry Types** | The registry which stores your image. To filter by registries that are not listed, select **Other types**.|
+| **Deployed in application**| The application or applications in which the image is currently deployed.|
+| **Currently Deployed**| When enabled, displays only images that are currently deployed in applications. |
+| **Sorted by** | List images by **Name**, or by the most recent update, **Last update**.
+| **Git branch** | Available in **More filters**. The Git branch to which the image is pushed.|
+| **Git repositories** | Available in **More filters**. The Git provider you use.|
+
+Currently Deployed
+
+## Image main view: deployment and repo information
+The main view of the Images dashboard displays high-level deployment, repository, and registry information.
+
+
+{% include
+ image.html
+ lightbox="true"
+ file="/images/image/images-main-view.png"
+ url="/images/image/images-main-view.png"
+ alt="Images in Codefresh"
+ caption="Images in Codefresh"
+ max-width="60%"
+ %}
+
+
+For each image, you can see:
+* The name of the image. Clicking the image name
+* The application or list of applications in which the image is currently deployed. Clicking an application takes you to the GitOps Apps dashboard with detailed information on the application.|
+* Binary information from Git, including the most recent commit, creation date, size, and tag.
+* The registry to which the image is pushed, and from which it is distributed.
+
+The Currently Deployed stamp on the right shows the number of applications in which the image is deployed.
+
+
+## Image tag view
+Drilldown on the repository shows all the tags created for the image.
+{% include
+ image.html
+ lightbox="true"
+ file="/images/image/image-drill-down-view.png"
+ url="/images/image/image-drill-down-view.png"
+ alt="Image tag info"
+ caption="Image tag info"
+ max-width="60%"
+ %}
+
+Each row displays information on the tag:
+
+* The comment describing the commit or change, with the name of the Git provider and the corresponding PR. To view details of the commit changes in the Git repository, select the commit text.|
+* The hash of the Docker image, generated as sha256. A change in the digest indicates that something has changed in the image.|
+* The registry to which the image is pushed, and from which it is distributed.|
+* The OS and architecture in which the image was created. The date and time of the most recent update is in the local time zone|
+* The date and time of the most recent update.
+* The size of the tag.
+
+> For Summary, Dockerfile, and Layer information on a tag, click **more details**.
+
+## Image Summary
+The Summary view summarizes the metadata for the image.
+
+
+
+{% include
+ image.html
+ lightbox="true"
+ file="/images/image/images-summary-tab.png"
+ url="/images/image/images-summary-tab.png"
+ alt="Image Summary tab"
+ caption="Image Summary tab"
+ max-width="60%"
+ %}
+
+
+* **Image info**: The image name, registry, OS architecture, and last update.
+* **Applications** : The application or applications in which the image is deployed.
+* **Build Info**: The size of the image, and the Argo Workflow for the image step. Click the link to go to the Argo Workflow.
+* **Issues**: The Jira issue number and the committer, enriched with the commit message and its status.
+* **Git**: The Git details for this image tag, such as repo, branch, commit message, committer(s) and Pull Request information.
+* **Annotations**: Annotations if any assigned to the image.
+
+## Image Dockerfile
+
+
+{% include
+ image.html
+ lightbox="true"
+ file="/images/image/images-dockerfile-tab.png"
+ url="/images/image/images-dockerfile-tab.png"
+ alt="Image Dockerfile tab"
+ caption="Image Dockerfile tab"
+ max-width="60%"
+ %}
+
+## Image Layers
+
+
+{% include
+ image.html
+ lightbox="true"
+ file="/images/image/images-layers-tab.png"
+ url="/images/image/images-layers-tab.png"
+ alt="Image Layers tab"
+ caption="Image Layers tab"
+ max-width="60%"
+ %}
+
+## Related articles
+[Image enrichment for GitOps with integrations]({{site.baseurl}}/docs/ci-cd-guides/image-enrichment/)
+[GitOps Overview dashboard]({{site.baseurl}}/docs/dashboards/home-dashboard/)
diff --git a/_docs/deploy-to-kubernetes/access-docker-registry-from-kubernetes.md b/_docs/deploy-to-kubernetes/access-docker-registry-from-kubernetes.md
deleted file mode 100644
index 145009bf5..000000000
--- a/_docs/deploy-to-kubernetes/access-docker-registry-from-kubernetes.md
+++ /dev/null
@@ -1,136 +0,0 @@
----
-title: "Accessing a Docker registry from your Kubernetes cluster"
-description: "Allowing Kubernetes to pull Docker images from your registry"
-group: deploy-to-kubernetes
-redirect_from:
- - /docs/access-codefresh-docker-registry-from-kubernetes/
- - /docs/deploy-to-kubernetes/deploy-to-kubernetes/create-image-pull-secret/
- - /docs/deploy-to-kubernetes/access-codefresh-docker-registry-from-kubernetes/
-toc: true
----
-
-Kubernetes deployments are based on a "pull" approach. When you deploy your application to a Kubernetes
-cluster you don't upload the application itself (which usually happens with traditional deployments). Instead,
-Kubernetes will pull the Docker images to its nodes on its own.
-
-
- {% include
-image.html
-lightbox="true"
-file="/images/getting-started/quick-start-k8s/overview.png"
-url="/images/getting-started/quick-start-k8s/overview.png"
-alt="Kubernetes deployments"
-caption="Kubernetes deployments"
-max-width="80%"
-%}
-
-If your Docker images are in a public repository such as DockerHub, Kubernetes can pull them right away. In most cases
-however your images are in a private Docker registry and Kubernetes must be given explicit access to it.
-
-This happens by using [Docker registry secrets](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/). This way each Kubernetes pod can pull Docker images directly when a deployment takes place.
-
-## Giving access to a Docker Registry via the GUI
-
-Codefresh allows you to create easily pull secrets for your cluster. The first step is to define your Docker registry
-inside Codefresh. It is important to know that Codefresh can work with any [compliant Docker registry]({{site.baseurl}}/docs/docker-registries/external-docker-registries/) either on the cloud or behing the firewall.
-
-Once your Registry is connected to Codefresh, select *Kubernetes* from the left sidebar to view your Kubernetes Dashboard. Then click
-the *Add Service* Button.
-
-At the screen that will appear select your cluster and your namespace at the top. Then at the bottom select the *Image Pull secret* dropdown.
-
- {% include
-image.html
-lightbox="true"
-file="/images/kubernetes/create-secret.png"
-url="/images/kubernetes/create-secret.png"
-alt="Create Pull Secret"
-caption="Create Pull Secret"
-max-width="80%"
-%}
-
-This dropdown shows all the existing pull secrets for that namespace. You can select the *Create Registry Pull secret* Option to create a new one.
-
-You will get a list of all the connected Docker registries in Codefresh. Select the one that you like and Codefresh will
-automatically create a secret for you.
-
->The creation of the secret is instant and will happen as soon as you select your Docker registry from the drop down. There is no need to actually deploy anything from this screen for the changes to take effect.
-
- {% include
-image.html
-lightbox="true"
-file="/images/kubernetes/secret-dropdown.png"
-url="/images/kubernetes/secret-dropdown.png"
-alt="Docker Registry Access"
-caption="Docker Registry Access"
-max-width="80%"
-%}
-
-From now on, this cluster on this namespace will be able to deploy Docker images from the selected Registry.
-
-From this screen you don't really need to finish the deployment in order to apply the secrets changes. Feel free to
-close the screen and go to another Codefresh page.
-
->Note that Codefresh will automatically use the secret you defined in all deployments
-that are performed via the GUI (Codefresh is dynamically creating the correct manifests for you behind the scenes in that case).
-If you wish to use your own manifests, you need to include the secret yourself, as explained in the next section.
-
-
-## Giving access to a Docker Registry with kubectl
-
-You can also use the `kubectl` command directly to give access to a Docker registry.
-This way is not specific to Codefresh so read the [official kubernetes documentation](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/).
-
-
-### Creating the Docker registry secret
-
-The credentials depend upon the [type or registry you use]({{site.baseurl}}/docs/docker-registries/external-docker-registries/).
-
-- The Docker server to use is a domain such `gcr.io`, `azurecr.io` etc
-- The username is your account username.
-- The password is a speficic docker registry password or any other kind of token. You need to check the documentation of your registry provider for the exact details.
-
->Be sure to create the Secret in the namespace in which your application will run.
-Pull secrets are specific to a namespace. If you want to deploy to multiple namespaces
-you need to create a secret for each one of them.
-
-This is an example of creating a pull secret to Azure registry. You can use the same command to any other private registry.
-
- `Shell`
-{% highlight sh %}
-{% raw %}
-
-export DOCKER_REGISTRY_SERVER=mysampleregistry.azurecr.io
-export DOCKER_USER=myregistryname
-export DOCKER_PASSWORD=myregistrytoken
-export DOCKER_EMAIL=YOUR_EMAIL
-
-kubectl create secret docker-registry cfcr\
- --docker-server=$DOCKER_REGISTRY_SERVER\
- --docker-username=$DOCKER_USER\
- --docker-password=$DOCKER_PASSWORD\
- --docker-email=$DOCKER_EMAIL
-{% endraw %}
-{% endhighlight %}
-
-### Using the Docker registry secret
-
-To use the secret you just created, you need to either
-
-* Include it in [your pod manifests](https://kubernetes.io/docs/concepts/containers/#specifying-imagepullsecrets-on-a-pod)
-* Include it in [the service account level](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)
-
-There is nothing specific to Codefresh regarding the usage of Docker registry secrets, and therefore
-following the official Kubernetes documentation is the recommended approach.
-
-## Giving access to a Docker Registry via the Codefresh CLI
-
-The Codefresh CLI can also create pull secrets in an automated manner.
-
-See the Image pull Secret [documentation](https://codefresh-io.github.io/cli/more/image-pull-secret/).
-
-## What to read next
-
-- [Deploy to Kubernetes - quick start]({{site.baseurl}}/docs/getting-started/deployment-to-kubernetes-quick-start-guide/)
-* [Managing your cluster]({{site.baseurl}}/docs/deploy-to-kubernetes/manage-kubernetes/)
-
diff --git a/_docs/deploy-to-kubernetes/add-config-maps-to-your-namespaces.md b/_docs/deploy-to-kubernetes/add-config-maps-to-your-namespaces.md
deleted file mode 100644
index abc5b2e4e..000000000
--- a/_docs/deploy-to-kubernetes/add-config-maps-to-your-namespaces.md
+++ /dev/null
@@ -1,128 +0,0 @@
----
-title: "Add config maps to your namespaces"
-description: "How to use manage Kubernetes Config Maps with Codefresh"
-group: deploy-to-kubernetes
-redirect_from:
- - /docs/add-config-maps-to-your-namespaces/
-toc: true
----
-Many applications require configuration with files, environment variables and command line arguments. It makes applications portable and easily manageable. It's pretty easy to configure an application with this way. But it can become very hard to support tons of config files for different environments and hundreds of microservices.
-
-Kubernetes provides an elegant and very convenient way for application configuration. This way is by using *configuration maps*. You can find more details about config maps at [https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/){:target="_blank"}.
-
-You can manage all your cluster configuration using Codefresh. This article will explain you how to do it.
-
-## View existing config maps
-In order to access the list of existing config maps, open the Kubernetes Services page and switch to list view.
-
-Select a namespace and hover your mouse pointer on it. Click the gear button which appears at the end of the row. You will see a list of all config maps inside this namespace, including date of creation and number of configuration variables inside these maps.
-
-{% include
-image.html
-lightbox="true"
-file="/images/kubernetes/config-maps/change-view.png"
-url="/images/kubernetes/config-maps/change-view.png"
-alt="Change View"
-caption="Change View"
-max-width="50%"
-%}
-
-## Add a new config map
-To add a new config map for the selected namespace, open the list of all config maps and click "Create a New Config Map" button.
-
-{% include image.html
-lightbox="true"
-file="/images/e1650e2-Screen_Shot_2017-10-08_at_9.10.15_AM.png"
-url="/images/e1650e2-Screen_Shot_2017-10-08_at_9.10.15_AM.png"
-alt="Screen Shot 2017-10-08 at 9.10.15 AM.png"
-max-width="40%"
-%}
-
-In the config map form that will open, enter a name, add variables and click the "Create" button.
-
-{% include image.html
-lightbox="true"
-file="/images/108add4-Screen_Shot_2017-10-08_at_9.10.22_AM.png"
-url="/images/108add4-Screen_Shot_2017-10-08_at_9.10.22_AM.png"
-alt="Screen Shot 2017-10-08 at 9.10.22 AM.png"
-max-width="40%"
-%}
-
-## You can add variables to your config maps in several ways:
-
-{:.text-secondary}
-### Add a single variable in config map
-
-This is the easiest way to add a variable inside the config map (It's very useful when you want to quickly create a small configmap with 1-2 variables inside):
-1. Enter key name
-1. Enter key value
-1. Click "ADD VARIABLE"
-
-{% include image.html
-lightbox="true"
-file="/images/48cda66-Screen_Shot_2017-10-08_at_9.10.29_AM.png"
-url="/images/108add4-Screen_Shot_2017-10-08_at_9.10.22_AM.png"
-alt="Screen Shot 2017-10-08 at 9.10.29 AM.png"
-max-width="40%"
-%}
-
-{:.text-secondary}
-### Import variables from text / file
-If you already have configuration variables inside a `*.property` file you can easily import it inside your configmap.
-
-To import from text:
-1. Click "IMPORT FROM TEXT"
-1. Copy text from file and insert inside text area
-1. Click apply
-
-{% include image.html
-lightbox="true"
-file="/images/40b1c06-Screen_Shot_2017-10-08_at_9.10.39_AM.png"
-url="/images/40b1c06-Screen_Shot_2017-10-08_at_9.10.39_AM.png"
-alt="Screen Shot 2017-10-08 at 9.10.39 AM.png"
-max-width="40%"
-%}
-
-To import from file:
-1. Click "IMPORT FROM FILE"
-1. Select file from your computer and click open button
-
-{:.text-secondary}
-### Copy from existing config map
-
-You can easily copy a previously created config map file and use it in other namespaces using the following steps:
-
-1. Click "COPY FROM EXISTING CONFIG MAP"
-1. Select cluster and namespace which contains configmap that you want to copy
-1. Find this configmap inside the list and click "SELECT" button
-
-{% include image.html
-lightbox="true"
-file="/images/181f2d4-Screen_Shot_2017-10-08_at_9.11.03_AM.png"
-url="/images/181f2d4-Screen_Shot_2017-10-08_at_9.11.03_AM.png"
-alt="Screen Shot 2017-10-08 at 9.11.03 AM.png"
-max-width="40%"
-%}
-
-## Edit / remove config maps
-You can easily edit / remove variables for each of your config maps.
-
-1. Select a config map
-1. Click on pencil icon
-1. You can add new variables using the same instructions as in "add new config map" section
-
-{% include image.html
-lightbox="true"
-file="/images/1fb1529-Screen_Shot_2017-10-08_at_9.22.27_AM.png"
-url="/images/1fb1529-Screen_Shot_2017-10-08_at_9.22.27_AM.png"
-alt="Screen Shot 2017-10-08 at 9.22.27 AM.png"
-max-width="40%"
-%}
-
-To remove a config map, click on "remove" icon in the selected row. After your confirmation, the configmap will be removed.
-
-## What to read next
-
-- [Connect to your Kubernetes cluster]({{site.baseurl}}/docs/deploy-to-kubernetes/add-kubernetes-cluster/)
-- [Manage your Kubernetes cluster]({{site.baseurl}}/docs/deploy-to-kubernetes/manage-kubernetes/)
-- [Deploy to Kubernetes - quick start]({{site.baseurl}}/docs/getting-started/deployment-to-kubernetes-quick-start-guide/)
diff --git a/_docs/deploy-to-kubernetes/add-kubernetes-cluster.md b/_docs/deploy-to-kubernetes/add-kubernetes-cluster.md
deleted file mode 100644
index 2b1aea13d..000000000
--- a/_docs/deploy-to-kubernetes/add-kubernetes-cluster.md
+++ /dev/null
@@ -1,636 +0,0 @@
----
-title: "Add Kubernetes Cluster"
-description: "How to connect your Kubernetes cluster to the Codefresh dashboard"
-group: deploy-to-kubernetes
-redirect_from:
- - /docs/adding-non-gke-kubernetes-cluster
- - /docs/adding-non-gke-kubernetes-cluster/
- - /docs/deploy-to-kubernetes/adding-non-gke-kubernetes-cluster/
-toc: true
----
-
-Codefresh offers its own Kubernetes dashboard that allows you to inspect the services and namespaces
-in your cluster. To activate this dashboard, you need to connect your cluster to your Codefresh account first.
-
-## Prerequisites
-
-Codefresh SAAS needs network connectivity to connect to your cluster. If your cluster is behind a restrictive firewall
-make sure that you allow the [following IPs]({{site.baseurl}}/docs/administration/platform-ip-addresses/) to come through.
-
-Notice that you only need to deal with this process if you use the SAAS version of Codefresh. For On-premises and [Hybrid installations]({{site.baseurl}}/docs/administration/behind-the-firewall/), there is no need to tamper with your firewall.
-
-## Visit the cluster integration screen
-
-
-Start by going into your Account Configuration, by clicking on *Account Settings* on the left sidebar. On the first section called *Integrations* click the *Configure* button next to *Kubernetes*.
-
-{% include image.html
- lightbox="true"
- file="/images/integrations/codefresh-integrations.png"
- url="/images/integrations/codefresh-integrations.png"
- alt="Codefresh integrations"
- caption="Codefresh integrations"
- max-width="70%"
- %}
-
-In the Kubernetes integration window, you will be able to add a cluster from known providers such as Google, Azure, Amazon etc. You can also add any generic Kubernetes cluster by manually entering your cluster settings.
-
-{:.text-secondary}
-## Adding GKE Cluster
-Adding a cluster in GKE can be done by clicking the **Add cluster** button under **Google Cloud Provider** and selecting the desired project and cluster.
-
-If this is your first time, you'll be prompted to authenticate using your Google credentials, make sure you're doing so with a user that have access to your GKE projects.
-
-For GKE cluster versions >=1.19 basic authentication is deprecated. You can add the GKE cluster manually by [using the custom Kubernetes integration option]({{site.baseurl}}/docs/deploy-to-kubernetes/add-kubernetes-cluster/#adding-any-other-cluster-type-not-dependent-on-any-provider) instead.
-
-{{site.data.callout.callout_info}}
-
-If you are a new customer of Google Cloud, you are also eligible to receive a Codefresh offer to get up to $500 in Google credits. As soon at the GKE integration is complete within Codefresh, you will get an email with extra details on how to claim your credits.
-
-Follow the link in the email to fill in an application for the free credits. Once Google approves the application (usually within 1-2 days) your credits will be available to your account. Make sure to check your spam folder for that email.
-
-{{site.data.callout.end}}
-
-{:.text-secondary}
-
-## Adding AKS cluster
-
-To add an Azure cluster, select *Azure AKS* from the drop-down menu instead of *Azure AKS SP*. Click the *Authenticate button* and enter your Azure credentials. You will see a description of all permissions that Codefresh needs
-in order to access your cluster. Accept them and Codefresh will connect to Azure to get the cluster information.
-
->If you experience difficulties at this point try logging into Azure first in your browser *before* clicking
-the authenticate button. Also make sure that you are using an organizational/company Azure account and not a personal one. We are currently working with Microsoft to improve this integration.
-
-If everything is ready you will see a dialog that allows you to select your Azure subscription and the
-cluster name that you wish to use.
-
-{% include image.html
-lightbox="true"
-file="/images/kubernetes/add-cluster/select-aks-cluster.png"
-url="/images/kubernetes/add-cluster/select-aks-cluster.png"
-alt="Selecting the Azure cluster"
-caption="Selecting the Azure cluster"
-max-width="60%"
- %}
-
-Codefresh will query the cluster and show its nodes. You are now ready to [deploy to Azure kubernetes]({{site.baseurl}}/docs/getting-started/deployment-to-kubernetes-quick-start-guide/).
-
->If you wish for any reason to revoke the granted access from the Azure side, visit [https://account.activedirectory.windowsazure.com/r#/applications](https://account.activedirectory.windowsazure.com/r#/applications) and remove "Codefresh" from the list.
-
-## Adding an AKS cluster with a service principal
-
-An alternative method of adding an Azure cluster is by using a service principal (*Azure AKS SP*). First follow the [instructions for creating a service principal in the Azure portal](https://docs.microsoft.com/en-us/azure/active-directory/develop/howto-create-service-principal-portal).
-
-Then from the drop-down menu select *Azure AKS SP*. Click the *Authenticate button* and enter the following details:
-
-* `Client ID`
-* `Tenant`
-* `Client secret`
-
-{% include image.html
-lightbox="true"
-file="/images/kubernetes/add-cluster/connect-azure-spn.png"
-url="/images/kubernetes/add-cluster/connect-azure-spn.png"
-alt="Azure Service principal details"
-caption="Azure Service principal details"
-max-width="60%"
- %}
-
-Click the *Save* button once finished. Assuming that the authentication is successful click the *Add cluster* button and you will be able to select any of your available Azure clusters.
-
-Codefresh will query the cluster and show its nodes. You are now ready to [deploy to Azure kubernetes]({{site.baseurl}}/docs/getting-started/deployment-to-kubernetes-quick-start-guide/).
-
-
-## Adding EKS Cluster
-
-To add an Amazon EKS cluster, you must first obtain `kubectl` access to it. Follow the instructions for using the
-[AWS CLI](https://aws.amazon.com/premiumsupport/knowledge-center/eks-cluster-connection/) in order to obtain your kubeconfig locally.
-
-```
-aws eks --region region update-kubeconfig --name cluster_name
-```
-
-Once you have access via `kubectl` then follow the [instructions]({{site.baseurl}}/docs/deploy-to-kubernetes/add-kubernetes-cluster/#get-cluster-configuration-manually) to obtain all the cluster details.
-To add the Amazon cluster, select *Amazon AWS* from the *ADD PROVIDER* drop-down menu and enter all details in the respective field in the Codefresh UI.
-
-> On adding or upgrading to Kubernetes cluster version 1.23 or higher, you can encounter volume provisioning issues with Amazon Elastic Block Store (Amazon EBS). To troubleshoot, see [Volume provisioning issues for Amazon EBS](#volume-provisioning-issues-for-amazon-ebs) later on in this article.
-
-## Adding a DigitalOcean cluster
-
-DigitalOcean is also offering a hosted solution for Kubernetes.
-
-To add a DO cluster select *DigitalOcean* from the *Add provider* menu in your [integration settings](https://g.codefresh.io/account-admin/account-conf/integration/kubernetes). Click the authenticate button and enter your DO account credentials:
-
-{% include image.html
-lightbox="true"
-file="/images/kubernetes/add-cluster/authorize-do.png"
-url="/images/kubernetes/add-cluster/authorize-do.png"
-alt="Authorizing DigitalOcean Integration"
-caption="Authorizing DigitalOcean Integration"
-max-width="35%"
- %}
-
-Click on the checkbox next to your account name and select the *Authorize application* button. Codefresh has now access to your DigitalOcean cluster. You need to authenticate only once.
-
-{% include image.html
-lightbox="true"
-file="/images/kubernetes/add-cluster/do-authorized.png"
-url="/images/kubernetes/add-cluster/do-authorized.png"
-alt="DigitalOcean is now authorized"
-caption="DigitalOcean is now authorized"
-max-width="70%"
- %}
-
-Next, expand the DigitalOcean row from the triangle icon on the right and click on the *Add cluster* button. The drop-down menu should contain all your DigitalOcean Kubernetes clusters. Select the one that you want to connect into Codefresh and click the *Add* button.
-
-{% include image.html
-lightbox="true"
-file="/images/kubernetes/add-cluster/add-do-cluster.png"
-url="/images/kubernetes/add-cluster/add-do-cluster.png"
-alt="Selecing the DigitalOcean cluster"
-caption="Selecing the DigitalOcean cluster"
-max-width="40%"
- %}
-
-Your cluster is now connected. You should be able to see it your [Kubernetes dashboard]({{site.baseurl}}/docs/deploy-to-kubernetes/manage-kubernetes/) and start [deploying]({{site.baseurl}}/docs/getting-started/deployment-to-kubernetes-quick-start-guide/) on it.
-
-Note that you can als add a DigitalOcean cluster as a generic cluster as well (explained below).
-
-
-## Adding any other cluster type (not dependent on any provider)
-
-Go to your Account Configuration, by clicking on *Account Settings* on the left sidebar. On the first section called *Integrations* click the *Configure* button next to *Kubernetes*.
-
-In order to add any other type of cluster, outside of GKE, use **Custom Providers**
-
-
-{% include image.html
-lightbox="true"
-file="/images/kubernetes/add-cluster/add-cluster-button.png"
-url="/images/kubernetes/add-cluster/add-cluster-button.png"
-alt="Adding a custom cluster in Codefresh"
-caption="Adding a custom K8s cluster in Codefresh"
-max-width="60%"
- %}
-
-The integration between Codefresh and your Kubernetes cluster is API based and relies on a Kubernetes service account of your choosing that will be used to manage the integration.
-
-The configurations you'll be required to add are:
-
-
-1. Name - Any name of your choosing, that will represent your cluster context in Codefresh. Do not use spaces, dots or other strange characters in the name.
-1. Host - The full URL of the Kubernetes API endpoints including protocol and port.
-1. Certificate - The Kubernetes service account certificate used for the integration with Codefresh (base64 encoded).
-1. Token - The Kubernetes service account token used for the integration with Codefresh (base64 encoded)
-1. (Optional) Namespace - Restrict Codefresh [access to a specific namespace](#restrict-codefresh-access-to-a-specific-namespace)
-
-
-{% include image.html
- lightbox="true"
- file="/images/kubernetes/add-cluster/add-cluster-fields.png"
- url="/images/kubernetes/add-cluster/add-cluster-fields.png"
- alt="Adding a custom cluster in Codefresh - details"
- caption="Adding a custom cluster in Codefresh - details"
- max-width="80%"
- %}
-
-There is also a toggle for [private clusters behind a firewall]({{site.baseurl}}/docs/enterprise/behind-the-firewall/).
-
- In the section below we'll provide you with easy instructions how to get all your cluster configurations in order to add it to Codefresh.
-
-### Get cluster configuration manually
-
-Codefresh accesses any custom cluster using a [service account](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/). You can define the privileges Codefresh has on your cluster
-using the standard authorization methods (i.e. [RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)) supported by your Kubernetes infrastructure.
-
-You need a terminal with `kubectl` access on your cluster. You can even use the "cloud shell" of your
-cloud provider for this purpose.
-
-#### The easy and insecure way
-
-If you are evaluating Codefresh and want to connect your cluster as fast as possible with no issues
-follow these steps:
-
->Note that this method is only suggested for non-production clusters, and quick demos. See the next section for the proper way to use Codefresh in production environments.
-
-First make sure that you are giving commands to the appropriate cluster if you have more than one:
-
-`Choose cluster`
-{% highlight shell %}
-{% raw %}
-kubectl config use-context
-{% endraw %}
-{% endhighlight %}
-
-Then give full admin privileges to the default account.
-
-`Make default account cluster administrator`
-{% highlight shell %}
-{% raw %}
-kubectl create clusterrolebinding default-admin --clusterrole cluster-admin --serviceaccount=default:default -n default
-{% endraw %}
-{% endhighlight %}
-
-Finally run the following commands and copy-paste the result to each Codefresh field in the UI:
-
-`Host IP`
-{% highlight shell %}
-{% raw %}
-export CURRENT_CONTEXT=$(kubectl config current-context) && export CURRENT_CLUSTER=$(kubectl config view -o go-template="{{\$curr_context := \"$CURRENT_CONTEXT\" }}{{range .contexts}}{{if eq .name \$curr_context}}{{.context.cluster}}{{end}}{{end}}") && echo $(kubectl config view -o go-template="{{\$cluster_context := \"$CURRENT_CLUSTER\"}}{{range .clusters}}{{if eq .name \$cluster_context}}{{.cluster.server}}{{end}}{{end}}")
-{% endraw %}
-{% endhighlight %}
-
-`Certificate`
-{% highlight shell %}
-{% raw %}
-echo $(kubectl get secret -o go-template='{{index .data "ca.crt" }}' $(kubectl get sa default -o go-template="{{range .secrets}}{{.name}}{{end}}"))
-{% endraw %}
-{% endhighlight %}
-
-`Token`
-{% highlight shell %}
-{% raw %}
-echo $(kubectl get secret -o go-template='{{index .data "token" }}' $(kubectl get sa default -o go-template="{{range .secrets}}{{.name}}{{end}}"))
-{% endraw %}
-{% endhighlight %}
-
-Once the cluster been added successfully you can go to the `Kubernetes` tab to start working with the services of your cluster.
-
-#### The proper/secure way
-
-For production environments you should create a service account and/or role for Codefresh access.
-The minimum permissions Codefresh needs to work with the cluster are the following:
-
-`codefresh-role.yml`
-{% highlight yaml %}
-{% raw %}
-kind: ClusterRole
-apiVersion: rbac.authorization.k8s.io/v1
-metadata:
- name: codefresh-role
-rules:
- - apiGroups: [""]
- resources: ["*"]
- verbs: ["list", "watch", "get"]
-{% endraw %}
-{% endhighlight %}
-
-Note that these permissions will only allow Codefresh to read the cluster resources and populate the respective dashboards. You need to give more privileges for actual deployments. For more information see the [Kubernetes RBAC documentation page](https://kubernetes.io/docs/reference/access-authn-authz/rbac/).
-
-Here is an example with role + service account + binding.
-
-`codefresh-role-sa-bind.yml`
-{% highlight yaml %}
-{% raw %}
-kind: ClusterRole
-apiVersion: rbac.authorization.k8s.io/v1
-metadata:
- name: codefresh-role
-rules:
- - apiGroups: [ "*"]
- resources: ["*"]
- verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
----
-apiVersion: v1
-kind: ServiceAccount
-metadata:
- name: codefresh-user
- namespace: kube-system
----
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRoleBinding
-metadata:
- name: codefresh-user
-roleRef:
- apiGroup: rbac.authorization.k8s.io
- kind: ClusterRole
- name: codefresh-role
-subjects:
-- kind: ServiceAccount
- name: codefresh-user
- namespace: kube-system
-{% endraw %}
-{% endhighlight %}
-
-Select the appropriate cluster if you have more than one:
-
-`Choose cluster`
-{% highlight shell %}
-{% raw %}
-kubectl config use-context
-{% endraw %}
-{% endhighlight %}
-
-Create the Codefresh user/role:
-
-`Apply Codefresh access rules`
-{% highlight shell %}
-{% raw %}
-kubectl apply -f codefresh-role-sa-bind.yml
-{% endraw %}
-{% endhighlight %}
-
-Finally run the following commands and copy-paste the result to each Codefresh field in the UI:
-
-`Host IP`
-{% highlight shell %}
-{% raw %}
-export CURRENT_CONTEXT=$(kubectl config current-context) && export CURRENT_CLUSTER=$(kubectl config view -o go-template="{{\$curr_context := \"$CURRENT_CONTEXT\" }}{{range .contexts}}{{if eq .name \$curr_context}}{{.context.cluster}}{{end}}{{end}}") && echo $(kubectl config view -o go-template="{{\$cluster_context := \"$CURRENT_CLUSTER\"}}{{range .clusters}}{{if eq .name \$cluster_context}}{{.cluster.server}}{{end}}{{end}}")
-{% endraw %}
-{% endhighlight %}
-
-`Certificate`
-{% highlight shell %}
-{% raw %}
-echo $(kubectl get secret -n kube-system -o go-template='{{index .data "ca.crt" }}' $(kubectl get sa codefresh-user -n kube-system -o go-template="{{range .secrets}}{{.name}}{{end}}"))
-{% endraw %}
-{% endhighlight %}
-
-`Token`
-{% highlight shell %}
-{% raw %}
-echo $(kubectl get secret -n kube-system -o go-template='{{index .data "token" }}' $(kubectl get sa codefresh-user -n kube-system -o go-template="{{range .secrets}}{{.name}}{{end}}"))
-{% endraw %}
-{% endhighlight %}
-
-#### The proper/secure way for Kubernetes Cluster 1.24+
-
-For production environments, create a service account and/or role for Codefresh access.
-
-Codefresh needs these minimum permissions to work with the cluster:
-
-`codefresh-role.yml`
-{% highlight yaml %}
-{% raw %}
-kind: ClusterRole
-apiVersion: rbac.authorization.k8s.io/v1
-metadata:
- name: codefresh-role
-rules:
- - apiGroups: [""]
- resources: ["*"]
- verbs: ["list", "watch", "get"]
-{% endraw %}
-{% endhighlight %}
-
-Note that these permissions will only allow Codefresh to read the cluster resources and populate the respective dashboards. You need to give more privileges for actual deployments. For more information see the [Kubernetes RBAC documentation page](https://kubernetes.io/docs/reference/access-authn-authz/rbac/){:target="\_blank"}.
-
-Here is an example with role + service account + binding.
-
-`codefresh-role-sa-bind.yml`
-{% highlight yaml %}
-{% raw %}
-kind: ClusterRole
-apiVersion: rbac.authorization.k8s.io/v1
-metadata:
- name: codefresh-role
-rules:
- - apiGroups: ["*"]
- resources: ["*"]
- verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
-—--
-apiVersion: v1
-kind: ServiceAccount
-metadata:
- name: codefresh-user
- namespace: kube-system
-—--
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRoleBinding
-metadata:
- name: codefresh-user
-roleRef:
- apiGroup: rbac.authorization.k8s.io
- kind: ClusterRole
- name: codefresh-role
-subjects:
-- kind: ServiceAccount
- name: codefresh-user
- namespace: kube-system
-—--
-apiVersion: v1
-kind: Secret
-type: kubernetes.io/service-account-token
-metadata:
- name: codefresh-user-token
- namespace: kube-system
- annotations:
- kubernetes.io/service-account.name: "codefresh-user"
-
-{% endraw %}
-{% endhighlight %}
-
-
-
-1. Select the appropriate cluster if you have more than one:
-`Choose cluster`
-{% highlight shell %}
-{% raw %}
-kubectl config use-context
-{% endraw %}
-{% endhighlight %}
-
-{:start="2"}
-1. Create the Codefresh user/role:
-`Apply Codefresh access rules`
-{% highlight shell %}
-{% raw %}
-kubectl apply -f codefresh-role-sa-bind.yml
-{% endraw %}
-{% endhighlight %}
-
-{:start="3"}
-1. Finally run the following commands, and copy-paste the results to the respective Codefresh field in the UI:
-`Host IP`
-{% highlight shell %}
-{% raw %}
-export CURRENT_CONTEXT=$(kubectl config current-context) && export CURRENT_CLUSTER=$(kubectl config view -o go-template="{{\$curr_context := \"$CURRENT_CONTEXT\" }}{{range .contexts}}{{if eq .name \$curr_context}}{{.context.cluster}}{{end}}{{end}}") && echo $(kubectl config view -o go-template="{{\$cluster_context := \"$CURRENT_CLUSTER\"}}{{range .clusters}}{{if eq .name \$cluster_context}}{{.cluster.server}}{{end}}{{end}}")
-{% endraw %}
-{% endhighlight %}
-
-`Certificate`
-{% highlight shell %}
-{% raw %}
-echo $(kubectl get secret -n kube-system -o go-template='{{index .data "ca.crt" }}' codefresh-user-token)
-{% endraw %}
-{% endhighlight %}
-
-`Token`
-{% highlight shell %}
-{% raw %}
-echo $(kubectl get secret -n kube-system -o go-template='{{index .data "token" }}' codefresh-user-token)
-{% endraw %}
-{% endhighlight %}
-
-### Restrict Codefresh access to a specific namespace
-
-In most cases, you want to allow Codefresh to access all namespaces inside the cluster. This is the most convenient option as it will make
-the [services dashboard]({{site.baseurl}}/docs/deploy-to-kubernetes/manage-kubernetes/) (and other GUI dashboards) the central way to manage your clusters.
-
-You can also restrict Codefresh only to an specific namespace of your choosing. To achieve this, use the details of service account in the previous section that has access only to that specific namespace, and also fill the *namespace* field in the cluster details form.
-
-{% include image.html
- lightbox="true"
- file="/images/kubernetes/add-cluster/restrict-namespace.png"
- url="/images/kubernetes/add-cluster/restrict-namespace.png"
- alt="Allows Codefresh access to a single namespace only"
- caption="Allows Codefresh access to a single namespace only"
- max-width="80%"
- %}
-
-Notice that if you follow this approach several built-in Codefresh capabilities will be disabled (e.g. creating new namespaces from the GUI).
-
-
-
-## Adding a Rancher cluster
-
-Rancher clusters are currently supported as generic clusters. Rancher clusters have a specific authentication configuration (the details are here: [https://rancher.com/kubernetes-authentication-in-rancher-and-rbac](https://rancher.com/kubernetes-authentication-in-rancher-and-rbac) for Rancher 1.x and at [https://rancher.com/blog/2018/2018-05-04-authentication-authorization-rancher2/](https://rancher.com/blog/2018/2018-05-04-authentication-authorization-rancher2/) for Rancher 2.x).
-
-Authentication using a token of a Kubernetes Service Account, which is usually used by Codefresh, doesn't work with Rancher clusters. Also, Rancher doesn't do proper TLS termination out-of-the-box for Kubernetes clusters hosted on it, so one needs to configure a load balancer for that purpose.
-
-In summary, the following conditions should be met in order to add the cluster, hosted on Rancher to Codefresh:
-
-### For Rancher version 1.x
-
-1. The token should be taken from the kubeconfig provided by Rancher and it has to be encoded with base64 before putting it into Codefresh. Be careful with the '\n' characters when encoding. The command for Linux is: `echo | tr -d '\n' | base64 | tr -d '\n'`.
-1. The CA certificate should be the CA of the Load Balancer standing in front of Rancher.
-1. The hostname and port should be corresponding to your Load Balancer.
-
-{% include image.html
- lightbox="true"
- file="/images/kubernetes/add-cluster/rancher-token.png"
- url="/images/kubernetes/add-cluster/rancher-token.png"
- alt="Getting the Rancher token"
- caption="Getting the Rancher token"
- max-width="40%"
- %}
-
-### For Rancher version 2.x
-
-1. Kubernetes HOST is in the kubeconfig provided by Rancher for the Kubernetes cluster based on the domain name of Rancher + the Kubernetes cluster endpoint exposed through Rancher in cluster -> server. Example: `https://rancher.localhost/k8s/clusters/c-npft4`.
-1. The token should be taken from the kubeconfig provided by Rancher under user -> token section of YAML and it has to be encoded with base64 before putting it into Codefresh. Be careful with the '\n' characters when encoding, do not wrap token in quotes when running echo command. The command for Linux is: `echo | tr -d '\n' | base64 | tr -d '\n'` Example: `kubeconfig-user-xtnt4:cppxv6db…`.
-1. The CA certificate should be the CA of the Load Balancer standing in front of Rancher base64 encoded `openssl base64 -in cert -out b64`. And then run this command on the file to remove any white space. `cat b64 | tr -d '\040\011\012\015' > b64_cert` then copy and paste this base64 encoded value into Codefresh UI Cert field.
-1. The hostname and port should be corresponding to your Load Balancer.
-
-{% include image.html
- lightbox="true"
- file="/images/kubernetes/add-cluster/rancher-2.png"
- url="/images/kubernetes/add-cluster/rancher-2.png"
- alt="Rancher 2.x cluster details"
- caption="Rancher 2.x cluster details"
- max-width="40%"
- %}
-
-
-Once you have all the information follow the instructions for adding a generic Kubernetes cluster in Codefresh as described in the previous section.
-
-
-## Troubleshooting cluster addition
-
-After adding your cluster configurations and in case the test fails, click "Save" to get the error message back.
-
-{% include image.html
- lightbox="true"
- file="/images/42382c7-click-save.png"
- url="/images/42382c7-click-save.png"
- alt="click-save.png"
- max-width="40%"
- %}
-
-{:.text-secondary}
-### Error: Cannot list namespaces
-
- `Add Cluster Error`
-{% highlight shell %}
-{% raw %}
-Failed to add cluster: namespaces is forbidden: User "system:serviceaccount:default:default" cannot list namespaces at the cluster scope
-{% endraw %}
-{% endhighlight %}
-
-The service account used for the integration doesn't have the minimal permissions required. To fix this add a service account that have the required permissions.
-
-The easiest way to do this is to create a cluster binding role between the default service account and cluster-admin role:
-
- `Create cluster binding with admin permissions`
-{% highlight shell %}
-{% raw %}
-kubectl create clusterrolebinding default-admin --clusterrole cluster-admin --serviceaccount=default:default
-{% endraw %}
-{% endhighlight %}
-
-### Volume provisioning issues for Amazon EBS
-
-After adding or upgrading Kubernetes clusters to version 1.23 or higher, you can encounter volume provisioning issues with Amazon EBS
-(Elastic Block Store).
-
-**Issue**
-
-* Codefresh builds remain in `pending` status as EBS volumes cannot be attached
-* Errors in `pod` logs:
-
- `Warning FailedMount 112s kubelet Unable to attach or mount volumes:
- unmounted volumes=[dind], unattached volumes=[dind-config dind codefresh-certs-server]:
- timed out waiting for the condition`
-
-**Possible cause**
-The Amazon EBS CSI driver is not installed on the cluster.
-Kubernetes versions 1.23 and higher require the Amazon EBS CSI driver for EBS volume management in EKS clusters. For more information, see [Amazon EBS CSI driver](https://docs.aws.amazon.com/eks/latest/userguide/ebs-csi.html){:target="\_blank"}.
-
-
-**Solution**
-Add the driver as an Amazon EKS add-on or as a self-managed add-on:
-* [Add as Amazon EKS add-on](https://docs.aws.amazon.com/eks/latest/userguide/managing-ebs-csi.html){:target="\_blank"}
-* [Add as self-managed add-on](https://github.com/kubernetes-sigs/aws-ebs-csi-driver){:target="\_blank"}
-
-
-
-
-## Kubernetes cluster - using an external reverse proxy (edge case)
-
-In case you're using an external reverse proxy to manage inbound traffic to your Kubernetes API, please read [this article]({{site.baseurl}}/docs/deploy-to-kubernetes/verify-cluster-tls-ssl-configuration/) to make sure your certificate setup are managed correctly in order to add your cluster successfully to Codefresh.
-
-## Multiple CAs in certificate chain
-
-Ideally your Kubernetes cluster will have a single certificate which is used directly on the API endpoint. Some organizations
-place clusters behind a load balancer or other proxy mechanism that uses a chain or certificates.
-
-When that happens and you more than one [CA](https://en.wikipedia.org/wiki/Certificate_authority) in your certification chain, you need to provide Codefresh with a [Certificate bundle](https://en.wikipedia.org/wiki/Chain_of_trust) (a file that containers the intermediate CAs as well).
-
-You will know when this is the case as this error will appear when you try to connect your cluster:
-
-```
-{"status":400,"code":"1004","name":"BAD_REQUEST_ERROR","message":"Failed to add cluster: unable to get local issuer certificate","context":{}}
-```
-
-To get the whole certificate open the URL of your Kubernetes in Chrome or Firefox and export all individual certificates as files
-
-{% include image.html
- lightbox="true"
- file="/images/kubernetes/add-cluster/cert-hierarchy.png"
- url="/images/kubernetes/add-cluster/cert-hierarchy.png"
- alt="A Certificate chain"
- caption="A Certificate chain"
- max-width="60%"
- %}
-
-The steps needed are:
-
-1. Connect all certificates (apart from the API/endpoint one) to a bundle:
-`cat rootCA.crt intermediateCA.crt > ca_bundle_cert`.
-1. Run the following to check the validity of the certificate:
-`openssl verify -verbose -CAfile ca_bundle_cert k8_server_cert`.
-1. If the check above passes fine, go on and run the following on your CA bundle file:
-`base64 ca_bundle_cert | tr -d '\n'`.
-1. Copy the output string (be careful when copying) and check whether you have copied it correctly:
-`openssl x509 -text -in <(echo | base64 -d)` - you should see the contents of your CA bundle file.
-1. Put the copied string into the Codefresh Kubernetes integration form and test the connection.
-
-Please make sure the certs are in order Root -> Intermediate -> Server.
-
-## What to read next
-
-- [Deploy to Kubernetes - quick start]({{site.baseurl}}/docs/getting-started/deployment-to-kubernetes-quick-start-guide/)
-- [Deploying to Kubernetes with Helm]({{site.baseurl}}/docs/getting-started/helm-quick-start-guide/)
-- [Manage your Kubernetes cluster in Codefresh]({{site.baseurl}}/docs/deploy-to-kubernetes/codefresh-kubernetes-integration-beta/)
-- [Example - Deploy demochat to Kubernetes cluster]({{site.baseurl}}/docs/deploy-to-kubernetes/codefresh-kubernetes-integration-demochat-example/)
-
diff --git a/_docs/deploy-to-kubernetes/custom-kubectl-commands.md b/_docs/deploy-to-kubernetes/custom-kubectl-commands.md
deleted file mode 100644
index 3c64d2071..000000000
--- a/_docs/deploy-to-kubernetes/custom-kubectl-commands.md
+++ /dev/null
@@ -1,183 +0,0 @@
----
-title: "Running custom kubectl commands"
-description: "How to use kubectl in your Codefresh pipelines"
-group: deploy-to-kubernetes
-toc: true
----
-
-As explained in the [deployment options page]({{site.baseurl}}/docs/deploy-to-kubernetes/deployment-options-to-kubernetes/), Codefresh has several built-in facilities for deploying to Kubernetes clusters.
-
-If you wish you can still run your own custom `kubectl` commands in a [freestyle step]({{site.baseurl}}/docs/codefresh-yaml/steps/freestyle/) for maximum flexibility on cluster deployments. [Kubectl](https://kubernetes.io/docs/reference/kubectl/overview/) is the command line interface for managing kubernetes clusters.
-
-Codefresh helps you even in this scenario by automatically setting up your [config context](https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) with your [connected clusters]({{site.baseurl}}/docs/deploy-to-kubernetes/add-kubernetes-cluster/).
-
-The config context is automatically placed for you at the path of the [variable]({{site.baseurl}}/docs/codefresh-yaml/variables/) `$CF_KUBECONFIG_PATH`.
-In the current Codefresh implementation this expands to `/codefresh/volume/sensitive/.kube/config`, inside the [shared step volume]({{site.baseurl}}/docs/configure-ci-cd-pipeline/introduction-to-codefresh-pipelines/#sharing-the-workspace-between-build-steps).
-
-Notice that when you use custom kubectl commands, it is your responsibility to template your manifests using any of the available options. If you wish to employ Codefresh for templating it is better to use the dedicated [cf-deploy-kubernetes step]({{site.baseurl}}/docs/deploy-to-kubernetes/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). You can choose a specific version of `kubectl` with the appropriate tag or just select `latest` of 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 will see the help options for `kubectl`.
-
-## Getting a config context
-
-The important thing to know when running custom `kubectl` commands is that Codefresh is automatically setting up
-your [kubeconfig files](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) for you with the cluster information present in [integrations]({{site.baseurl}}/docs/deploy-to-kubernetes/add-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 are going to create two docker images and deploy them into two separate clusters, using custom `kubectl` commands. We are going also to use the [parallel capability]({{site.baseurl}}/docs/codefresh-yaml/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 full `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 this example above we select the one of the clusters on each deployment step, and then apply several Kubernetes manifests that constitute an application.
-
-## What to read next
-
-* [Connnecting to your cluster]({{site.baseurl}}/docs/deploy-to-kubernetes/add-kubernetes-cluster/)
-* [Managing your cluster]({{site.baseurl}}/docs/deploy-to-kubernetes/manage-kubernetes/)
-* [Accessing a docker registry]({{site.baseurl}}/docs/deploy-to-kubernetes/access-docker-registry-from-kubernetes/)
-
-
-
-
-
-
-
-
-
-
\ No newline at end of file
diff --git a/_docs/deploy-to-kubernetes/deployment-options-to-kubernetes.md b/_docs/deploy-to-kubernetes/deployment-options-to-kubernetes.md
deleted file mode 100644
index a3fd503a8..000000000
--- a/_docs/deploy-to-kubernetes/deployment-options-to-kubernetes.md
+++ /dev/null
@@ -1,136 +0,0 @@
----
-title: "Deployment Options for Kubernetes"
-description: "Learn how to deploy to Kubernetes with the declarative deploy step"
-group: deploy-to-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 a lot of options when it comes to Kubernetes deployments:
-
-1. Using the Codefresh GUI to deploy on demand. This is the easiest way and was described in the [quick start guide]({{site.baseurl}}/docs/getting-started/deployment-to-kubernetes-quick-start-guide/).
-1. Using the dedicated [deploy step]({{site.baseurl}}/docs/codefresh-yaml/steps/deploy/) in a pipeline. Explained in detail in the present page.
-1. Using the [cf-deploy-kubernetes step]({{site.baseurl}}/docs/deploy-to-kubernetes/kubernetes-templating/) in a pipeline. This can also perform simple templating on Kubernetes manifests.
-1. Using a [freestyle]({{site.baseurl}}/docs/codefresh-yaml/steps/freestyle/) step with [Kustomize](https://kustomize.io). Described in details in [this page]({{site.baseurl}}/docs/yaml-examples/examples/deploy-with-kustomize).
-1. Using a [freestyle]({{site.baseurl}}/docs/codefresh-yaml/steps/freestyle/) step with your own `kubectl` commands. This is very flexible, but assumes that you know how to work with `kubectl`. Described in details in [this page]({{site.baseurl}}/docs/deploy-to-kubernetes/custom-kubectl-commands/).
-1. Using Helm as a package manager. See the [Helm quick start guide]({{site.baseurl}}/docs/getting-started/helm-quick-start-guide/) for more details.
-
-## Prerequisites
-
-It is assumed that
- - You have already [added your K8s cluster]({{site.baseurl}}/docs/deploy-to-kubernetes/add-kubernetes-cluster/) into Codefresh
- - You are familiar with [Codefresh YAML]({{site.baseurl}}/docs/codefresh-yaml/what-is-the-codefresh-yaml/) and basic [pipeline steps ]({{site.baseurl}}/docs/codefresh-yaml/steps/)and know how to describe it
- - You know how to [integrate your docker registry]({{site.baseurl}}/docs/docker-registries/external-docker-registries/) with Codefresh
-
-## Build and Push your image
-The following describe 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.
->Note: If you're deploying to an existing service in your Kubernetes cluster please skip to the [next step]({{ site.baseurl }}/docs/deploy-to-kubernetes/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 finished and you will be able to 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.
-
-## What to read next
-
-- [Add your cluster]({{site.baseurl}}/docs/deploy-to-kubernetes/add-kubernetes-cluster/)
-- [Manage your Kubernetes cluster]({{site.baseurl}}/docs/deploy-to-kubernetes/manage-kubernetes/)
-- [The environment dashboard]({{site.baseurl}}/docs/deploy-to-kubernetes/environment-dashboard/)
\ No newline at end of file
diff --git a/_docs/deploy-to-kubernetes/environment-dashboard.md b/_docs/deploy-to-kubernetes/environment-dashboard.md
deleted file mode 100644
index fbf0e94c7..000000000
--- a/_docs/deploy-to-kubernetes/environment-dashboard.md
+++ /dev/null
@@ -1,121 +0,0 @@
----
-title: "Environment Dashboard"
-description: "Viewing your deployment environments"
-group: deploy-to-kubernetes
-
-toc: true
----
-
-The [built-in Kubernetes dashboard]({{site.baseurl}}/docs/deploy-to-kubernetes/manage-kubernetes/) is a good way to see what your clusters are doing but it is mostly focused on low level constructs such as pods and docker images. The [Helm environment dashboard]({{site.baseurl}}/docs/new-helm/helm-environment-promotion/) on the other hand offers an application level view of your cluster, but it only applies to Helm deployments.
-
-To bridge this gap, Codefresh also offers a Environment Dashboard for both Kubernetes and Helm releases that allows you to see cluster status in addition to what the pipelines are doing.
-
-{% include
-image.html
-lightbox="true"
-file="/images/codefresh-yaml/environments/environments.png"
-url="/images/codefresh-yaml/environments/environments.png"
-alt="Codefresh Environment Dashboard"
-caption="Codefresh Environment Dashboard"
-max-width="70%"
-%}
-
-The environment dashboard is configurable and each environment can represent a plain Kubernetes deployment or a Helm release. You can access the dashboard by clicking on *Environments* from the left sidebar in Codefresh.
-
-
-## How environments work
-
-The purpose of an environment is to give you an overview of both the cluster status as well as the builds that affect it. The environment acts as a link between the status of builds and the status of the cluster.
-
-
-{% include
-image.html
-lightbox="true"
-file="/images/kubernetes/environments/environment-info.png"
-url="/images/kubernetes/environments/environment-info.png"
-alt="Components of an environment"
-caption="Components of an environment"
-max-width="100%"
-%}
-
-A Codefresh environment is based on two components
-
-* a cluster namespace that holds a deployment/service (or a Helm release in the case of Helm)
-* an association between builds and this cluster
-
-When you visit the environment screen you can see consolidated information on what your environment is doing. Codefresh will pull live data from the cluster to populate the status bar of each environment entry and will automatically show the status of the last 3 builds that affected this environment.
-
-The overall status of the environment (shown as a green or red label at the top of the environment card) is the exit result of the last build that affected that environment.
-
-The URL shown at the environment is just a shortcut link that allows you to quickly visit the user application exposed by the environment (if this is applicable). It is not used by Codefresh for anything else (i.e. Codefresh does *not* check it to actually decide if an environment is healthy).
-
-
-## Creating an environment
-
-You can create an environment in two ways:
-
-* Describe the environment details in the any pipeline that affects it using the [special env syntax]({{site.baseurl}}/docs/codefresh-yaml/deployment-environments/). The first time the pipeline runs, the environment GUI entry will be created automatically in the dashboard
-* Create the environment details yourself straight from the Codefresh UI
-
-To create an environment while in the dashboard screen, click the *New environment* button on the top right corner and fill in the required details:
-
-{% include
-image.html
-lightbox="true"
-file="/images/kubernetes/environments/create-environment.png"
-url="/images/kubernetes/environments/create-environment.png"
-alt="Creating an environment from the GUI"
-caption="Creating an environment from the GUI"
-max-width="50%"
-%}
-
-When you create an environment for your application, you can define the following:
-* Helm boards: Namespace, Cluster, and Release. Namespace is useful when you have more than one Helm release per namespace, or you have the same Helm release in more than one namespace.
-* Kubernetes boards: Release, Cluster, and Namespace.
-
-Once you create the environment, Codefresh will pull automatically the status of pods/deployments/services from the cluster and show it at the environment status bar. To link specific pipelines to that environment follow the [env syntax guide]({{site.baseurl}}/docs/codefresh-yaml/deployment-environments/).
-
-You can also combine the two ways by first creating an environment in the GUI and then associating it with a pipeline. But notice that in that case the environment details you selected in the GUI must **EXACTLY** match those defined in the pipeline (so that the pipeline can detect which environment entry it should update).
-
-## Understanding cluster issues
-
-There is no restriction to the number of pipelines linked to an environment (and the number of environments affected by a single pipeline). In fact the true power of the environment dashboard becomes evident when you link multiple pipelines to a single environment.
-
-One of the most common deployment issues are errors in configuration. Instead of just linking pipelines that deploy applications, you should instead link *all* types of pipelines that affect a cluster. These pipelines can contains
-
-* application deployments
-* cluster component changes
-* configuration changes (e.g. configmaps or secrets)
-* database changesets
-
-This means that the environment entry will have a history of *all* changes that happened on the cluster and not just application deployments. Ideally no manual change should happen to the cluster outside of a pipeline.
-
-{% include
-image.html
-lightbox="true"
-file="/images/kubernetes/environments/error-detection.png"
-url="/images/kubernetes/environments/error-detection.png"
-alt="Looking at the history of an environment"
-caption="Looking at the history of an environment"
-max-width="100%"
-%}
-
-Here we have a classic deployment issue where an application is deployed on the cluster and fails, even thought the exact same application tag was previously successful.
-
-Because that team that created this dashboard also linked the pipeline that does configuration changes to the cluster, it is clear that there was a configmap change between the two application deployments. Even though the configuration change itself was successful, the application deployment failed the second time because of it.
-
-With the environment dashboard it is very easy to understand that the configuration change was responsible for breaking the next deployment. An operator can now look at the configuration change and talk with a developer that knows what the application needs and why it failed.
-
-Therefore make sure to link all pipelines that affect a cluster in the environment dashboard and not just application deployments.
-
-
-
-
-## What to read next
-
-- [How to update environment status from builds]({{site.baseurl}}/docs/codefresh-yaml/deployment-environments/)
-- [Add your cluster]({{site.baseurl}}/docs/deploy-to-kubernetes/add-kubernetes-cluster/)
-- [Manage your Kubernetes cluster]({{site.baseurl}}/docs/deploy-to-kubernetes/manage-kubernetes/)
-- [Helm environment board]({{site.baseurl}}/docs/new-helm/helm-environment-promotion/)
-
-
diff --git a/_docs/deploy-to-kubernetes/example-deploy-demochat-to-kubernetes-cluster.md b/_docs/deploy-to-kubernetes/example-deploy-demochat-to-kubernetes-cluster.md
deleted file mode 100644
index 6374453c2..000000000
--- a/_docs/deploy-to-kubernetes/example-deploy-demochat-to-kubernetes-cluster.md
+++ /dev/null
@@ -1,158 +0,0 @@
----
-title: "Example - Deploy demochat to Kubernetes cluster"
-description: "An end-to-end example for Kubernetes deployment"
-group: deploy-to-kubernetes
-permalink: /:collection/deploy-to-kubernetes/codefresh-kubernetes-integration-demochat-example/
-toc: true
----
-In this example we will deploy our `demochat` application to Kubernetes. `demochat` requires two services to run:
-
-1. MongoDB
-1. `demochat` webserver that is implemented in Node and can be found at [https://github.com/containers101/demochat](https://github.com/containers101/demochat)
-
-We will perfom the following steps:
-
-1. Build the Docker image for `demochat`
-1. Deploy the `demochat` service to a Kubernetes cluster
-1. Access the running `demochat` service
-1. Automate `demochat` deployment using a Codefresh pipeline
-
-{{site.data.callout.callout_info}}
-##### Demochat source code
-
-The Demochat repository can be found and forked from here:
-[https://github.com/containers101/demochat](https://github.com/containers101/demochat){:target="_blank"}
-{{site.data.callout.end}}
-
-{:.text-secondary}
-
-## Building the Docker image for Demochat
-
-Become familiar with basic Codefresh pipelines as explained in the [quick start guide]({{site.baseurl}}/docs/getting-started/create-a-basic-pipeline/) and then:
-
-1. Add your forked `demochat` repo in Codefresh (use the url above to find the repo).
-1. Choose the branch for your first build (in this case `master`).
-1. Select how you would like to setup your repository. In this case, our repo already has a Dockerfile, so we will select the middle option.
-1. Clicking on `Build` button will trigger a regular build.
-1. When the docker image will be created, go to the tab `Images` to find the image `containers101/demochat`
-
-{{site.data.callout.callout_warning}}
-More info about how to add, build and push docker image you can find in the readme of repository [https://github.com/containers101/demochat](https://github.com/containers101/demochat){:target="_blank"}
-{{site.data.callout.end}}
-
-{:.text-secondary}
-
-## Deploying the Demochat service to a Kubernetes cluster
-
-{:start="1"}
-1. Go to your Account Configuration, by clicking on *Account Settings* on the left sidebar. On the first section called *Integrations* click the *Configure* button next to *Kubernetes*.
-
-{:start="2"}
-2. [Add your Kubernetes cluster]({{site.baseurl}}/docs/deploy-to-kubernetes/add-kubernetes-cluster/).
-
-{% include image.html
- lightbox="true"
- file="/images/integrations/codefresh-integrations.png"
- url="/images/integrations/codefresh-integrations.png"
- alt="Codefresh integrations"
- max-width="60%"
- %}
-
-{:start="3"}
-3. Exit your account settings and then select `Kubernetes` from the left sidebar to access your [Kubernetes dashboard]({{site.baseurl}}/docs/deploy-to-kubernetes/manage-kubernetes/). Click on the button `Add New Service`.
-
-{:start="4"}
-4. The `demochat` application uses a Mongo database, therefore we need to add a `mongo` service with the following params (see the screenshot below).
-
-{% include image.html
-lightbox="true"
-file="/images/kubernetes/demo/mongo-service.png"
-url="/images/kubernetes/demo/mongo-service.png"
-alt="Deploy mongo service"
-caption="Deploy mongo service"
-max-width="50%"
-%}
-
-{:start="5"}
-5. Then just click on the button `Deploy`.
-
-{:start="6"}
-6. The mongo service will appear on your Kubernetes dashboard.
-
-{:start="7"}
-7. Click on the button `Add New Service` to create a Demochat service.
-
-{:start="8"}
-8. Use the screenshot below to specify the parameters of Demochat service.
-
-{: .table .table-bordered .table-hover}
-| Parameter | Value |
-|:-------------------|:------------------------------------------|
-| **CLUSTER** | choose one of your clusters |
-| **NAMESPACE** | choose the namespace in the dropdown list |
-| **SERVICE NAME** | Demochat |
-| **REPLICAS** | 1 |
-| **EXPOSE PORT** | 5000 |
-| **IMAGE** | containers101/demochat |
-| **INTERNAL PORTS** | 5000 |
-
-{% include image.html
-lightbox="true"
-file="/images/kubernetes/demo/configure-service.png"
-url="/images/kubernetes/demo/configure-service.png"
-alt="Configure mongo service"
-caption="Configure mongo service"
-max-width="50%"
-%}
-
-
-## Accessing the Demochat service
-
-On the `Kubernetes` tab you can see the `demochat` and `mongo` services.
-
-{% include image.html
-lightbox="true"
-file="/images/kubernetes/demo/services.png"
-url="/images/kubernetes/demo/services.png"
-alt="Kubernetes Services"
-caption="Kubernetes Services"
-max-width="70%"
-%}
-
-
-The Demochat application is now successfully deployed!
-You can see the external endpoints of this service in the service view and access the application using its endpoint and port.
-
-{% include image.html
-lightbox="true"
-file="/images/1f7db93-codefresh_external_endpoints.png"
-url="/images/1f7db93-codefresh_external_endpoints.png"
-alt="codefresh_external_endpoints.png"
-max-width="50%"
-%}
-
-Click on the external endpoint and your browser window will open to show the running application.
-
-{% include image.html
-lightbox="true"
-file="/images/324f2ba-codefresh_demochat_endpoint.jpg"
-url="/images/324f2ba-codefresh_demochat_endpoint.jpg"
-alt="codefresh_demochat_endpoint.png"
-max-width="50%"
-%}
-
-
-## Automating Demochat deployment using Codefresh pipelines
-
-For automated Kubernetes deployments check the documentation for
-
-1. The dedicated [deploy step]({{site.baseurl}}/docs/codefresh-yaml/steps/deploy/) in a pipeline.
-1. The [cf-deploy-kubernetes step]({{site.baseurl}}/docs/deploy-to-kubernetes/kubernetes-templating/) in a pipeline. This can also perform simple templating on Kubernetes manifests.
-1. Using a [freestyle]({{site.baseurl}}/docs/codefresh-yaml/steps/freestyle/) step with [custom kubectl commands]({{site.baseurl}}/docs/deploy-to-kubernetes/custom-kubectl-commands/).
-1. Using The Helm package manager. See the [Helm quick start guide]({{site.baseurl}}/docs/getting-started/helm-quick-start-guide/).
-
-## What to read next
-
-- [Deploy to Kubernetes - quick start]({{site.baseurl}}/docs/getting-started/deployment-to-kubernetes-quick-start-guide/)
-- [Deploying to Kubernetes with Helm]({{site.baseurl}}/docs/getting-started/helm-quick-start-guide/)
-- [Manage your Kubernetes cluster]({{site.baseurl}}/docs/deploy-to-kubernetes/manage-kubernetes/)
diff --git a/_docs/deploy-to-kubernetes/kubernetes-templating.md b/_docs/deploy-to-kubernetes/kubernetes-templating.md
deleted file mode 100644
index 816fcf525..000000000
--- a/_docs/deploy-to-kubernetes/kubernetes-templating.md
+++ /dev/null
@@ -1,213 +0,0 @@
----
-title: "Simple Kubernetes templating"
-description: "How to use templates in your Kubernetes manifests"
-group: deploy-to-kubernetes
-toc: true
----
-
-Once you start working with Kubernetes you will see the need for using templates in Kubernetes manifests for common parameters such as:
-
-* The docker image name of a deployment
-* The docker image tag of a deployment
-* Number of replicas
-* Service labels
-* Configmaps and other settings
-
-Kubernetes does not provide any templating mechanism on its own. Deployed manifests are expected to be static yaml files. An external solution is needed if you want to pass parameters in your manifests.
-
-The proper way to handle templates is within [Helm]({{site.baseurl}}/docs/getting-started/helm-quick-start-guide/). Helm is the package manager for Kubernetes and also includes templating capabilities.
-
-If you wish to use templates without using Helm there are several templating solutions available including [Kustomize](https://github.com/kubernetes-sigs/kustomize) from Google.
-
-Codefresh also includes its own simple templating mechanism that has built-in integration with all [pipeline variables]({{site.baseurl}}/docs/codefresh-yaml/variables/) as we will explain in this page.
-
-## Using the Codefresh deploy image
-
-Codefresh offers a public docker image at [https://hub.docker.com/r/codefresh/cf-deploy-kubernetes/tags/](https://hub.docker.com/r/codefresh/cf-deploy-kubernetes/tags/) for easy templating of Kubernetes manifests. The source code of the image is at [https://github.com/codefresh-io/cf-deploy-kubernetes](https://github.com/codefresh-io/cf-deploy-kubernetes). This image can be used in a freestyle step like this:
-
-`YAML`
-{% highlight yaml %}
-{% raw %}
- MyDeploy:
- title: K8s Deploy
- image: codefresh/cf-deploy-kubernetes:master
- commands:
- - /cf-deploy-kubernetes deployment.yml
- environment:
- - KUBECONTEXT=my-cluster-name
- - KUBERNETES_NAMESPACE=my-namespace
-{% endraw %}
-{% endhighlight %}
-
-The step accepts the following environment variables:
-
-* `KUBECONTEXT` - corresponds to the name of a cluster added to codefresh.
-* `KUBERNETES_NAMESPACE` - The namespace to deploy.
-* `KUBECTL_ACTION` - means an action for `kubectl `. Valid values are `apply|create|replace` (Default is `apply`).
-* `KUBERNETES_DEPLOYMENT_TIMEOUT` - How much to wait for a successful deployment before failing the build (Defaults to 120 secs).
-
-The step will deploy your deployment to the cluster specified by the context and namespace given. The name of the context is the name of your cluster as seen in the [Kubernetes dashboard]({{site.baseurl}}/docs/deploy-to-kubernetes/manage-kubernetes/#work-with-your-services).
-
-Before the deployment takes place, all Codefresh variables found in the `deployment.yml` file in the form of {% raw %}`{{MY_VARIABLE}}`{% endraw %} will be automatically replaced with their current values.
-
-Here is an example manifest:
-
-`Kubernetes manifest`
-{% highlight yaml %}
-{% raw %}
-apiVersion: extensions/v1beta1
-kind: Deployment
-metadata:
- name: my-demo-app
- annotations:
- branch: {{CF_BRANCH_TAG_NORMALIZED}}
- source-repository: {{CF_REPO_NAME}}
-spec:
- replicas: 4
- template:
- metadata:
- labels:
- name: my-demo-app
- app: my-demo-app
- spec:
- containers:
- - name: my-demo-app
- image: r.cfcr.io/{{CF_ACCOUNT}}/my-sample-application:{{CF_SHORT_REVISION}}
- imagePullPolicy: Always
- ports:
- - name: http
- containerPort: 8080
- protocol: TCP
-{% endraw %}
-{% endhighlight %}
-
-In this case the image will get the replacement for your Codefresh account name and the tag will use the git revision. Metadata annotations are also defined with value from the branch name and the git repository name.
-
-Notice that the variables are declared as {% raw %}`{{MY_VARIABLE}}`{% endraw %} form and **NOT** {% raw %}`${{MY_VARIABLE}}`{% endraw %} which is how they are used inside the [Codefresh yaml]({{site.baseurl}}/docs/codefresh-yaml/what-is-the-codefresh-yaml/) definition.
-
-
-## Creating custom manifest replacements
-
-Apart from the built-in [Codefresh variables]({{site.baseurl}}/docs/codefresh-yaml/variables/) you can also create any variable on your own using the same replacement syntax. Here is an example manifest.
-
-`Kubernetes manifest`
-{% highlight yaml %}
-{% raw %}
-apiVersion: extensions/v1beta1
-kind: Deployment
-metadata:
- name: my-demo-app
- annotations:
- source-repository: {{CF_REPO_NAME}}
- branch: {{CF_BRANCH_TAG_NORMALIZED}}
- custom-label: {{MY_CUSTOM_LABEL}}
-spec:
- replicas: {{MY_REPLICA_NUMBER}}
- template:
- metadata:
- labels:
- name: my-demo-app
- app: my-demo-app
- spec:
- containers:
- - name: my-demo-app
- image: r.cfcr.io/{{CF_ACCOUNT}}/my-sample-application:{{CF_SHORT_REVISION}}
- imagePullPolicy: Always
- ports:
- - name: http
- containerPort: 8080
- protocol: TCP
- imagePullSecrets:
- - name: {{PULL_SECRET}}
-{% endraw %}
-{% endhighlight %}
-
-Here you can see custom variables for an annotation, the replica number and the pull secret (in addition with the standard variables).
-You can provide the values for your custom variables as environment parameters in the freestyle step.
-
-`codefresh.yaml`
-{% highlight yaml %}
-{% raw %}
-version: '1.0'
-steps:
- BuildingDockerImage:
- title: Building Docker Image
- type: build
- image_name: my-sample-application
- tag: '${{CF_SHORT_REVISION}}'
- dockerfile: Dockerfile
- MyDeploy:
- title: K8s Deploy
- image: codefresh/cf-deploy-kubernetes:master
- commands:
- - /cf-deploy-kubernetes deployment.yml
- environment:
- - KUBECONTEXT=k8s-demo@Google
- - KUBERNETES_NAMESPACE=my-namespace
- - MY_CUSTOM_LABEL=build-id-${{CF_BUILD_ID}}
- - MY_REPLICA_NUMBER=3
- - PULL_SECRET=codefresh-generated-r.cfcr.io-cfcr-my-namespace
-{% endraw %}
-{% endhighlight %}
-
-In the environment section you can see the values for the custom variables. We set the replica number to 3, a full string for the pull secret and a concatenated string for the annotation.
-
-## Using replacements in multiple manifests
-
-By default, the deploy step will only do replacements in a single manifest. If you have multiple Kubernetes manifests you can merge all of them in a single file, or use multiple times the deploy commands like this:
-
-`codefresh.yml`
-{% highlight yaml %}
-{% raw %}
- MyDeploy:
- title: K8s Deploy
- image: codefresh/cf-deploy-kubernetes:master
- commands:
- - /cf-deploy-kubernetes deployment.yml
- - /cf-deploy-kubernetes service.yml
- - /cf-deploy-kubernetes config-map.yml
- environment:
- - KUBECONTEXT=my-cluster-name
- - KUBERNETES_NAMESPACE=my-namespace
- - MY_REPLICA_NUMBER=3
- - KUBERNETES_DEPLOYMENT_TIMEOUT=360
-{% endraw %}
-{% endhighlight %}
-
-Variable replacements will happen in all manifests before they are deployed.
-
-
-## Using Unix command line tools for templates
-
-It is also perfectly possible to use any Unix templating or text editing tool such as `sed` or `awk` to perform text replacements in Kubernetes manifests.
-
-As a very simple example you could a replacement with the following [freestyle step]({{site.baseurl}}/docs/codefresh-yaml/steps/freestyle/) in your Codefresh pipeline.
-
-`YAML`
-{% highlight yaml %}
-{% raw %}
-version: '1.0'
-steps:
- my_replacement:
- image: alpine
- commands:
- # replace every ${TAG} with current TAG variable value
- - sed -i 's/${TAG}/${{TAG}}/g' my-k8s-deployment.yaml
-{% endraw %}
-{% endhighlight %}
-
-## What to read next
-
-* [Connnecting to your cluster]({{site.baseurl}}/docs/deploy-to-kubernetes/add-kubernetes-cluster/)
-* [Managing your cluster]({{site.baseurl}}/docs/deploy-to-kubernetes/manage-kubernetes/)
-* [Accessing a docker registry]({{site.baseurl}}/docs/deploy-to-kubernetes/access-docker-registry-from-kubernetes/)
-* [Running custom kubectl commands]({{site.baseurl}}/docs/deploy-to-kubernetes/custom-kubectl-commands/)
-
-
-
-
-
-
-
-
-
\ No newline at end of file
diff --git a/_docs/deploy-to-kubernetes/manage-kubernetes.md b/_docs/deploy-to-kubernetes/manage-kubernetes.md
deleted file mode 100644
index 87f7b9888..000000000
--- a/_docs/deploy-to-kubernetes/manage-kubernetes.md
+++ /dev/null
@@ -1,168 +0,0 @@
----
-title: "Manage your Kubernetes cluster"
-description: "Using the graphical Kubernetes Dashboard in Codefresh"
-group: deploy-to-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 cluster(s) and even make changes if you have the appropriate access privileges.
-
-## Accessing the Kubernetes Dashboard
-
-After [adding a cluster]({{site.baseurl}}/docs/deploy-to-kubernetes/add-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/docker-registries/external-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/d07104d-Screen_Shot_2017-07-23_at_6.46.17_PM.png"
-url="/images/d07104d-Screen_Shot_2017-07-23_at_6.46.17_PM.png"
-alt="Deploying with the quick GUI dialog"
-caption="Deploying with the quick GUI 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/11c15f3-Screen_Shot_2017-09-06_at_6.28.30_PM.png"
-url="/images/11c15f3-Screen_Shot_2017-09-06_at_6.28.30_PM.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/deploy-to-kubernetes/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/58ac43c-Screen_Shot_2017-07-23_at_6.42.58_PM.png"
-url="/images/58ac43c-Screen_Shot_2017-07-23_at_6.42.58_PM.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 advance 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/cc01a9f-Pasted_image_at_2017_07_23_03_17_PM.png"
-url="/images/cc01a9f-Pasted_image_at_2017_07_23_03_17_PM.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/7238315-Pasted_image_at_2017_07_23_03_18_PM.png"
-url="/images/7238315-Pasted_image_at_2017_07_23_03_18_PM.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/codefresh-yaml/steps/deploy/) in a pipeline.
-1. The [cf-deploy-kubernetes step]({{site.baseurl}}/docs/deploy-to-kubernetes/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/deploy-to-kubernetes/deployment-options-to-kubernetes/).
-
-## What to read next
-
-- [Environment dashboard]({{site.baseurl}}/docs/deploy-to-kubernetes/environment-dashboard/)
-- [Add Config Maps]({{site.baseurl}}/docs/deploy-to-kubernetes/add-config-maps-to-your-namespaces/)
-- [Manage your Kubernetes cluster]({{site.baseurl}}/docs/deploy-to-kubernetes/manage-kubernetes/)
-- [Deploy to Kubernetes - quick start]({{site.baseurl}}/docs/getting-started/deployment-to-kubernetes-quick-start-guide/)
-
-
diff --git a/_docs/deployments/gitops.md b/_docs/deployments/gitops.md
new file mode 100644
index 000000000..a0ab3931f
--- /dev/null
+++ b/_docs/deployments/gitops.md
@@ -0,0 +1,18 @@
+---
+title: "Deploy with GitOps"
+description: "Learn how Codefresh deploys GitOps applications"
+group: deployments
+toc: true
+---
+
+Codefresh has a native module for GitOps deployments powered by Argo CD and Argo Rollouts. It also has native support for Argo Events and Argo Workflows.
+
+* Create a [GitOps Application]({{site.baseurl}}/docs/deployments/helm/managed-helm-repository/) either from the GUI or the CLI.
+* [Monitor your GitOps applications]({{site.baseurl}}/docs/deployments/helm/helm-charts-and-repositories/) and check their health status
+* You can [edit/delete/rollback]({{site.baseurl}}/docs/deployments/helm/helm-releases-management/) applications while still keeping the state in Git.
+* Perform [Canary releases]({{site.baseurl}}/docs/deployments/helm/helm-environment-promotion/) via the dedicated UI
+
+
+
+
+
diff --git a/_docs/deployments/gitops/applications-dashboard.md b/_docs/deployments/gitops/applications-dashboard.md
new file mode 100644
index 000000000..7038bbeeb
--- /dev/null
+++ b/_docs/deployments/gitops/applications-dashboard.md
@@ -0,0 +1,685 @@
+---
+title: "Monitoring GitOps applications"
+description: ""
+group: deployments
+sub_group: gitops
+toc: true
+---
+
+Monitor applications across clusters, and the deployments, resources, and services for an application in the GitOps Apps dashboard. As a one-stop shop for Argo Rollouts and Argo CD, the GitOps Apps dashboard in Codefresh delivers on the challenge of keeping track of your applications and their deployments, whatever the frequency and scale, across all clusters in your enterprise. A wide range of filters, progressive delivery views, and enriched CI and CD information, provide full traceability and visibility to your deployments.
+
+Select the view format for the GitOps Apps dashboard, as either [List or Card views](#select-view-mode-for-the-gitops-apps-dashboard). The default view displays all applications deployed within the last 30 days. Customize the scope through filters to display the [information](#/#gitops-apps-dashboard-information) you need.
+
+{% include
+image.html
+lightbox="true"
+file="/images/applications/app-dashboard-main-view.png"
+url="/images/applications/app-dashboard-main-view.png"
+alt="GitOps Apps dashboard: List view"
+caption="GitOps Apps dashboard: List view"
+max-width="60%"
+%}
+
+
+Identify applications with [health and sync errors](#identify-applications-with-warningserrors), and then select an application to drill down into its resources, deployments, and services:
+* [Get status from application header](#get-status-from-application-header)
+* [View deployment and configuration info for selected application](#view-deployment-and-configuration-info-for-selected-application)
+* [Monitor resources for selected application](#monitor-resources-for-selected-application)
+* [Monitor deployments for selected application](#monitor-deployments-for-selected-application)
+* [Monitor services for selected application](#monitor-services-for-selected-application)
+
+>For information on creating and managing applications and application resources, see [Creating GitOps applications]({{site.baseurl}}/docs/deployments/gitops/create-application/) and [Managing GitOps applications]({{site.baseurl}}/docs/deployments/gitops/manage-application/).
+
+## Select view mode for the GitOps Apps dashboard
+View deployed applications in either List (the default) or Card views. Both views are sorted by the most recent deployments.
+
+1. In the Codefresh UI, from Ops in the sidebar, select [GitOps Apps](https://g.codefresh.io/2.0/applications-dashboard/list){:target="\_blank"}.
+1. Select **List** or **Cards**.
+
+### Applications List view
+
+Here is an example of the GitOps Apps dashboard in List view mode.
+
+{% include
+image.html
+lightbox="true"
+file="/images/applications/app-dashboard-main-view.png"
+url="/images/applications/app-dashboard-main-view.png"
+alt="GitOps Apps dashboard: List view"
+caption="GitOps Apps dashboard: List view"
+max-width="60%"
+%}
+
+### Applications Card view
+Here is an example of the GitOps Apps dashboard in Card view mode. The Card view provides a scannable view of application data and the actions to manage applications.
+
+ {% include
+image.html
+lightbox="true"
+file="/images/applications/app-dashboard-card-view.png"
+url="/images/applications/app-dashboard-card-view.png"
+alt="GitOps Apps dashboard: Card view"
+caption="GitOps Apps dashboard: Card view"
+max-width="60%"
+%}
+
+## GitOps Apps dashboard information
+Here's a description of the information and actions in the GitOps Apps dashboard.
+
+{: .table .table-bordered .table-hover}
+| Item | Description |
+| -------------- | -------------- |
+|Application filters | Filter by a range of attributes to customize the information in the dashboard to bring you what you need. {::nomarkdown}
Application state A snapshot that displays a breakdown of the deployed applications by their health status. Click a status to filter by applications that match it. Codefresh tracks Argo CD's set of health statuses. See the official documentation on Health sets.
Application attributes Attribute filters support multi-selection, and results are based on an OR relationship within the same filter with multiple options, and an AND relationship between filters. Clicking More Filters gives you options to filter by Health status, Cluster names, Namespace, and Type.
Application Type: Can be any of the following
Applications: Standalone applications. See the official documentation on Applications.
ApplicationSet: Applications created using the ApplicationSet Custom Resource (CR) template. An ApplicationSet can generate single or multiple applications. See the official documentation on Generating Applications with ApplicationSet.
Git Source: Applications created by Codefresh that includes other applications and CI resources. See Git Sources.
Labels:The K8s labels defined for the applications. The list displays labels of all the applications, even if you have applied filters. To see the available labels, select Add, and then select the required label and one or more values. To filter by the labels, select Add and then Apply. See the official documentation on Labels and selectors.
{:/}|
+|{::nomarkdown}{:/}| Star applications as favorites and view only the starred applications.{::nomarkdown} Select the to star the application as a favorite.
To filter by favorite applications, on the filters bar, select . {:/} TIP: If you star applications as favorites in the GitOps Apps dashboard, you can filter by the same applications in the [DORA metrics dashboard]({{site.baseurl}}/docs/dashboards/dora-metrics/#metrics-for-favorite-applications). |
+|Application actions| Options to monitor/manage applications through the application's context menu. {::nomarkdown}
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.
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.
{:/} |
+
+
+## Identify applications with warnings/errors
+Errors are flagged in the **Warnings/Errors** button, displayed at the top right of the GitOps Apps dashboard. Clicking the button shows the list of applications with the warnings/errors and the possible reasons for these.
+
+{% include
+image.html
+lightbox="true"
+file="/images/applications/app-dashboard-warnings-errors.png"
+url="/images/applications/app-dashboard-warnings-errors.png"
+alt="Example of warning and error notifications for applications"
+caption="Example of warning and error notifications for applications"
+max-width="60%"
+%}
+
+Every notification identifies:
+* The type of resource with the problem (`Application`, `Deployment`, `Pod`)
+* If it is health or sync related
+* If it is a warning or error.
+
+All errors are Argo CD-generated errors. Codefresh generates custom warnings for the following:
+
+{::nomarkdown}
+
+{:/}
+
+### 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 GitOps Apps dashboard and control rollout steps with the Rollout Player.
+
+**Corrective Action**: Click **Install** and install Argo Rollouts on the target cluster.
+
+{::nomarkdown}
+
+{:/}
+
+### Warning: Long sync
+**Reason**: Ongoing sync for application exceeds 30 minutes (Argo CD's default duration for a sync operation).
+
+**Corrective Action**:
+* Click **View Details** to take you directly to the Sync Result tab.
+ Here you can see details on the sync job that was started, and info on the Hooks if any. Failed hooks are dsiplayed at the top.
+* To see more details such as the message and sync duration, switch to **Sync Info**.
+* To stop the sync operation, click **Terminate**.
+* Drill down into the application to investigate the issue and make changes.
+
+## Get status from application header
+When you select an application from the GitOps Apps dashboard, the application header is displayed at the top of the page with important information on the application.
+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.
+For example, it displays the health, current and previous sync operation results, and indicates if auto-sync is enabled or disabled for the application. Sync statuses also have **More** links that display details such as the date, tags, and message.
+
+{% include
+image.html
+lightbox="true"
+file="/images/applications/application-header.png"
+url="/images/applications/application-header.png"
+alt="Application header for selected application"
+caption="Application header for selected application"
+max-width="80%"
+%}
+
+>Tip:
+ You can also view the current health and sync status for the application as a resource in the Current State tab.
+
+## 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.
+Access the Quick View from the GitOps Apps dashboard, either from the application's context menu, or after drilldown, from the Current State tab.
+
+1. In the Codefresh UI, from Ops in the sidebar, select [GitOps Apps](https://g.codefresh.io/2.0/applications-dashboard/list){:target="\_blank"}.
+1. Do one of the following:
+ * From the List or Card views, select the context menu and then select **Quick View**.
+
+{% include
+image.html
+lightbox="true"
+file="/images/applications/quick-view-context-menu.png"
+url="/images/applications/quick-view-context-menu.png"
+alt="Selecting Quick View from the context menu"
+caption="Selecting Quick View from the context menu"
+max-width="80%"
+%}
+
+ * Select the application, and from the application header's context menu on the right, select **Details**.
+
+ {% include
+image.html
+lightbox="true"
+file="/images/applications/app-header-view-details.png"
+url="/images/applications/app-header-view-details.png"
+alt="View app details from the application header context menu"
+caption="View app details from the application header context menu"
+max-width="80%"
+%}
+
+ * Select the application, and in the Current State tab, click the parent application resource.
+
+{% include
+image.html
+lightbox="true"
+file="/images/applications/quick-view-access-app-resource.png"
+url="/images/applications/quick-view-access-app-resource.png"
+alt="Accessing Quick View from the Current State tab"
+caption="Accessing Quick View from the Current State tab"
+max-width="60%"
+%}
+
+The Quick View includes the following tabs:
+* Summary: Displays health, sync status, and source and destination definitions.
+* Metadata: Displays labels and annotations for the application.
+* 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`, `Helm` charts, or `Kustomize` manifests, or the specific plugin.
+* Sync Options: Displays the sync options enabled for the application.
+* Manifest: Displays the YAML version of the application manifest.
+* Events: Displays status and sync events for the 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 GitOps Apps dashboard takes you to the Current State tab, which as its title indicates, displays the
+live state of the application's resources (Kubernetes objects) on the cluster, including health, sync state, manifests, and logs.
+
+{% include
+image.html
+lightbox="true"
+file="/images/applications/app-resources-monitor-screen.png"
+url="/images/applications/app-resources-monitor-screen.png"
+alt="Monitor application resources in Current State tab"
+caption="Monitor application resources in Current State tab"
+max-width="60%"
+%}
+
+The icon for a resource node identifies the type of Kubernetes resource it represents. For general information on K8s resources, see [Working with Kubernetes objects](https://kubernetes.io/docs/concepts/overview/working-with-objects/){:target="\_blank"}.
+
+You can view application resources in [List or Tree views](#view-modes-for-application-resources), [set filters](#filters-for-application-resources), and monitor:
+* [Health status](#health-status-for-application-resources)
+* [Sync status](#sync-status-for-application-resources)
+* [Manifests](#manifests-for-application-resources)
+* [Logs](#logs-for-application-resources)
+* [Events](#events-for-application-resources)
+
+
+
+### View modes for application resources
+
+The Current State tab supports Tree and List view formats.
+* Tree view (default): A hierarchical, interactive visualization of the application and its resources. Useful for complex deployments with multiple clusters and large numbers of resources. See also [Working with resources in Tree view](#working-with-resources-in-tree-view).
+Here is an example of the Current State in Tree view.
+
+
+{% include
+image.html
+lightbox="true"
+file="/images/applications/current-state-tree-app-in-progress.png"
+url="/images/applications/current-state-tree-app-in-progress.png"
+alt="Tree view of application resources in Current State"
+caption="Tree view of application resources in Current State"
+max-width="50%"
+%}
+
+* List View: A list-based representation of application's resources, sorted by the Last Update.
+ Here is an example of the Current State in List view.
+
+{% include
+image.html
+lightbox="true"
+file="/images/applications/apps-current-state.png"
+url="/images/applications/apps-current-state.png"
+alt="List view of application resources in Current State"
+caption="List view of application resources in Current State"
+max-width="50%"
+%}
+
+
+
+
+#### 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**
+Every resource has a context menu that opens on clicking the three dots on the right of the node. The options available differ according to the type of resource.
+
+{% include
+image.html
+lightbox="true"
+file="/images/applications/current-state-resource-context-menu.png"
+url="/images/applications/current-state-resource-context-menu.png"
+alt="Current State Tree view: Resource context menu"
+caption="Current State Tree view: Resource context menu"
+max-width="50%"
+%}
+
+**Resource info**
+Mouse over a node to see a tooltip for that resource. For detailed information, select the resource.
+
+{% include
+image.html
+lightbox="true"
+file="/images/applications/current-state-resource-summary.png"
+url="/images/applications/current-state-resource-summary.png"
+alt="Current State Tree view: Resource tooltip"
+caption="Current State Tree view: Resource tooltip"
+max-width="50%"
+%}
+
+**Search resources**
+Quickly find a resource by typing the resource name in the search field. You can identify search results through the border which is different from the borders depicting health status. Press Enter to navigate to the next result.
+
+{% include
+image.html
+lightbox="true"
+file="/images/applications/current-state-tree-search.png"
+url="/images/applications/current-state-tree-search.png"
+alt="Current State Tree view: Search resources"
+caption="Current State: Search resources"
+max-width="50%"
+%}
+
+
+
+**Resource inventory**
+The Resource inventory in the Tree view (bottom-left), summarizes the aggregated count for each resource type in the application. The number of `out-of-sync` items for that resource type if any are numbered in red.
+
+Click-filters:
+
+Selecting any resource type, filters the Current State by that resource type and sync status.
+These filters are automatically applied to the default filter list for both Tree and List views.
+Here's an example of an application with out-of-sync resources, and the result on selecting an out-of-sync resource type.
+
+
+{% include
+image.html
+lightbox="true"
+file="/images/applications/current-state-tree-resource-filtered.png"
+url="/images/applications/current-state-tree-resource-filtered.png"
+alt="Current State Tree view: Resource inventory filtered by Rollouts"
+caption="Current State Tree view: Resource inventory filtered by Rollouts"
+max-width="50%"
+%}
+
+
+### 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.
+
+>The `IgnoreExtraneous` filter applies only to the sync status. The health status of the resource directly affects the application's health status. If the resource is degraded, then the application is also degraded.
+
+**For the `IgnoreExtraneous` filter to be effective:**
+
+* Add `IgnoreExtraneous` as an annotation to the resource, as in the example below of the `ConfigMap` resource.
+
+{% include
+image.html
+lightbox="true"
+file="/images/applications/current-state-ignore-extraneous-annotation.png"
+url="/images/applications/current-state-ignore-extraneous-annotation.png"
+alt="Resource with IgnoreExtraneous annotation"
+caption="Resource with IgnoreExtraneous annotation"
+max-width="50%"
+%}
+
+* In the Current State tab, click the `IgnoreExtraneous` filter.
+ You can see that the `IgnoreExtraneous` filter is active and the `ConfigMap` resource is not displayed in the Current State.
+
+{% include
+image.html
+lightbox="true"
+file="/images/applications/current-state-ignore-extraneous-on.png"
+url="/images/applications/current-state-ignore-extraneous-on.png"
+alt="Current State filtered by IgnoreExtraneous resources"
+caption="Current State filtered by IgnoreExtraneous resources"
+max-width="50%"
+%}
+
+
+### 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).
+
+
+{: .table .table-bordered .table-hover}
+| Health status | Description | Display in Tree view |
+| -------------- | ------------| ------------------|
+| **Healthy** | Resource is functioning as required. | {::nomarkdown}{:/} |
+| **Progressing** | Resource is not healthy but can become healthy before the timeout occurs.| {::nomarkdown}{:/} |
+| **Suspended** | Resource is not functioning, and is either suspended or paused. For example, Cron job or a canary rollout.| {::nomarkdown}{:/} |
+| **Missing** | Resource is not present on the cluster. |{::nomarkdown}{:/} |
+| **Degraded** | Resource is not healthy, or a timeout occurred before it could reach a healthy status.| {::nomarkdown}{:/} |
+| **Unknown** | Resource does not have a health status, or the health status is not tracked in Argo CD. For example,`ConfigMaps` resource types. | {::nomarkdown}{:/} |
+
+
+See also [Argo CD's set of health checks](https://argo-cd.readthedocs.io/en/stable/operator-manual/health/){:target="\_blank"}.
+
+
+
+### 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).
+
+The table describes the possible sync statuses for an application resource, and its representation in the Tree view.
+
+{: .table .table-bordered .table-hover}
+| Sync state | Description |Display in Tree view |
+| -------------- | ---------- | ---------- |
+| **Synced** | The live state of the resource on the cluster is identical to the desired state in Git.| {::nomarkdown}{:/} |
+| **Syncing** | The live state of the resource was not identical to the desired state, and is currently being synced.| {::nomarkdown}{:/} |
+| **Out-of-Sync** | {::nomarkdown}The live state is not identical to the desired state. To sync a resource, select the Sync option from the resource's context menu in Tree view. {:/}| {::nomarkdown}{:/} |
+| **Unknown** | The sync status could not be determined. | {::nomarkdown}{:/} |
+
+
+> 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
+
+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.
+
+> To view information for the application resource, select the application node in Tree View. See [Application information](#view-deployment-and-configuration-info-for-selected-application).
+
+
+{% include
+image.html
+lightbox="true"
+file="/images/applications/current-state-resource-summary.png"
+url="/images/applications/current-state-resource-summary.png"
+alt="Current State Tree view: Resource tooltip"
+caption="Current State Tree view: Resource tooltip"
+max-width="50%"
+%}
+
+Here's what you can see and do in the Summary tab:
+> Press Ctrl/Command F to search for strings in the manifest.
+
+* Desired and Live states of the resource manifest:
+ * Managed resources, stored in Git repositories and using Git as the single source of truth, show both the Desired (Git) and the Live (cluster) states.
+ If there are discrepancies between them, the Diff view is displayed, highlighting the differences in both versions for comparison.
+ * Resources that are not stored in Git but live in the cluster, show only the Live state.
+* Share resource details: Copy the URL and send to others in your organization to share the resource details for collaborative review and analysis. Pasting the URL in a browser opens to the same view of the resource.
+* Hide Managed Fields: In the Live state version of the manifest, you can hide managed-field information from the manifest. Managed-fields show information on which field manager manages the field, after Kubernetes introduced `Server Side Apply`. For more information, see [Field Management](https://kubernetes.io/docs/reference/using-api/server-side-apply/#field-management){:target="\_blank"}.
+
+{::nomarkdown}
+
+{:/}
+
+### 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
+image.html
+lightbox="true"
+file="/images/applications/current-state-logs.png"
+url="/images/applications/current-state-logs.png"
+alt="Current State: Logs for resource"
+caption="Current State: Logs for resource"
+max-width="50%"
+%}
+
+
+* Search: Free-text search for any string in the log, using the next and previous buttons to navigate between the results, or Enter for sequential navigation.
+* Wrap: Enable/disable line wrapping
+* Download: Download the complete log into a text file for offline viewing and analysis.
+
+{::nomarkdown}
+
+{:/}
+
+### 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.
+
+The Events tab displays both successful and failed events from Argo CD, starting with the most recent event.
+Argo CD displays events as they occur for an application resource, and retains event information for a duration of 30 minutes. Historical events older than this duration are removed, and the Events tab can be empty if there are no ongoing events.
+
+{% include
+image.html
+lightbox="true"
+file="/images/applications/current-state-events-tab.png"
+url="/images/applications/current-state-events-tab.png"
+alt="Current State: Events for resource"
+caption="Current State: Events for resource"
+max-width="50%"
+%}
+
+
+
+
+
+
+## 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.
+
+The deployment chart displays the day-to-day deployments for the selected time period. Mouse over the dot on the deployment chart for information on historical deployments.
+
+{% include
+image.html
+lightbox="true"
+file="/images/applications/dashboard-timeline-main.png"
+url="/images/applications/dashboard-timeline-main.png"
+alt="GitOps Apps dashboard: Timeline tab"
+caption="GitOps Apps dashboard: Timeline tab"
+max-width="30%"
+%}
+
+You can:
+* [Monitor CI details by deployments](#monitor-ci-details-by-deployment)
+
+* [Monitor rollouts by deployment](#monitor-rollouts-by-deployment)
+
+
+**How to monitor deployments**
+1. If required, set filters to narrow the number of deployments for the selected application.
+1. To view GitOps details for a deployment, in the deployment chart mouse over the dot that represents the deployment.
+1. To view additional details, expand the record for that deployment.
+
+{% include
+image.html
+lightbox="true"
+file="/images/applications/apps-historical-deployment.png"
+url="/images/applications/apps-historical-deployment.png"
+alt="GitOps Apps dashboard: Deployment chart"
+caption="GitOps Apps dashboard: Deployment chart"
+max-width="30%"
+%}
+
+### Monitor CI details by deployment
+
+Each deployment record displays the complete CI history for that deployment.
+
+
+* The **CI Builds** shows the Argo Workflow run in the deployment. Click the build name to see the Argo Workflow in a new browser window.
+* The **Pull Request (PRs)** used for the commit.
+* The Jira **Issues** the PR aims to resolve or has resolved, with the current status.
+* The **Committer** who made the changes.
+
+
+
+
+
+
+
+### 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 **Updated Services**.
+
+Clicking the image name displays the image in the **Images** dashboard.
+
+> 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
+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.
+
+{% include
+image.html
+lightbox="true"
+file="/images/applications/apps-dashboard-rollout-in-progress.png"
+url="/images/applications/apps-dashboard-rollout-in-progress.png"
+alt="Rollout in progress for deployment"
+caption="Rollout in progress for deployment"
+max-width="50%"
+%}
+
+Based on the current state of the rollout, you can pause and resume an ongoing rollout.
+Here is an example of the rollout for the same deployment on completion. All traffic has been routed to the new version.
+
+{% include
+image.html
+lightbox="true"
+file="/images/applications/apps-dashboard-rollout-complete.png"
+url="/images/applications/apps-dashboard-rollout-complete.png"
+alt="Rollout completed for deployment"
+caption="Rollout completed for deployment"
+max-width="50%"
+%}
+
+#### 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.
+
+{% include
+image.html
+lightbox="true"
+file="/images/applications/rollout-player.png"
+url="/images/applications/rollout-player.png"
+alt="Rollout step visualization and Rollout Player"
+caption="Rollout steps and Rollout Player"
+max-width="50%"
+%}
+
+
+The table lists the controls in the Rollout Player to manage an ongoing rollout.
+
+{: .table .table-bordered .table-hover}
+| Rollback player option | Description |
+| -------------- | ------------|
+| **Rollback** | Not available currently. |
+| **Resume** {::nomarkdown} {:/}| Resume a step that has been paused indefinitely. |
+| **Skip step** {::nomarkdown} {:/} | Skip execution of current step. Such steps are marked as Skipped in the rollout visualization. |
+| **Promote full rollout** {::nomarkdown} {:/} | Skip remaining pause, traffic routing, and analysis steps, and deploy the current release. |
+
+
+
+#### 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"}.
+
+If you are running Background Analysis for example, the first step shows the list of analysis metrics.
+
+{% include
+image.html
+lightbox="true"
+file="/images/applications/app-rollout-analysis-template-step.png"
+url="/images/applications/app-rollout-analysis-template-step.png"
+alt="Rollout: Analysis Metrics in Background Analysis"
+caption="Analysis Template: Analysis Metrics in Background Analysis"
+max-width="50%"
+%}
+
+Click the metric link in the step.
+
+{% include
+image.html
+lightbox="true"
+file="/images/applications/app-rollout-run-results-manifest.png"
+url="/images/applications/app-rollout-run-results-manifest.png"
+alt="Analysis Template: Run Results and Manifest for Analysis Metric"
+caption="Analysis Template: Run Results and Manifest for Analysis Metric"
+max-width="50%"
+%}
+
+
+## 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.
+
+For more information, see the official documentation on [Services](https://kubernetes.io/docs/concepts/services-networking/service/){:target="\_blank"}.
+
+{% include
+image.html
+lightbox="true"
+file="/images/applications/apps-dashboard-services.png"
+url="/images/applications/apps-dashboard-services.png"
+alt="GitOps Apps dashboard: Services tab"
+caption="GitOps Apps 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-application)
+[GitOps Overview dashboard]({{site.baseurl}}/docs/dashboards/home-dashboard)
+[DORA metrics]({{site.baseurl}}/docs/dashboards/dora-metrics/)
+
+
diff --git a/_docs/deployments/gitops/create-application.md b/_docs/deployments/gitops/create-application.md
new file mode 100644
index 000000000..b028f438c
--- /dev/null
+++ b/_docs/deployments/gitops/create-application.md
@@ -0,0 +1,258 @@
+---
+title: "Creating GitOps applications"
+description: ""
+group: deployments
+sub_group: gitops
+toc: true
+---
+
+
+
+Codefresh provides all the options and functionality to create and manage Argo CD applications in the Codefresh UI.
+* Create Argo CD applications that are fully GitOps compliant, from generating the application configuration manifest, committing it to Git, and syncing and deploying to the cluster.
+ Creating an application in Codefresh includes:
+ * Application definitions
+ * General configuration settings
+ * Advanced configuration settings
+
+ The Create application wizard guides you through the process of creating an application. For how-to information, see [Create an application](#create-an-application).
+ For example Argo CD applications, see this [repo](https://github.com/oleksandr-codefresh/argocd-example-apps){:target="_blank"}.
+
+* Edit and delete applications
+ Once the application is created and synced to the cluster, it is displayed in the GitOps Apps 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 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.
+
+{% include
+ image.html
+ lightbox="true"
+ file="/images/applications/add-app-definitions.png"
+ url="/images/applications/add-app-definitions.png"
+ alt="Application definitions"
+ caption="Application definitions"
+ max-width="50%"
+ %}
+
+
+## Application: General configuration settings
+
+General configuration settings define the source, destination, and sync policies for the application.
+
+{% include
+ image.html
+ lightbox="true"
+ file="/images/applications/add-app-general-settings.png"
+ url="/images/applications/add-app-general-settings.png"
+ alt="General configuration settings"
+ caption="General configuration settings"
+ max-width="70%"
+ %}
+
+### Source
+The Git repository to be tracked for changes to the application's source code.
+{::nomarkdown}
Repository URL: The Git repo or the Helm package repo with the application source code, to be tracked for changes. If the Argo CD project is not the default project, make sure that the repo has the correct access roles for your application.
Revision and Path: Applies to Git repositories.
Chart: Applies to Helm repositories. The name of the Helm package with all the resource definitions for the application, and the version.
{:/}
+
+{::nomarkdown}
+
+{:/}
+
+### Destination
+The cluster and namespace to which to deploy the application.
+{::nomarkdown}
Cluster: The cluster to which to deploy the application, defined as a URL, or as the user-defined display NAME.
Namespace: The namespace in the cluster to which to deploy the application.
{:/}
+
+{::nomarkdown}
+
+{:/}
+
+### Sync Settings
+#### Sync Policy
+{::nomarkdown}The synchronization policy to apply when there are differences between the desired state in Git and the actual state in the cluster.
Manual: Manually sync the changes from the Argo CD UI.
Automatic: Automatically sync changes, with the following options if selected:
Prune resources:When selected, removes legacy resources that do not exist currently in Git.
Self heal: When selected, always enforces a sync to the desired state in Git, if and when there is a change to the actual state in the cluster. See Automatic self-healing.
{:/}
+
+{::nomarkdown}
+
+{:/}
+
+#### Sync Options
+{::nomarkdown}Common to both manual and automatic sync policies.
Skip schema validation: When selected, bypasses validating the YAML schema.
Auto-create namespace: When selected, automatically create the namespace if the specified namespace does not exist in the cluster.
Prune last: When selected, removes those resources that do not exist in the currently deployed version during the final wave of the sync operation. See Prune last.
Apply out of sync only: When selected, syncs only those resources in the application that have been changed and are OutOfSync, instead of syncing every resource regardless of their state. This option is useful to reduce load and save time when you have thousands of resources in an application. See Selective Sync.
{:/}
+
+{::nomarkdown}
+
+{:/}
+
+#### Prune propagation policy
+{::nomarkdown}Defines how resources are pruned, applying Kubernetes cascading deletion prune policies.
+For more information, see Kubernetes - Cascading deletion.
Foreground: The default prune propagation policy used by Argo CD. With this policy, Kubernetes changes the state of the owner resource to `deletion in progress`, until the controller deletes the dependent resources and finally the owner resource itself.
Background: When selected, Kubernetes deletes the owner resource immediately, and then deletes the dependent resources in the background.
Orphan: When selected, Kubernetes deletes the dependent resources that remain orphaned after the owner resource is deleted.
{:/}
+All Prune propagation policies can be used with:
+**Replace**: When selected, Argo CD executes `kubectl replace` or `kubectl create`, instead of the default `kubectl apply` to enforce the changes in Git. This action will potentially recreate resources and should be used with care. See [Replace Resource Instead Of Applying Change](https://argo-cd.readthedocs.io/en/stable/user-guide/sync-options/#replace-resource-instead-of-applying-changes){:target="_blank"}.
+
+**Retry**: When selected, retries a failed sync operation, based on the retry settings configured:
+* Maximum number of sync retries (**Limit**)
+* Duration of each retry attempt in seconds, minutes, or hours (**Duration**)
+* Maximum duration permitted for each retry (**Max Duration**)
+* Factor by which to multiply the Duration in the event of a failed retry (**Factor**). A factor of 2 for example, attempts the second retry in 2 X 2 seconds, where 2 seconds is the Duration.
+
+{::nomarkdown}
+
+{:/}
+
+## Application: Advanced configuration settings
+
+Advanced settings define the tool used to create the application, and related toll-specific settings.
+
+{% include
+ image.html
+ lightbox="true"
+ file="/images/applications/add-app-advanced-settings.png"
+ url="/images/applications/add-app-advanced-settings.png"
+ alt="Advanced configuration settings"
+ caption="Advanced configuration settings"
+ max-width="70%"
+ %}
+
+{::nomarkdown}
+
+{:/}
+
+### ArgoCD Project
+The project group to which the application belongs. A project is useful to enforce restrictions on permitted sources and targets for applications, and roles. If not defined, the application is automatically assigned to the `default` project, which is created automatically by Argo CD and has no restrictions.
+For more information, see Argo CD's documentation on [Projects](https://argo-cd.readthedocs.io/en/stable/user-guide/projects/#projects){:target="\_blank"}.
+
+
+{::nomarkdown}
+
+{:/}
+
+### Propagation policy for application deletion
+Defines how resources are pruned, applying Kubernetes cascading deletion prune policies when you delete the application.
+For more information, see [Argo CD's app deletion](https://argo-cd.readthedocs.io/en/stable/user-guide/app_deletion/){:target="_blank"}..
+* **Foreground**
+ The default prune propagation policy used by Argo CD. With this policy, Kubernetes changes the state of the owner resource to `deletion in progress`, until the controller deletes the dependent resources and finally the owner resource itself.
+* **Background**
+ When selected, Kubernetes deletes the owner resource immediately, and then deletes the dependent resources in the background.
+* **Non-cascading**
+ When selected, Kubernetes deletes only the application and not its resources.
+
+{::nomarkdown}
+
+{:/}
+
+### Type of Application
+The tool used to create the application's manifests. Codefresh supports defining application manifests as a directory, Helm charts, or Kustomize. If you are using other tools to define application manifests, use the Plugin type. For more information, see the Argo CD's documentation on [Tools](https://argo-cd.readthedocs.io/en/stable/user-guide/application_sources/){:target="_blank"}.
+
+
+* **Directory**: A `directory` application, which is the default application type in Argo CD.
+ * **Directory recurse**: Optional. Select to include subdirectories.
+ * **Top-level arguments**: Optional. Select and define parameters.
+ * **External variables**: Optional. Select and define external variables.
+
+* **Helm**: Create the application as a Helm chart.
+ * **Values files**: One or more `values.yaml` files to store the parameters.
+ * **Values**: Optional. When defined, new values not in `values.yaml` files are added, and existing values are overridden.
+
+* **Kustomize**: Create a Kustomize application, with the following settings:
+ * **Version**: The version of Kustomize used to create the application.
+ * **Name Prefix** and **Name Suffix**: Optional. The prefix and suffix to be appended to the resources of the application.
+
+* **Plugin**: Use for any other tool.
+ * **Name**: The name of the Plugin used to create the application.
+ * **External Variables**: The variables to use in the application.
+
+For example applications, go to the [Argo CD example applications repo](https://github.com/argoproj/argocd-example-apps){:target="_blank"}.
+
+
+
+
+## Create an application
+Create a new application from the GitOps Apps dashboard with the Add Application wizard.
+Edit the manifest directly in YAML mode, or define the settings in the Form mode. Toggle between the modes as convenient. You can also edit the YAML manifest directly at all stages, after defining configuration settings, and before the final commit.
+
+**Before you begin**
+
+Review:
+[General configuration](#application-general-configuration-settings)
+[Advanced configuration](#application-advanced-configuration-settings)
+
+
+**How to**
+1. In the Codefresh UI, from Ops in the sidebar, select [GitOps Apps](https://g.codefresh.io/2.0/applications-dashboard/list){:target="\_blank"}.
+1. On the top-right, select **Add Application**.
+1. In the Add Application panel, add definitions for the application:
+ * Application name: Must be unique within the cluster.
+ * Runtime: The runtime to associate with the application.
+ * YAML filename: The name of the application's configuration manifest, assigned on commit to Git. By default, the manifest is assigned the application name. Change the name as required.
+
+ >The application definitions cannot be changed after you continue to the Configuration settings.
+
+{% include
+ image.html
+ lightbox="true"
+ file="/images/applications/add-app-definitions.png"
+ url="/images/applications/add-app-definitions.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. You can edit the YAML manifest.
+1. Define the **General** settings for the application.
+
+{% include
+ image.html
+ lightbox="true"
+ file="/images/applications/add-app-general-settings.png"
+ url="/images/applications/add-app-general-settings.png"
+ alt="Add Application: Advanced settings"
+ caption="Add Application: Advanced settings"
+ max-width="70%"
+ %}
+
+
+{:start="6"}
+1. Define the **Advanced** settings for the application.
+
+{% include
+ image.html
+ lightbox="true"
+ file="/images/applications/add-app-advanced-settings.png"
+ url="/images/applications/add-app-advanced-settings.png"
+ alt="Add Application: Advanced settings"
+ caption="Add Application: Advanced settings"
+ max-width="70%"
+ %}
+
+{:start="7"}
+1. To commit all your changes, select **Commit**.
+ The Commit form is displayed with the application's definition on the left, and the read-only version of the manifest with the configuration settings you defined on the right.
+1. Enter the path to the **Git Source** to which to commit the application configuration manifest.
+
+{% include
+ image.html
+ lightbox="true"
+ file="/images/applications/add-app-final-commit.png"
+ url="/images/applications/add-app-final-commit.png"
+ alt="Add Application: Commit to Git"
+ caption="Add Application: Commit to Git"
+ max-width="70%"
+ %}
+
+{:start="9"}
+1. Add a commit message and then select **Commit** on the bottom-right of the panel.
+
+
+Your application is first committed to Git, and then synced to the cluster which may take a few moments.
+Monitor the application.
+
+{::nomarkdown}
+
+{:/}
+
+
+## Related articles
+[Monitoring GitOps applications]({{site.baseurl}}/docs/deployments/gitops/applications-dashboard)
+[Managing GitOps applications]({{site.baseurl}}/docs/deployments/gitops/manage-application)
+[GitOps Overview dashboard]({{site.baseurl}}/docs/dashboards/home-dashboard)
+[DORA metrics]({{site.baseurl}}/docs/dashboards/dora-metrics/)
\ No newline at end of file
diff --git a/_docs/deployments/gitops/install-argo-rollouts.md b/_docs/deployments/gitops/install-argo-rollouts.md
new file mode 100644
index 000000000..bcb01c8b3
--- /dev/null
+++ b/_docs/deployments/gitops/install-argo-rollouts.md
@@ -0,0 +1,29 @@
+---
+title: "Progressive delivery with GitOps"
+description: ""
+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 [GitOps Apps 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, from the toolbar click the **Settings** icon.
+1. From Runtimes in the sidebar, select [GitOps Runtimes](https://g.codefresh.io/2.0/account-settings/runtimes){:target="\_blank"}.
+1. Select **Topology View**.
+1. Select the target cluster, and then select **+ Install Argo Rollouts**.
+
+{% include
+ image.html
+ lightbox="true"
+ file="/images/runtime/cluster-install-rollout.png"
+ url="/images/runtime/cluster-install-rollout.png"
+ alt="Install Argo Rollouts"
+ caption="Install Argo Rollouts"
+ max-width="40%"
+%}
+
+## Related articles
+[Add external clusters to runtimes]({{site.baseurl}}/docs/installation/managed-cluster/)
\ No newline at end of file
diff --git a/_docs/deployments/gitops/manage-application.md b/_docs/deployments/gitops/manage-application.md
new file mode 100644
index 000000000..2d6535006
--- /dev/null
+++ b/_docs/deployments/gitops/manage-application.md
@@ -0,0 +1,373 @@
+---
+title: "Managing GitOps applications"
+description: ""
+group: deployments
+sub_group: gitops
+toc: true
+---
+
+Application creation and deployment is one part of the continuous deployment/delivery process. An equally important part is optimizing deployed applications when needed.
+
+* [Edit applications](#edit-application-definitions)
+ Optimize deployed applications by changing application definitions when needed.
+
+* [Synchronize applications](#manually-synchronize-an-application)
+ Sync applications on-demand by manually applying sync options or selecting the resources to sync.
+
+* [Delete applications](#delete-an-application)
+ Delete unused or legacy applications to avoid clutter and remove unnecessary resources.
+
+
+* [Manage rollouts for deployments](#manage-rollouts-for-deployments)
+ Control ongoing rollouts by resuming indefinitely paused steps, promoting rollouts, aborting, restarting and retrying rollouts.
+
+
+
+
+
+## Edit application definitions
+Update General or Advanced configuration settings for a deployed application through the Configuration tab. Once the application is deployed to the cluster, the Configuration tab is available on selecting the application in the GitOps Apps dashboard.
+
+> You cannot change application definitions (the application name and the selected runtime), and the Git Source selected for the application.
+
+**How to**
+
+1. In the Codefresh UI, from Ops in the sidebar, select [GitOps Apps](https://g.codefresh.io/2.0/applications-dashboard/list){:target="\_blank"}.
+1. Do one of the following:
+ * Select the application to update, and then from the context menu on the right, select **Edit**.
+
+ * Click the application and then select the **Configuration** tab.
+
+{% include
+ image.html
+ lightbox="true"
+ file="/images/applications/edit-app-configuration-tab.png"
+ url="/images/applications/edit-app-configuration-tab.png"
+ alt="Configuration tab with application settings"
+ caption="Configuration tab with application settings"
+ max-width="70%"
+ %}
+
+{:start="3"}
+1. Update the **General** or **Advanced** configuration settings as needed:
+ [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
+ image.html
+ lightbox="true"
+ file="/images/applications/edit-app-change-setting.png"
+ url="/images/applications/edit-app-change-setting.png"
+ alt="Edit application settings"
+ caption="Edit application settings"
+ max-width="70%"
+ %}
+
+{:start="4"}
+1. Do one of the following:
+ * To _commit all changes_, click **Commit**. This final commit screen is displayed with a diff view of the changes.
+ * To _undo all changes_ and return to the previous settings, click **Discard Changes**. This action removes all the changes you have made so far and returns you to the GitOps Apps dashboard.
+
+ >If you change settings and then restore existing values for the same, Codefresh automatically removes the Commit and Discard Changes buttons as there are no new changes to commit or discard.
+
+ {% include
+ image.html
+ lightbox="true"
+ file="/images/applications/edit-app-diff-view.png"
+ url="/images/applications/edit-app-diff-view.png"
+ alt="Commit changes with diff view"
+ caption="Commit changes with diff view"
+ max-width="70%"
+ %}
+
+{:start="5"}
+1. To confirm all changes, at the bottom-left, click **Commit**.
+ The changes are committed to Git, and in a few moments also synced to the cluster.
+
+{::nomarkdown}
+
+{:/}
+
+## Manually synchronize an application
+Manually synchronize an application to expedite Git-to-cluster sync. The sync options selected for manual sync override the sync options defined for the application.
+The sync options, grouped into Revision and Additional Settings, are identical to the Sync options in the General settings when you created the application.
+
+>You can also synchronize application resources with sync statuses, such as `Service`, `AnalysisTemplate`, and `Rollouts` resources for example, in the Current State tab. The context menu of the resource shows the Sync option.
+
+**Before you begin**
+* Review:
+ [Revision settings for application sync](#revision-settings-for-application-sync)
+ [Additional Options for application sync](#additional-options-for-application-sync)
+ [Synchronize resources](#synchronize-resources-in-the-application)
+
+**How to**
+1. In the Codefresh UI, from Ops in the sidebar, select [GitOps Apps](https://g.codefresh.io/2.0/applications-dashboard/list){:target="\_blank"}.
+1. Sync an application:
+ * Select the application to sync, and do one of the following:
+ * From the context menu on the right, select **Synchronize**.
+ * On the top-right, click **Synchronize**.
+
+ Sync a resource:
+ * Click the application with the resource to sync.
+ * In the **Current State** tab, open the context menu of the resource, and then select **Sync**.
+
+1. Select the **Revision** and **Additional Options** for the manual sync.
+ Review
+1. Click **Next**.
+1. In the Synchronize Resources form, select the scope of the manual sync:
+ * To sync only specific resources, search for the resources by any part of their names, or define a Regex to filter by the required resources.
+ * **All**: Sync all resources regardless of their sync state.
+ * **Out of sync**: Sync _only_ resources that are `Out of sync`.
+
+{::nomarkdown}
+
+{:/}
+
+### Revision settings for application sync
+Revision settings determine the behavior for the branch you select.
+
+**Revision**
+The branch in Git to synchronize with the cluster.
+
+**Prune**
+When selected, removes legacy resources from the cluster that do not exist currently in the Git branch.
+
+**Apply only**
+When selected, syncs only those resources in the application that have been changed and are `OutOfSync`, instead of syncing every resource regardless of their state. This option is useful to reduce load and save time when you have thousands of resources in an application. See [Selective Sync](https://argo-cd.readthedocs.io/en/stable/user-guide/sync-options/#selective-sync){:target="\_blank"}.
+
+**Dry run**
+When selected, allows you to preview the application before changes are made to the cluster.
+
+**Force**
+When selected, orphans the dependents of a deleted resource during the sync operation. This option is useful to prevent
+
+{::nomarkdown}
+
+{:/}
+
+### Additional Options for application sync
+
+#### Sync Options
+
+* **Skip schema validation**
+ When selected, bypasses validating the YAML schema.
+* **Auto-create namespace**
+ When selected, automatically creates the namespace if the specified namespace does not exist in the cluster. If the namespace already exists, this setting is ignored.
+* **Prune last**
+ When selected, removes those resources that do not exist in the currently deployed version during the final wave of the sync operation. See [Prune last](https://argo-cd.readthedocs.io/en/stable/user-guide/sync-options/#prune-last){:target="\_blank"}.
+* **Apply out of sync only**
+ When selected, syncs only those resources in the application that have been changed and are `OutOfSync`, instead of syncing every resource regardless of their state. This option is useful to reduce load and save time when you have thousands of resources in an application. See [Selective Sync](https://argo-cd.readthedocs.io/en/stable/user-guide/sync-options/#selective-sync){:target="\_blank"}.
+* **Respect ignore differences**
+ When selected, Argo CD omits resources defined for the `spec.ignoreDifferences` attribute from the sync. Otherwise, Argo CD implements the desired state ad-hoc during the sync operation. See [Respect ignore difference configs](https://argo-cd.readthedocs.io/en/stable/user-guide/sync-options/#respect-ignore-difference-configs){:target="\_blank"}.
+
+#### Prune propagation policy
+{::nomarkdown}Defines how resources are pruned, applying Kubernetes cascading deletion prune policies.
+Read more at Kubernetes - Cascading deletion.
Foreground: The default prune propagation policy used by Argo CD. With this policy, Kubernetes changes the state of the owner resource to `deletion in progress`, until the controller deletes the dependent resources and finally the owner resource itself.
Background: When selected, Kubernetes deletes the owner resource immediately, and then deletes the dependent resources in the background.
Orphan: When selected, Kubernetes deletes the dependent resources that remain orphaned after the owner resource is deleted.
{:/}
+All Prune propagation policies can be used with:
+
+**Replace**: When selected, Argo CD executes `kubectl replace` or `kubectl create`, instead of the default `kubectl apply` to enforce the changes in Git. This action will potentially recreate resources and should be used with care. See [Replace Resource Instead Of Applying Change](https://argo-cd.readthedocs.io/en/stable/user-guide/sync-options/#replace-resource-instead-of-applying-changes){:target="\_blank"}.
+
+
+**Retry**: When selected, retries a failed sync operation, based on the retry settings configured:
+* Maximum number of sync retries (**Limit**)
+* Duration of each retry attempt in seconds, minutes, or hours (**Duration**)
+* Maximum duration permitted for each retry (**Max Duration**)
+* Factor by which to multiply the Duration in the event of a failed retry (**Factor**). A factor of 2 for example, attempts the second retry in 2 X 2 seconds, where 2 seconds is the Duration.
+
+{::nomarkdown}
+
+{:/}
+
+### Synchronize resources in the application
+Synchronize Resource options allow you to selectively sync application resources. You can bypass sync settings at the application level, and directly select the resources you want to sync, by state or otherwise.
+* All resources regardless of their sync states
+* Only out-of-sync resources
+* Only selected resources
+
+By default, Synchronize Resources displays and selects all resources in the application.
+
+ {% include
+ image.html
+ lightbox="true"
+ file="/images/applications/sync-manual-resources-form.png"
+ url="/images/applications/sync-manual-resources-form.png"
+ alt="Default settings for Synchronize Resources"
+ caption="Default settings for Synchronize Resources"
+ max-width="50%"
+ %}
+
+You can search/filter resources using part of the resource names or regex strings, and then select the resources you want to sync.
+For example, if you made changes to `api` resources or `audit` resources, type `api` or `audit` to locate the resources and then selectively sync those resources.
+
+ {% include
+ image.html
+ lightbox="true"
+ file="/images/applications/sync-manual-resource-search.png"
+ url="/images/applications/sync-manual-resource-search.png"
+ alt="Selective sync in Synchronize Resources"
+ caption="Selective sync in Synchronize Resources"
+ max-width="50%"
+ %}
+
+
+{::nomarkdown}
+
+{:/}
+
+## Delete an application
+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 GitOps Apps 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/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, from Ops in the sidebar, select [GitOps Apps](https://g.codefresh.io/2.0/applications-dashboard/list){:target="\_blank"}.
+1. Select the application to delete.
+1. Click the three dots for additional actions, and select **Delete**.
+
+ {% include
+ image.html
+ lightbox="true"
+ file="/images/applications/app-delete-option.png"
+ url="/images/applications/app-delete-option.png"
+ alt="Delete application"
+ caption="Delete application"
+ max-width="80%"
+ %}
+
+ Pay attention to the _impact of the delete action_ for the selected application that Codefresh displays.
+
+ {% include
+ image.html
+ lightbox="true"
+ file="/images/applications/delete-app-prune-affects.png"
+ url="/images/applications/delete-app-prune-affects.png"
+ alt="Prune setting impact on deleting application"
+ caption="Prune setting impact on deleting application"
+ max-width="70%"
+ %}
+
+{:start="4"}
+1. To confirm, click **Commit & Delete**.
+
+## Manage rollouts for deployments
+Control ongoing rollouts by resuming indefinitely paused steps, promoting rollouts, aborting, restarting and retrying rollouts.
+
+{::nomarkdown}
+
+{:/}
+
+### Pause/resume ongoing rollouts
+Pause and resume ongoing rollouts directly from the Timeline tab in the GitOps Apps dashboard.
+If the rollout is already automatically paused as result of a step definition, this action pauses the rollout even after the pause duration.
+
+
+1. In the Codefresh UI, from Ops in the sidebar, select [GitOps Apps](https://g.codefresh.io/2.0/applications-dashboard/list){:target="\_blank"}.
+1. Select the application and go to the Timelines tab.
+1. In the deployment record for the ongoing rollout, expand **Updated Services**.
+1. Based on the current state of the rollout, click **Pause** or **Resume**, as relevant.
+
+{% include
+ image.html
+ lightbox="true"
+ file="/images/applications/rollout-resume-indefinite-pause.png"
+ url="/images/applications/rollout-resume-indefinite-pause.png"
+ alt="Resume paused rollout"
+ caption="Resume paused rollout"
+ max-width="70%"
+ %}
+
+{::nomarkdown}
+
+{:/}
+
+### Manage an ongoing rollout with the Rollout Player
+Manage an ongoing rollout using the controls in the Rollout Player to skip steps, and promote rollouts.
+
+1. In the Codefresh UI, from Ops in the sidebar, select [GitOps Apps](https://g.codefresh.io/2.0/applications-dashboard/list){:target="\_blank"}.
+1. Select the application and go to the Timelines tab.
+1. In the deployment record for the ongoing rollout, click the name of the rollout.
+1. Select the required option in the Rollout Player.
+
+
+{% include
+image.html
+lightbox="true"
+file="/images/applications/rollout-player.png"
+url="/images/applications/rollout-player.png"
+alt="Rollout Player controls for an ongoing rollout"
+caption="Rollout Player controls for an ongoing rollout"
+max-width="50%"
+%}
+
+
+The table describes the controls in the Rollout Player.
+
+{: .table .table-bordered .table-hover}
+| Rollback player option | Description |
+| -------------- | ------------|
+| **Rollback** | Not available currently. |
+| **Pause** | Pause the rollout. If the rollout is already automatically paused as the result of a step definition, clicking Pause pauses the rollout also after the pause duration. |
+| **Resume** | Resume a rollout that was paused either manually by clicking Pause, or automatically through the step's definition. |
+| **Skip step** | Skip execution of current step. Such steps are marked as Skipped in the rollout visualization. |
+| **Promote full** | Skip all remaining steps, and deploy the current image. |
+
+{::nomarkdown}
+
+{:/}
+
+### Manually rollback completed rollout to previous revision
+
+Manually rollback a completed rollout to a previous revision when and if needed. If after a successful analysis run and rollout, your application is not functioning as it should, you can rollback to a prior revision from the Rollout’s revision history. The revision depth is determined by the `spec.revisionHistoryLimit` parameter in the [Rollout Specification](https://argoproj.github.io/argo-rollouts/features/specification/#rollout-specification){:target="\_blank"}.
+Manual rollback changes the live state of the rollout resource to the state in the previous commit that you select.
+
+1. In the Codefresh UI, from Ops in the sidebar, select [GitOps Apps](https://g.codefresh.io/2.0/applications-dashboard/list){:target="\_blank"}.
+1. Select the application and select the **Timeline** tab.
+1. Click the name of the rollout to rollback.
+1. From the **Choose version to Rollabck** dropdown, select the revision to rollback to.
+1. Review the changes in the revision.
+1. In the Rollout Player, click **Rollback to**.
+
+
+### Manage the `rollout` resource
+
+Control the rollout through the options available for the Rollout resource.
+
+1. In the Codefresh UI, from Ops in the sidebar, select [GitOps Apps](https://g.codefresh.io/2.0/applications-dashboard/list){:target="\_blank"}.
+1. Select the application and go to the Current State tab.
+1. Open the context menu of the `Rollout` resource, and select the relevant option.
+
+{% include
+image.html
+lightbox="true"
+file="/images/applications/rollout-resource-context-menu.png"
+url="/images/applications/rollout-resource-context-menu.png"
+alt="Options for `rollout` resource in the Current State tab"
+caption="Options for `rollout` resource in the Current State tab"
+max-width="50%"
+%}
+
+The table describes the options for the `Rollout` resource.
+
+{: .table .table-bordered .table-hover}
+| Option | Description |
+| -------------- | -------------- |
+|**Abort** | Terminate the current rollout. |
+|**Pause** | Pause the current rollout. |
+|**Promote-full** | Promote the current rollout by skipping all remaining stages in the rollout, and deploy the current image. |
+|**Restart** | Manually restart the pods of the rollout.|
+|**Resume** | Resume a rollout that has been paused. |
+|**Retry** | Retry a rollout that has been aborted. Available only when a rollout has been aborted. |
+|**Skip-current-step** | Skip executing the current step, and continue with the next step. |
+
+
+
+
+## Related articles
+[Creating GitOps applications]({{site.baseurl}}/docs/deployments/gitops/create-application)
+[GitOps Overview dashboard]({{site.baseurl}}/docs/dashboards/home-dashboard)
+[DORA metrics]({{site.baseurl}}/docs/dashboards/dora-metrics)
+
+
+
diff --git a/_docs/deployments/helm.md b/_docs/deployments/helm.md
new file mode 100644
index 000000000..5d3a60186
--- /dev/null
+++ b/_docs/deployments/helm.md
@@ -0,0 +1,19 @@
+---
+title: "Deploy Helm applications"
+description: "Learn how Codefresh supports Helm"
+group: deployments
+toc: true
+---
+
+Codefresh offers several options when it comes to Helm packages and deployments:
+
+* Codefresh offers a [built-in Helm repository]({{site.baseurl}}/docs/deployments/helm/managed-helm-repository/) that you can use in your applications.
+* You can connect your [own external Helm repositories]({{site.baseurl}}/docs/deployments/helm/helm-charts-and-repositories/) and then reference them by name everywhere in your pipelines
+* You can [view the contents]({{site.baseurl}}/docs/deployments/helm/helm-releases-management/) of your Helm repositories and the charts they contain
+* You can easily [store a chart]({{site.baseurl}}/docs/deployments/helm/custom-helm-uploads/) or [deploy it]({{site.baseurl}}/docs/deployments/helm/using-helm-in-codefresh-pipeline/) from a Codefresh pipeline
+* You can create [Helm environments]({{site.baseurl}}/docs/deployments/helm/helm-environment-promotion/) in a dedicated dashboard and promote releases between them.
+
+
+
+
+
diff --git a/_docs/deployments/helm/custom-helm-uploads.md b/_docs/deployments/helm/custom-helm-uploads.md
new file mode 100644
index 000000000..1c596c328
--- /dev/null
+++ b/_docs/deployments/helm/custom-helm-uploads.md
@@ -0,0 +1,126 @@
+---
+title: "Creating and uploading Helm packages"
+description: "Manually create and upload Helm packages"
+group: deployments
+sub_group: helm
+redirect_from:
+ - /docs/new-helm/custom-helm-uploads/
+ - /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 article 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/quick-start/ci-quick-start/deploy-with-helm/) and [Using Helm in 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://helm.sh/docs/helm/helm_package/){:target="_blank"} and [Helm charts overview](https://helm.sh/docs/topics/charts/){: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]({{site.baseurl}}/pipelines/variables/#user-defined-variables)
+
+## 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/)
+[Promoting Helm environments]({{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 000000000..20d25bd0e
--- /dev/null
+++ b/_docs/deployments/helm/helm-charts-and-repositories.md
@@ -0,0 +1,120 @@
+---
+title: "Helm charts and repositories"
+description: "Use external Helm charts and repositories in Codefresh pipelines"
+group: deployments
+sub_group: helm
+redirect_from:
+ - /docs/new-helm/helm-charts-and-repositories/
+ - /docs/new-helm/
+ - /docs/add-helm-repository/
+ - /docs/new-helm/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 Artifacts 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/deployments/helm/quick-helm-integration.png"
+url="/images/deployments/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 you have set up Helm integrations in Codefresh, you can import single or multiple Helm repository contexts into your pipelines.
+Select the **Import from shared configuration** option in the "Environment Variables" section, and then select the Helm repository or Helm repositories to import into the pipeline.
+The repository settings are imported as environment variables into the pipeline, to use as needed.
+
+1. From the Pipelines page, select the pipeline into which to import the Helm repository contexts.
+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 **Import from/Add shared configuration**, and select the name of the repository.
+1. To import more Helm registry contexts, repeat step 3.
+ The settings for the Helm registry contexts are injected as environment variables into the pipeline.
+
+{% include image.html
+lightbox="true"
+file="/images/deployments/helm/connect-helm-repo.png"
+url="/images/deployments/helm/connect-helm-repo.png"
+alt="Connecting a Helm repository in the pipeline"
+caption="Connecting a Helm repository in the pipeline"
+max-width="70%"
+%}
+
+{:start="5"}
+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/deployments/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/configuration/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 that you have a Kubernetes integration with the cluster and namespace, as described [here]({{site.baseurl}}/docs//integrations/kubernetes/#connect-a-kubernetes-cluster)
+
+**How to**
+1. In the Codefresh UI, from Artifacts 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)
+[Promoting Hlem environments]({{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 000000000..0ae1bd979
--- /dev/null
+++ b/_docs/deployments/helm/helm-environment-promotion.md
@@ -0,0 +1,292 @@
+---
+
+title: "Promoting Helm Environments"
+description: "Manage your Helm Environments with the Codefresh UI"
+group: deployments
+sub_group: helm
+redirect_from:
+ - /docs/new-helm/helm-environment-promotion/
+toc: true
+---
+Apart from the [Helm Releases]({{site.baseurl}}/docs/deployments/helm/helm-releases-management) dashbaord that shows 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/deployments/helm/promotion/board.png"
+url="/images/deployments/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/deployments/helm/promotion/helm-environments.png"
+url="/images/deployments/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 DevOps Insights in the sidebar, select [**Helm Boards**](https://g.codefresh.io/helm/helm-kanban/){:target="\_blank"}.
+
+{% include
+image.html
+lightbox="true"
+file="/images/deployments/helm/promotion/board-selection.png"
+url="/images/deployments/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/deployments/helm/promotion/edit-helm-environment.png"
+url="/images/deployments/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/deployments/helm/promotion/expand.png"
+url="/images/deployments/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/deployments/helm/promotion/shift-right.png"
+url="/images/deployments/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/deployments/helm/promotion/promote-settings.png"
+url="/images/deployments/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/deployments/helm/promotion/value-options.png"
+url="/images/deployments/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/#environment-variables-for-custom-helm-commands):
+
+* `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` - 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/pipelines/configuration/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/account-user-management/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/deployments/helm/promotion/board-management.png"
+url="/images/deployments/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/deployments/helm/promotion/filter.png"
+url="/images/deployments/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/)
+[Helm charts and repositories]({{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/deployments/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 000000000..62faa5443
--- /dev/null
+++ b/_docs/deployments/helm/helm-releases-management.md
@@ -0,0 +1,264 @@
+---
+title: "Managing Helm releases"
+description: "Manage Helm deployments from the Codefresh UI"
+group: deployments
+sub_group: helm
+redirect_from:
+ - /docs/new-helm/helm-releases-management/
+ - /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/deployments/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/#connect-a-kubernetes-cluster) to Codefresh.
+
+1. In the Codefresh UI, from DevOps Insights in the sidebar, select [**Helm Releases**](https://g.codefresh.io/helm/releases/releasesNew/){:target="\_blank"}.
+
+{% include
+image.html
+lightbox="true"
+file="/images/deployments/helm/helm-release-dashboard.png"
+url="/images/deployments/helm/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/deployments/helm/services.png"
+url="/images/deployments/helm/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/deployments/helm/history.png"
+url="/images/deployments/helm/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/deployments/helm/diff.png"
+url="/images/deployments/helm/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/deployments/helm/manifests.png"
+url="/images/deployments/helm/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/deployments/helm/helm-commit-message.png"
+url="/images/deployments/helm/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-a-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 [Helm pipeline 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/deployments/helm/rollback.png"
+url="/images/deployments/helm/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-default-helm-actions-for-releases), 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.
+
+Select the row with the desired chart, and:
+* Issue a [Helm test](https://helm.sh/docs/topics/chart_tests/){:target="\_blank"} by clicking on the 'Run Test' button.
+* Delete a release by clicking on the 'Delete' button.
+ For deletion options, see the [Helm delete documentation](https://helm.sh/docs/helm/helm_uninstall/){:target="\_blank"}. For example, *purge* removes the revision from the release history.
+
+## Helm deployment badge
+
+Similar to a [build badge]({{site.baseurl}}/docs/pipelines/configuration/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/deployments/helm/helm-badge.png"
+url="/images/deployments/helm/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/account-user-management/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/deployments/helm/override-helm-actions.png"
+url="/images/deployments/helm/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/pipelines/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/)
+[Using a managed Helm repository]({{site.baseurl}}/docs/deployments/helm/managed-helm-repository/)
+[Promoting Helm Environments]({{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 000000000..f8f133c41
--- /dev/null
+++ b/_docs/deployments/helm/managed-helm-repository.md
@@ -0,0 +1,140 @@
+---
+title: "Using a managed Helm repository"
+description: "Use the Codefresh integrated Helm repository"
+group: deployments
+sub_group: helm
+redirect_from:
+ - /docs/new-helm/managed-helm-repository/
+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/deployments/helm/managed-helm-repo.png"
+url="/images/deployments/helm/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 the Codefresh UI:
+* From your avatar dropdown, select [**User Settings**](https://g.codefresh.io/user/settings){:target="\_blank"}. See [Codefresh API integration]({{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 000000000..ff62aa191
--- /dev/null
+++ b/_docs/deployments/helm/using-helm-in-codefresh-pipeline.md
@@ -0,0 +1,376 @@
+---
+title: "Using Helm in a Codefresh pipeline"
+description: "Deploy and push Helm charts with Codefresh"
+group: deployments
+sub_group: helm
+redirect_from:
+ - /docs/new-helm/using-helm-in-codefresh-pipeline/
+ - /docs/deployments/helm/create-helm-artifacts-using-codefresh-pipeline/
+ - /docs/install-helm-chart-using-codefresh-pipeline/
+ - /docs/new-helm/helm2-support/
+ - /docs/new-helm/integration-tests-with-helm/
+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/quick-start/ci-quick-start/deploy-with-helm/) . 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/){:target="\_blank"}
+1. Create a Helm package for your application from the chart
+1. [Add a Kubernetes cluster]({{site.baseurl}}/docs/integrations/kubernetes/#connect-a-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/configuration/shared-configuration/) into your pipeline variables
+1. Use the Helm step in your [Pipeline definitions YAML]({{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]({{site.baseurl}}/docs/integrations/kubernetes/#connect-a-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 (Settings >Pipeline Integrations > Kubernetes).
+
+{% include image.html
+lightbox="true"
+file="/images/deployments/helm/k8s-name.png"
+url="/images/deployments/helm/k8s-name.png"
+alt="Name of Kubernetes cluster"
+caption="Name of Kubernetes cluster"
+max-width="70%"
+%}
+
+{:start="3"}
+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/helm-charts-and-repositories/)
+OR
+* Obtain your [managed Helm repository URL]({{site.baseurl}}/docs/deployments/helm/managed-helm-repository/#get-the-chart-repository-url)
+
+
+### Step 4: (Optional) Import Helm configuration(s) into your pipeline definition
+
+Once you have Helm repositories connected to Codefresh, you can import one or more of them into the pipeline. This step is needed in pipelines that actually upload/fetch Helm charts from/to Helm repositories. If you have a pipeline that directly installs a Helm chart from the Git filesystem, there is no need to import a Helm configuration.
+
+1. Click the **Variables** tab on the right sidebar, and then click the **Settings** (gear) icon.
+1. Click **Import from shared configuration**, and select the Helm context or contexts to import into the pipeline:
+ * To import a single context, select the context. The `CF_HELM_DEFAULT` is the Helm repo provided by Codefresh. See also [shared configuration]({{site.baseurl}}/docs/configure-ci-cd-pipeline/shared-configuration/).
+ * To import multiple contexts, select each context to import.
+
+ {% include image.html
+lightbox="true"
+file="/images/deployments/helm/import-helm-configuration.png"
+url="/images/deployments/helm/import-helm-configuration.png"
+alt="Importing Helm repositories into the pipeline"
+caption="Importing Helm repositories into the pipeline"
+max-width="50%"
+%}
+
+> You can also click on *Add shared configuration* directly from the three dots menu for the same functionality.
+
+This concludes the Helm setup for Codefresh. Now you can use the Helm freestyle step in the pipeline `codefresh.yml` file.
+
+
+### 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 in [user-defined variables]({{site.baseurl}}/docs/pipelines/variables/#user-defined-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, which can be one of the following:
+
+1. `install`: Installs the Helm chart into a Kubernetes cluster. This is the default mode if one is not explicitly set.
+2. `push`: Packages the Helm chart and pushes it to the repository.
+3. `auth`: Sets up authentication, and adds one or more Helm repos. 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.
+
+
+**Multiple Helm contexts for pipeline**
+
+If you have imported multiple Helm contexts into the same pipeline:
+* For the `install` and `push` actions, you need to define the primary Helm context to use through the `primary_helm_context` argument.
+* For the `auth` action, to use the repos from the Helm contexts imported into the pipeline, add `use_repos_for_auth_action: 'true'`. Otherwise, imported contexts, if any, are ignored for the `auth` action.
+
+For a description of these and other arguments, see [Helm step configuration fields](#helm-step-configuration-fields).
+
+
+#### 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 [Argument 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-into-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/){:target="\_blank"}.
+
+## Helm step configuration fields
+
+{: .table .table-bordered .table-hover}
+|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_subdir |optional | The subfolder where the chart is located in the JFrog Artifactory Helm repository.|
+|chart_version|optional|Override or set the chart version.|
+|cmd_ps|optional|Command Postscript - this will be 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.|
+|credentials_in_arguments | optional | The username and password credentials to add to the Helm command as arguments. If not added to the Helm command, the credentials are passed in the URL `http(s)://username:password@url`. Should be enabled for JFrog Artifactory Helm repositories.|
+|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_repository_context | optional |The name of the Helm repository integration configured in Codefresh.|
+|helm_version|optional|version of [cfstep-helm image](https://hub.docker.com/r/codefresh/cfstep-helm/tags).|
+|kube_context|required for install|Kubernetes context to use. The name of the cluster as [configured in Codefresh]({{site.baseurl}}/docs/integrations/kubernetes/#connect-a-kubernetes-cluster).|
+|namespace|optional|Target Kubernetes namespace to deploy to.|
+|primary_helm_context |optional |Required for `install` and `push` actions when the pipeline has multiple Helm contexts. The Helm context to use for the Helm command. When omitted, the repo most recently added to the pipeline is used.|
+|release_name|used for `install`|The Helm release name. If the release exists, it is upgraded.|
+|repos|optional|array of custom repositories.|
+|set_file | optional | Set values from the respective files specified by the command line in `key=value` format. To specify multiple key-value pairs, separate them with commas. |
+|skip_cf_stable_helm_repo | optional | Don't add stable repository.|
+|tiller_namespace|optional|Kubernetes namespace where Tiller is installed .|
+|timeout | optional | The maximum time, in seconds, to wait for Kubernetes commands to complete.|
+|use_debian_image | optional | Use Debian-based `cfstep-helm` image.|
+|use_repos_for_auth_action |optional | Required for the `auth` action to use repos from attached contexts. When required, set value to `true`.|
+wait |optional | When specified, waits until all pods are in state `ready` to mark the release as successful. Otherwise, release is marked as successful when the minimum number of pods are `ready` and the Services have IP addresses. |
+
+
+
+## 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/deployments/helm/full-helm-pipeline.png"
+url="/images/deployments/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/helm-charts-and-repositories/)
+[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.md b/_docs/deployments/kubernetes.md
new file mode 100644
index 000000000..370d0f7f8
--- /dev/null
+++ b/_docs/deployments/kubernetes.md
@@ -0,0 +1,34 @@
+---
+title: "How to deploy to Kubernetes"
+description: "Learn the different Kubernetes deployment options"
+group: deployments
+toc: true
+redirect_from:
+ - /docs/deployments/kubernetes/deployment-options-to-kubernetes/
+---
+
+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 deployment quick start]({{site.baseurl}}/docs/quick-start/ci-quick-start/deploy-to-kubernetes/).
+1. Through a dedicated [deploy step]({{site.baseurl}}/docs/pipelines/steps/deploy/) in a pipeline.
+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 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 deployment to Kubernetes quick start]({{site.baseurl}}/docs/quick-start/ci-quick-start/deploy-with-helm/).
+
+## Prerequisites for all options
+
+* A K8s cluster in Codefresh (see [Connecting a Kubernetes cluster]({{site.baseurl}}/docs/integrations/kubernetes/#connect-a-kubernetes-cluster) )
+* Familiarity with the [Codefresh YAML for pipeline definitions]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/), basic [pipeline steps]({{site.baseurl}}/docs/pipelines/steps/), and how to describe them
+* [Docker registry integration]({{site.baseurl}}/docs/integrations/docker-registries/) in Codefresh
+
+
+## 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/automated-deployment.md b/_docs/deployments/kubernetes/automated-deployment.md
new file mode 100644
index 000000000..7307d4119
--- /dev/null
+++ b/_docs/deployments/kubernetes/automated-deployment.md
@@ -0,0 +1,99 @@
+---
+title: "Automated deployments"
+description: "Deploy to Kubernetes with a pipeline"
+group: deployments
+sub_group: kubernetes
+redirect_from:
+ - /docs/deploy-to-kubernetes/environment-dashboard/
+ - /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
+---
+
+First you need a Docker image to deploy to the cluster.
+If you don't have one already you can use a Codefresh pipeline to build one.
+
+## Build and push your image
+Here is a basic Codefresh pipeline scenario to build and push your image to the 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.
+
+
+## Add a Deployment step
+So now you have deployed your image manually, which is great.
+But, how can you trigger the deployment within your pipeline? For that you will need to add a step of type `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 the image to a Docker registry, and deploys the image 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/custom-kubectl-commands.md b/_docs/deployments/kubernetes/custom-kubectl-commands.md
new file mode 100644
index 000000000..620506055
--- /dev/null
+++ b/_docs/deployments/kubernetes/custom-kubectl-commands.md
@@ -0,0 +1,186 @@
+---
+title: "Custom kubectl commands"
+description: "Use kubectl in your Codefresh pipelines"
+group: deployments
+sub_group: kubernetes
+redirect_from:
+ - /docs/deploy-to-kubernetes/custom-kubectl-commands/
+toc: true
+---
+
+As described in [Deployment options for Kubernetes]({{site.baseurl}}/docs/deployments/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/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/deployments/kubernetes/kube-context.png"
+url="/images/deployments/kubernetes/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/deployments/kubernetes/parallel-kubectl.png"
+url="/images/deployments/kubernetes/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 Kubernetes clusters]({{site.baseurl}}/docs/deployments/kubernetes/manage-kubernetes/)
+[Accessing a Docker registry from cluster]({{site.baseurl}}/docs/ci-cd-guides/access-docker-registry-from-kubernetes/)
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/_docs/deployments/kubernetes/environment-dashboard.md b/_docs/deployments/kubernetes/environment-dashboard.md
new file mode 100644
index 000000000..173e15313
--- /dev/null
+++ b/_docs/deployments/kubernetes/environment-dashboard.md
@@ -0,0 +1,124 @@
+---
+title: "Environment dashboard"
+description: "Viewing your deployment environments"
+group: deployments
+sub_group: kubernetes
+redirect_from:
+ - /docs/deploy-to-kubernetes/environment-dashboard/
+toc: true
+---
+
+The [Kubernetes Services dashboard]({{site.baseurl}}/docs/deployments/kubernetes/manage-kubernetes/) is a good way to see what your clusters are doing but it is mostly focused on low level constructs such as pods and docker images. The [Helm environment dashboard]({{site.baseurl}}/docs/deployments/helm/helm-environment-promotion/) on the other hand offers an application level view of your cluster, but it only applies to Helm deployments.
+
+To bridge this gap, Codefresh also offers a Environment Dashboard for both Kubernetes and Helm releases that allows you to see cluster status in addition to what the pipelines are doing.
+
+{% include
+image.html
+lightbox="true"
+file="/images/pipeline/codefresh-yaml/environments/environments.png"
+url="/images/pipeline/codefresh-yaml/environments/environments.png"
+alt="Codefresh Environment Dashboard"
+caption="Codefresh Environment Dashboard"
+max-width="70%"
+%}
+
+The environment dashboard is configurable and each environment can represent a plain Kubernetes deployment or a Helm release.
+
+## Access the Environment dashboard
+* In the Codefresh UI, from Ops in the sidebar, [**Environments**](https://g.codefresh.io/environments){:target="\_blank"}.
+
+
+## How environments work
+
+The purpose of an environment is to give you an overview of both the cluster status as well as the builds that affect it. The environment acts as a link between the status of builds and the status of the cluster.
+
+
+{% include
+image.html
+lightbox="true"
+file="/images/deployments/kubernetes/dashboard/environment-info.png"
+url="/images/deployments/kubernetes/dashboard/environment-info.png"
+alt="Components of an environment"
+caption="Components of an environment"
+max-width="100%"
+%}
+
+A Codefresh environment is based on two components:
+* A cluster namespace that holds a deployment/service (or a Helm release in the case of Helm)
+* An association between builds and this cluster
+
+When you visit the environment screen you can see consolidated information on what your environment is doing. Codefresh will pull live data from the cluster to populate the status bar of each environment entry and will automatically show the status of the last 3 builds that affected this environment.
+
+The overall status of the environment (shown as a green or red label at the top of the environment card) is the exit result of the last build that affected that environment.
+
+The URL shown at the environment is just a shortcut link that allows you to quickly visit the user application exposed by the environment (if this is applicable). It is not used by Codefresh for anything else (i.e. Codefresh does *not* check it to actually decide if an environment is healthy).
+
+
+## Creating an environment
+
+You can create an environment in two ways:
+
+* Describe the environment details in the any pipeline that affects it using the [special env syntax]({{site.baseurl}}/docs/pipelines/deployment-environments/). The first time the pipeline runs, the environment GUI entry will be created automatically in the dashboard.
+* Create the environment details yourself straight from the Codefresh UI
+
+To create an environment while in the dashboard screen, click the *New environment* button on the top right corner and fill in the required details:
+
+{% include
+image.html
+lightbox="true"
+file="/images/deployments/kubernetes/dashboard/create-environment.png"
+url="/images/deployments/kubernetes/dashboard/create-environment.png"
+alt="Creating an environment from the GUI"
+caption="Creating an environment from the GUI"
+max-width="50%"
+%}
+
+When you create an environment for your application, you can define the following:
+* Helm boards: Namespace, Cluster, and Release. Namespace is useful when you have more than one Helm release per namespace, or you have the same Helm release in more than one namespace.
+* Kubernetes boards: Release, Cluster, and Namespace.
+
+Once you create the environment, Codefresh will pull automatically the status of pods/deployments/services from the cluster and show it at the environment status bar. To link specific pipelines to that environment follow the [env syntax guide]({{site.baseurl}}/docs/pipelines/deployment-environments/).
+
+You can also combine the two ways by first creating an environment in the GUI and then associating it with a pipeline. But notice that in that case the environment details you selected in the GUI must **EXACTLY** match those defined in the pipeline (so that the pipeline can detect which environment entry it should update).
+
+## Understanding cluster issues
+
+There is no restriction to the number of pipelines linked to an environment (and the number of environments affected by a single pipeline). In fact the true power of the environment dashboard becomes evident when you link multiple pipelines to a single environment.
+
+One of the most common deployment issues are errors in configuration. Instead of just linking pipelines that deploy applications, you should instead link *all* types of pipelines that affect a cluster. These pipelines can contains
+
+* application deployments
+* cluster component changes
+* configuration changes (e.g. configmaps or secrets)
+* database changesets
+
+This means that the environment entry will have a history of *all* changes that happened on the cluster and not just application deployments. Ideally no manual change should happen to the cluster outside of a pipeline.
+
+{% include
+image.html
+lightbox="true"
+file="/images/deployments/kubernetes/dashboard/error-detection.png"
+url="/images/deployments/kubernetes/dashboard/error-detection.png"
+alt="Looking at the history of an environment"
+caption="Looking at the history of an environment"
+max-width="100%"
+%}
+
+Here we have a classic deployment issue where an application is deployed on the cluster and fails, even thought the exact same application tag was previously successful.
+
+Because that team that created this dashboard also linked the pipeline that does configuration changes to the cluster, it is clear that there was a configmap change between the two application deployments. Even though the configuration change itself was successful, the application deployment failed the second time because of it.
+
+With the environment dashboard it is very easy to understand that the configuration change was responsible for breaking the next deployment. An operator can now look at the configuration change and talk with a developer that knows what the application needs and why it failed.
+
+Therefore make sure to link all pipelines that affect a cluster in the environment dashboard and not just application deployments.
+
+
+
+
+## Related articles
+[Update environment status from builds]({{site.baseurl}}/docs/pipelines/deployment-environments/)
+[Connect a Kubernetes cluster]({{site.baseurl}}/docs/integrations/kubernetes/#connect-a-kubernetes-cluster)
+[Managing Kubernetes clusters]({{site.baseurl}}/docs/deployments/kubernetes/manage-kubernetes/)
+[Promoting Helm environments]({{site.baseurl}}/docs/deployments/helm/helm-environment-promotion/)
+
+
diff --git a/_docs/deployments/kubernetes/manage-kubernetes.md b/_docs/deployments/kubernetes/manage-kubernetes.md
new file mode 100644
index 000000000..7f8aeafeb
--- /dev/null
+++ b/_docs/deployments/kubernetes/manage-kubernetes.md
@@ -0,0 +1,170 @@
+---
+title: "Managing Kubernetes clusters"
+description: "Use the graphical Kubernetes dashboard in Codefresh"
+group: deployments
+sub_group: kubernetes
+redirect_from:
+ - /docs/deploy-to-kubernetes/manage-kubernetes/
+ - /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/integrations/kubernetes/kubernetes-dashboard.png"
+url="/images/integrations/kubernetes/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/deployments/kubernetes/grid-view.png"
+url="/images/deployments/kubernetes/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:
+* 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.
+
+Read more [Deployment options for Kubernetes]({{site.baseurl}}/docs/deployments/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/quick-start/ci-quick-start/deploy-to-kubernetes/)
+
+
+
diff --git a/_docs/deployments/kubernetes/manual-deployment.md b/_docs/deployments/kubernetes/manual-deployment.md
new file mode 100644
index 000000000..279ccc4f0
--- /dev/null
+++ b/_docs/deployments/kubernetes/manual-deployment.md
@@ -0,0 +1,67 @@
+---
+title: "Manual deployments"
+description: "Deploy to Kubernetes with the Codefresh GUI"
+group: deployments
+sub_group: kubernetes
+toc: true
+---
+
+First you need a Docker image to deploy to the cluster.
+If you don't have one already you can use a Codefresh pipeline to build one.
+
+## Build and push your image
+
+Here is a basic Codefresh pipeline scenario to build and push your image to the 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 %}
+
+Run the pipeline and the container image will be pushed to Dockerhub.
+
+## Describe your deployment
+
+The following instructions describe how to create a new service in your Kubernetes cluster in order to deploy to it.
+
+
+ 1. In the Codefresh UI, from Ops in the sidebar, select [**Kubernetes Services**](https://g.codefresh.io/kubernetes/services/){:target="\_blank"}.
+ 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/deployments/kubernetes/describe-k8s-deployment.png"
+url="/images/deployments/kubernetes/describe-k8s-deployment.png"
+alt="Describe Kubernetes deployment"
+caption="Describe Kubernetes deployment"
+max-width="60%"
+%}
+
+## 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/docker-registries/cfcr-deprecation.md b/_docs/docker-registries/cfcr-deprecation.md
deleted file mode 100644
index 360c4a8f4..000000000
--- a/_docs/docker-registries/cfcr-deprecation.md
+++ /dev/null
@@ -1,501 +0,0 @@
----
-title: "Deprecation of the Codefresh Container Registry"
-description: "Migrating images and pipelines to an external registry"
-group: docker-registries
-toc: true
----
-
-
-| Important Date | Codefresh Container Registry status |
-| -------------- | ---------------------------- |
-| 1st April 2020 | New build step and image API are available. |
-| Now until July 1st 2020 | Fully functional (push/pull allowed) |
-| July 1st 2020 | No pushes allowed. Registry becomes read-only|
-| 15th July 2020 | Codefresh Container Registry is removed from service |
-
-
-
-The Codefresh Container registry which is the built-in Docker registry that comes out of the box with all Codefresh accounts is being deprecated. The registry will become read-only on **July 1st 2020** and will be removed completely on **July 15th 2020**.
-
-## Terminology for this document
-
-{: .table .table-bordered .table-hover}
-
-| Term | Description |
-| -------------- | ---------------------------- |
-| Codefresh Container registry | The built-in registry available to all accounts. This registry is decommissioned. |
-| Caching registry | Registry used for [caching]({{site.baseurl}}/docs/configure-ci-cd-pipeline/pipeline-caching/#docker-registry-caching). Currently served by the Codefresh registry|
-| Default Registry | Registry where pipelines auto-push their docker images |
-| External Registry | Any other external registry which is linked to Codefresh such as ACR, GCR, ECR etc. |
-| Image dashboard | The [Image registry viewer]({{site.baseurl}}/docs/docker-registries/codefresh-registry/#viewing-your-docker-images). Currently shows images from Codefresh registry only|
-| Pipeline Build step | The [build step]({{site.baseurl}}/docs/codefresh-yaml/steps/build/) that currently auto-pushes to the Codefresh Container registry |
-| SAAS installation | The cloud version of Codefresh where everything is managed by Codefresh personnel |
-| Hybrid installation | Codefresh installation where customers [use the Codefresh runner]({{site.baseurl}}/docs/enterprise/behind-the-firewall/) |
-| On-prem installation | Installation of Codefresh that is running fully on customer premises without any cloud interaction.
-
-
-## Who is affected from the removal of the Codefresh Container registry
-
-* If you running the on-prem version of Codefresh, there is no requirement to take immediate action. Your Codefresh account manager will let you know how you will upgrade to the next version.
-* If you running the hybrid version of Codefresh, you are affected and need to select an external registry to use in your account.
-* If you are using the SAAS version of Codefresh, you are affected and need to select an external registry to use in your account.
-
-In most cases migration is trivial, unless you are using solely the Codefresh Container registry for your artifact storage.
-
-## Adopting an external Docker registry
-
-The migration effort depends on the usage of the Codefresh Container registry in your organization.
-
-1. Customers who use exclusively an external registry and do not depend on the Codefresh Container registry will have to take no action.
-1. Customers who use both the Codefresh Container registry as well as an external one will need to move all their critical workloads and pipelines to the external one
-1. Customers who use the Codefresh Container registry for all their needs will need to evaluate and select and external Docker registry and connect it to Codefresh.
-
-The first prerequisite is therefore to [select an external Registry]({{site.baseurl}}/docs/docker-registries/external-docker-registries/). You can use any popular cloud registry such as:
-
- * [Docker Hub]({{site.baseurl}}/docs/docker-registries/external-docker-registries/docker-hub/)
- * [Azure Container Registry]({{site.baseurl}}/docs/docker-registries/external-docker-registries/azure-docker-registry/)
- * [Google Container Registry]({{site.baseurl}}/docs/docker-registries/external-docker-registries/google-container-registry/)
- * [Amazon EC2 Container Registry]({{site.baseurl}}/docs/docker-registries/external-docker-registries/amazon-ec2-container-registry/)
- * [Bintray.io/Artifactory]({{site.baseurl}}/docs/docker-registries/external-docker-registries/bintray-io/)
- * [Quay.io]({{site.baseurl}}/docs/docker-registries/external-docker-registries/quay-io/)
-
-It is also possible to connect any other cloud or hosted registry that follows the V2 Docker registry protocol.
-
-Some examples of self-hosted registries are:
-
-* The [official registry](https://github.com/docker/distribution) by Docker
-* [Nexus](https://www.sonatype.com/nexus-repository-sonatype) by Sonatype
-* [Harbor](https://goharbor.io/) by VMware
-* [Portus](http://port.us.org/) by Suse
-* [Container Registry](https://www.alibabacloud.com/product/container-registry) by Alibaba
-* [Openshift registry](https://www.openshift.com/) by Redhat
-* [Kraken](https://github.com/uber/kraken) by Uber
-* [Proget](https://inedo.com/proget) by Inedo
-
-
-## Migration schedule
-
-
-Summary of actions by customers
-
-{: .table .table-bordered .table-hover}
-
-| Migration Phase | Action |
-| -------------- | ---------------------------- |
-| Now | Investigate external Registry options. Replace Codefresh Container registry with an External Docker registry in all pipelines |
-| From April 1st to July 1st | Choose default registry for auto-push and validate that all pipelines do NOT use the Codefresh Container registry. Setup meeting with CSM as needed|
-| July 1st | No push allowed. Validate that no cluster, workflow or pipeline is still using the Codefresh Container registry. Confirm migration completion with Codefresh |
-
-
-
-
-## Phase A Migration actions until 1st April 2020
-
-At this phase, customers that depend on the Codefresh Container registry should look at their pipelines and deployments and understand where the Codefresh Container registry is used.
-
-
-### Locating images from the Codefresh Container registry in clusters
-
-The most critical action point is to locate docker images that reside in the Codefresh Container registry and are actually deployed in production clusters.
-
-Here is an example of a Kubernetes deployment manifest.
-
-`example-deployment.yaml`
-{% highlight yaml %}
-{% raw %}
-apiVersion: extensions/v1beta1
-kind: Deployment
-metadata:
- name: vote
-spec:
- replicas: 1
- template:
- metadata:
- labels:
- app: vote
- spec:
- containers:
- - image: r.cfcr.io/dockersamples/examplevotingapp:production
- name: vote
-{% endraw %}
-{% endhighlight %}
-
-The deployment refers to an image to the Codefresh Container registry identified by the `r.cfcr.io` prefix. For Helm deployments, images may also be referenced in the Helm values file.
-
-`values.yaml`
-{% highlight yaml %}
-{% raw %}
-replicaCount: 1
-image:
- pullPolicy: IfNotPresent
- repository: r.cfcr.io/kostis-codefresh/helm-sample-app-go
-service:
- name: my-example-helm-app
- type: LoadBalancer
- externalPort: 80
- internalPort: 8080
- {% endraw %}
-{% endhighlight %}
-
-In all these cases, deployment manifests should be changed to mention Docker images that are found in the external Docker registry.
-You can also use the [dedicated script](https://github.com/codefresh-io/cfcrmigration) for the same purpose.
-
-### Locating images from the Codefresh Container registry in pipelines
-
-It is also possible that images from the Codefresh Container Registry are used as [freestyle steps]({{site.baseurl}}/docs/codefresh-yaml/steps/freestyle/) directly in pipelines.
-
-Here is an example:
-
- `codefresh.yml`
-{% highlight yaml %}
-{% raw %}
-version: '1.0'
-stages:
- - prepare
- - test
-steps:
- main_clone:
- title: Cloning main repository...
- stage: prepare
- type: git-clone
- repo: 'codefresh-contrib/react-sample-app'
- revision: master
- git: github
- my_unit_tests:
- title: Unit test
- stage: test
- image: r.cfcr.io/kostis-codefresh/my-node-dev-image:9.0
- commands:
- - yarn install
- - yarn test
-{% endraw %}
-{% endhighlight %}
-
-The second step in this pipeline is using an image from the registry as mentioned by `r.cfcr.io/kostis-codefresh/my-node-dev-image`. Image references like this will need to be changed to mention an external registry.
-
-Explicit [push steps]({{site.baseurl}}/docs/codefresh-yaml/steps/push/) must also change to refer to an external registry:
-
- `codefresh.yml`
-{% highlight yaml %}
-{% raw %}
-version: '1.0'
-stages:
-- checkout
-- build
-- push
-steps:
- main_clone:
- title: Cloning main repository...
- type: git-clone
- stage: checkout
- repo: 'codefreshdemo/cf-example-build-and-push'
- revision: 'master'
- git: github
- build_my_app:
- title: Building Node.Js Docker Image
- type: build
- stage: build
- image_name: my-node-js-app
- working_directory: '.'
- tag: 'master'
- dockerfile: Dockerfile
- push_to_my_registry:
- stage: 'push'
- type: push
- title: Pushing to internal registry
- candidate: ${{build_my_app}}
- tag: 'v1.0.0'
- registry: cfcr
-{% endraw %}
-{% endhighlight %}
-
-In this pipeline the last step is pushing a docker image to the internal Codefresh. You will need to change the `registry` property to the name of an external registry.
-
->Note the name `cfcr` shown above is just a convention. You can find the actual name given to the Codefresh Container Registry in the [Registry settings screen](https://g.codefresh.io/account-admin/account-conf/integration/registry). From the same screen you can also see the name of your external registry
-
-You can also use the [dedicated script](https://github.com/codefresh-io/cfcrmigration) for the same purpose.
-
-### Promoting images from the Codefresh Container registry to an external ones.
-
-Another migration step for this phase is to move all existing images from the Codefresh Container registry to the external one. You can use the [Image dashboard](https://g.codefresh.io/images/) to locate and analyze your existing Docker images. You can then migrate Docker images in 3 ways
-
-1. If you know the pipeline that created this image, you can simply rerun the pipeline with a new push step
-1. You can promote the image directly from the Codefresh Container Registry to your external one
-1. You can perform mass migration with a migration script
-
-The first case is linked with the push steps mentioned in the previous section.
-
-If your existing pipeline pushes to cfcr:
-
-{% highlight yaml %}
-{% raw %}
- push_to_my_registry:
- stage: 'push'
- type: push
- title: Pushing to internal registry
- candidate: ${{build_my_app}}
- tag: 'v1.0.0'
- registry: cfcr
-{% endraw %}
-{% endhighlight %}
-
-then you can simply change the `registry` property to your external registry and re-run the pipeline.
-
-{% highlight yaml %}
-{% raw %}
- push_to_my_registry:
- stage: 'push'
- type: push
- title: Pushing to external registry
- candidate: ${{build_my_app}}
- tag: 'v1.0.0'
- registry: my-external-registry
-{% endraw %}
-{% endhighlight %}
-
-Note that `my-external-registry` is just the unique name assigned to your registry from the [Registry settings screen](https://g.codefresh.io/account-admin/account-conf/integration/registry).
-
-You can also promote images from the [manually from the UI]({{site.baseurl}}/docs/docker-registries/codefresh-registry/#promoting-docker-images) or with a [pipeline]({{site.baseurl}}/docs/docker-registries/working-with-docker-registries/#promoting-docker-images).
-
-If you wish to perform migration of Docker images in a batch manner, you can also use the [migration script offered by Codefresh](https://github.com/codefresh-io/cfcr-migration).
-
-We also offer an automated way to locate all pipelines that still use the Codefresh registry. See our [tool for locating all pipelines](https://github.com/codefresh-io/cfcrmigration)
- that are affected by the Codefresh registry removal.
-
-
-
-
-### Summary of actions and results of migration phase A
-
-Here is a summary of customer actions at the end of 1st April 2020
-
-* You need to evaluate external Docker registry services and connect at least one in your Codefresh account
-* Change Kubernetes deployments and Helm releases to pull images from the external Registry instead of the Codefresh one
-* Do not use Codefresh images in any pipeline (especially freestyle steps). Use images from the external registry only
-* Change all pipeline push steps to use specifically the external Docker registry
-* Promote essential images from the Codefresh Container registry to the external Docker registry
-* No pipeline should push to the Codefresh Container registry.
-* Use the [dedicated script](https://github.com/codefresh-io/cfcrmigration) to detect all pipelines affected by the Codefresh registry
-
-
-## Phase B Migration actions until 1st July 2020
-
-At that start of Phase B (1st April 2020) Codefresh will offer the following new features:
-
-1. The ability to define a default registry for the build step to push to (currently the build step is always pushing to the Codefresh Container Registry)
-1. The ability to define an explicit registry in the [build step]({{site.baseurl}}/docs/codefresh-yaml/steps/build/) (overriding the default)
-1. The ability to disable the automatic push of the build step completely (currently a build will always push to the internal Codefresh Container registry)
-1. The ability to define multiple tags to be created in the build step.
-1. The ability to define an explicit registry for [caching]({{site.baseurl}}/docs/configure-ci-cd-pipeline/pipeline-caching/)
-1. A new image dashboard that will show docker images from all connected registries (and not just the Codefresh Container registry)
-
-You can find all these settings in the [Migration dashboard](https://g.codefresh.io/account-admin/account-conf/cfcr-deprecation). You need to be a Codefresh administrator to access the dashboard.
-
-{%
- include image.html
- lightbox="true"
- file="/images/artifacts/cfcr/build-enhancements.png"
- url="/images/artifacts/cfcr/build-enhancements.png"
- alt="New Image and Build enhancements"
- caption="New Image and Build enhancements"
- max-width="50%"
-%}
-
-From the dashboard you can change all settings (and even revert them back) and see if your pipelines are ready. You can also "simulate" the removal of the Codefresh registry (or set it read-only) in advance, and see how you will be affected when the actual removal happens.
-
-Specifically for the new Build Step, you can also enable it on a specific pipeline with the `build_version` property (see the next section for examples).
-
-### Using a default registry for pipelines
-
-With the migration settings in place, you need to inspect your pipelines and make sure you:
-
-1. Set as default registry in your Codefresh account the external one
-1. If you have more than one external registries, override the default one in any build steps that you want to use another registry other than the default (if this scenario is useful to you)
-1. Disable auto-push on pipelines that don't need it if they also have a push step or you only wish to use the image in the pipeline itself and don't need anywhere else.
-
-For the second point here is the syntax for the new build step:
-
-
-{% highlight yaml %}
-{% raw %}
- build_step:
- type: build
- stage: build
- tag: ${{CF_BRANCH_TAG_NORMALIZED}}
- image_name: my-docker-image
- registry: my-external-registry
-{% endraw %}
-{% endhighlight %}
-
-For the third point, here is the syntax for disabling auto-push
-
-{% highlight yaml %}
-{% raw %}
- build_step:
- type: build
- stage: build
- tag: ${{CF_BRANCH_TAG_NORMALIZED}}
- image_name: my-docker-image
- disable_push: true
-{% endraw %}
-{% endhighlight %}
-
-This way you get maximum flexibility on what build and push steps are doing in your pipelines.
-
-We are also adding the ability to create multiple tags in the build step. Therefore if until now you used the [push step]({{site.baseurl}}/docs/codefresh-yaml/steps/push/) for this purpose, you can simplify your pipelines even further by using only the enhanced build step.
-
-{% highlight yaml %}
-{% raw %}
- build_step:
- type: build
- stage: build
- image_name: my-docker-image
- tags:
- - latest
- - ${{CF_BRANCH_TAG_NORMALIZED}}
- - v1.1
-{% endraw %}
-{% endhighlight %}
-
-This way you get maximum flexibility on what build and push steps are doing in your pipelines.
-
->It is important to notice that if you haven't set a default registry on your Codefresh account, or define a specific registry in the build step itself, the pipeline doesn't know where to push the created docker image.
-
-### Using the new build step on a specific pipeline
-
-Instead of enabling globally the new build step on your account, you can also enable it on a specific pipeline (and keep all other pipelines with the previous behavior) by using the `build_version` property in the root of the pipeline:
-
-{% highlight yaml %}
-{% raw %}
-version: '1.0'
-build_version: 'v2'
-steps:
- main_clone:
- title: Cloning main repository...
- type: git-clone
- repo: 'codefreshdemo/cf-example-build-and-push'
- revision: 'master'
- git: github
- build_my_app:
- title: Building Node.Js Docker Image
- type: build
- image_name: my-node-js-app
- working_directory: '.'
- tag: 'master'
- dockerfile: Dockerfile
- registry: 'gcr'
-
-{% endraw %}
-{% endhighlight %}
-
-
-This pipeline is able to use the new `registry` property because we declare at the root of the pipeline that the enhanced version of the build step will be used.
-
-### Marking a registry as a caching registry
-
-Make sure that one of your external registries (if you have more than one) is marked as a [caching registry]({{site.baseurl}}/docs/docker-registries/external-docker-registries/#the-caching-registry).
-
-
-### Using the new Docker image dashboard/API
-
-The Codefresh CLI as well as the Codefresh UI will now show images for all external registries. This means that all Docker images in pipelines and/or scripts will need to have an explicit prefix in order for Codefresh to understand which external registry they belong to (if you have more than one).
-
-If you don't have a prefix, Codefresh will assume that this image refers to Dockerhub.
-
-You will need to
-
-* Check all custom scripts you have that use Codefresh CLI and make sure that images mentioned refer to your external registry
-* Check any API integrations you have created with the Codefresh Image API and make sure that images mentioned refer to your external registry
-
-
-### Summary of actions and results of migration phase B
-
-Here is a summary of customer actions at the end of 1st July 2020
-
-* Setup a default registry in your Codefresh account for the registry that is used in push steps as well as caching
-* Decide if you want your build steps to push automatically to the default registry or not
-* Make sure that all your APIs calls or Codefresh CLI invocations mention images with an explicit Docker registry prefix
-* Use the [dedicated script](https://github.com/codefresh-io/cfcrmigration) to detect all pipelines affected by the Codefresh registry
-
-
-## Phase C Migration actions until 15th July 2020
-
-At this phase, the Codefresh Container registry will become readonly. Pipelines will be able to pull from it, but all pushes are disallowed.
-
-If you have performed all the migration steps explained in the previous phases, nothing will break. However if you still have push steps that refer to the Codefresh Container registry or have not selected yet a default registry, your pipelines will now *fail*.
-
-This is also the last opportunity for migrating images from the Codefresh Container Registry to the external one.
-
-### Summary of actions and results of migration phase C
-
-Here is a summary of customer actions at the end of 15th July 2020
-
-* Monitor your pipelines and make sure that they push to the external registry only
-* Double-check your clusters and make sure that they pull from an external registry
-* Check that caching works in your pipelines as well as Hybrid environments by making sure that the external Docker registry has enough capacity.
-
-## Complete removal of the Codefresh Container registry on 15th July 2020
-
-The Codefresh Container registry will be removed from service on 15th July 2020
-
-* Pipelines that still pull from it will stop working
-* Kubernetes clusters that will pull from it will have failed deployments
-
-## Motivation behind the Registry removal
-
-Codefresh was one of the [first solutions to include a built-in Registry](https://codefresh.io/docker-registry/free-private-docker-registry/). When this started it was a unique and important feature. But over time, it’s value has diminished as Docker registries have become common.
-
-The Codefresh registry was always offered to all customers free of charge and without any (hard) storage limits. Behind the scenes, the Codefresh registry is based on Google storage (similar to GCR) but with some extra Codefresh modifications. For all intents and purposes the Codefresh registry was fully controlled by us in all aspects (domain prefix, authorization and authentication).
-
-Four years ago, having a built-in private registry was a huge competitive advantage, that helped us make users familiar with Docker images.
-
-Nowadays however, Docker (i.e. containers) are an established technology and many vendors offer [external Docker registries]({{site.baseurl}}/docs/docker-registries/external-docker-registries/) that work perfectly fine with Codefresh pipelines. It therefore makes sense for us to focus on implementing brand new CI/CD features as we look into the future of the Kubernetes/Helm ecosystem.
-
-## Customer usage of the Codefresh Registry
-
-One of the factors in our decision for deprecation was customer usage of the registry. We saw that most of our customers are already using an external Docker registry in addition to the private one.
-
-We support natively [promoting Docker images]({{site.baseurl}}/docs/docker-registries/working-with-docker-registries/#promoting-docker-images) from the private Registry to an external one. This means that most of our customers will migrate their images to an external registry with minimum impact.
-
-We are also contacting customers who exclusively use the Codefresh registry for all their deployments to offer them special assistance regarding the migration.
-
-## Keeping the unique features of Codefresh regarding registries
-
-The Codefresh container registry also had some extra features unique to Codefresh such as a [smart Docker image cache]({{site.baseurl}}/docs/configure-ci-cd-pipeline/pipeline-caching/#docker-registry-caching).
-
-We know that these features are important to several customers and we wish to keep them. SAAS customers can choose which registry will be used for caching and it can be any external registry (the same one that is used for image pushing or another one). Customers with hybrid runtimes will still get caching from any external registry they connect, which in many cases will actually yield a performance improvement as well as improved security.
-
-This way customers will still be able to enjoy fast builds and dynamic pipeline steps by using their own registry. Development for this new functionality is already underway.
-
-## New features planned for Docker Registries
-
-With the removal of the Codefresh registry we are also re-evaluating some long standing features and enhancements that we always wanted to add to the Codefresh registry and are now more useful in regards to the deprecation announcement.
-
-First of all, we intend to make the registry view a universal dashboard that will be used for all external docker registries. Previously this dashboard only showed images in the Codefresh registry.
-
-This means that customers who used both the Codefresh and an external registry had to visit two distinct places to see their images. One of the main goals of Codefresh however is the full visibility of all phases of the software life cycle within a single application and having two different places to look at Docker images goes against this goal.
-
-In addition, we will offer more flexibility to customers regarding the auto-push of docker images to any external registry, as well as which external registry is considered the “default” for auto-pushes. Previously all these options were hardcoded and customers had zero flexibility on how to use the Codefresh registry.
-
-In summary, even though we are deprecating the Codefresh registry, we are committed to making Codefresh the best solution for working with external Docker registries.
-
-## Migration of images from the Codefresh container registry to the external one
-
-Among other things, we will offer an automated way to migrate Docker images from the Codefresh registry to an external one. This way if a customer has Docker images which for some reason cannot be recreated by an existing pipeline (and therefore pushed to an external registry), they will all be migrated to an external Docker registry.
-
-We will also offer dedicated support and special assistance to customers who need help with the migration period or otherwise face significant impact from the deprecation of the private Registry
-
-## Contact information
-
-Please do not hesitate to contact us with questions or concerns. We are here to help. Feel free to contact our special deprecation team at cfcr-removal@codefresh.io or your designated Codefresh account manager for more information.
-
-## What to read next
-
-* [Working with Docker registries]({{site.baseurl}}/docs/docker-registries/working-with-docker-registries/)
-* [External Docker Registries]({{site.baseurl}}/docs/docker-registries/external-docker-registries/)
-* [Accessing a Docker registry from your Kubernetes cluster]({{site.baseurl}}/docs/deploy-to-kubernetes/access-docker-registry-from-kubernetes/)
-
-
-
-
-
diff --git a/_docs/example-catalog/cd-examples.md b/_docs/example-catalog/cd-examples.md
new file mode 100644
index 000000000..082bc536b
--- /dev/null
+++ b/_docs/example-catalog/cd-examples.md
@@ -0,0 +1,42 @@
+---
+title: "CD example catalog"
+description: "A collection of CD examples for Codefresh pipelines"
+group: example-catalog
+toc: true
+---
+
+Continuous Delivery/Deployment ideally includes already
+Continuous Integration and builds upon it.
+
+
+### Preview environment examples
+
+Codefresh can automatically launch environments (powered by Docker swarm) to [preview a Pull Request or feature]({{site.baseurl}}/docs/quick-start/ci-quick-start/on-demand-environments/). The definition of the environment can come from an [existing composition]({{site.baseurl}}/docs/testing/create-composition/), a docker-compose file or an inline YAML. Preview environments can be launched manually or [automatically from pipelines]({{site.baseurl}}/docs/pipelines/steps/launch-composition/).
+
+- [NGINX Basic Auth]({{site.baseurl}}/docs/example-catalog/cd-examples/secure-a-docker-container-using-http-basic-auth/)
+- [Spring Boot + Kafka + Zookeeper]({{site.baseurl}}/docs/example-catalog/cd-examples/spring-boot-kafka-zookeeper/)
+- [Web terminal]({{site.baseurl}}/docs/example-catalog/cd-examples/web-terminal/)
+
+### Deployment examples
+
+Codefresh can deploy to any platform such as VMs, FTP/SSH/S3 sites, app servers, but of course it has great support for [Kubernetes clusters]({{site.baseurl}}/docs/deployments/kubernetes/) and [Helm releases]({{site.baseurl}}/docs/deployments/helm/helm-releases-management/):
+
+- [Deploy to a VM with packer]({{site.baseurl}}/docs/example-catalog/cd-examples/packer-gcloud/)
+- [Deploy to a VM with FTP]({{site.baseurl}}/docs/example-catalog/cd-examples/transferring-php-ftp)
+- [Deploy to Tomcat using SCP]({{site.baseurl}}/docs/example-catalog/cd-examples/deploy-to-tomcat-via-scp)
+- [Use kubectl as part of freestyle step]({{site.baseurl}}/docs/example-catalog/cd-examples/use-kubectl-as-part-of-freestyle-step)
+- [Deploy with Kustomize]({{site.baseurl}}/docs/example-catalog/cd-examples/deploy-with-kustomize)
+- [Deploy with Helm]({{site.baseurl}}/docs/example-catalog/cd-examples/helm)
+- [Deploy with Terraform]({{site.baseurl}}/docs/example-catalog/cd-examples/terraform)
+- [Deploy with Pulumi]({{site.baseurl}}/docs/example-catalog/cd-examples/pulumi)
+- [Deploy to Nomad]({{site.baseurl}}/docs/example-catalog/cd-examples/nomad)
+- [Deploy to Heroku]({{site.baseurl}}/docs/example-catalog/cd-examples/deploy-to-heroku/)
+- [Deploy to Docker swarm]({{site.baseurl}}/docs/example-catalog/cd-examples/docker-swarm/)
+- [Deploy to Elastic Beanstalk]({{site.baseurl}}/docs/example-catalog/cd-examples/elastic-beanstalk/)
+- [Deploy to Amazon ECS/Fargate]({{site.baseurl}}/docs/example-catalog/cd-examples/amazon-ecs/)
+
+
+### Secrets examples
+
+Codefresh can automatically export secret key-value pairs using the Vault plugin from the [Step Marketplace](https://codefresh.io/steps/step/vault){:target="\_blank"}.
+- [GitOps with Bitnami sealed secrets]({{site.baseurl}}/docs/example-catalog/cd-examples/gitops-secrets)
\ No newline at end of file
diff --git a/_docs/yaml-examples/examples/amazon-ecs.md b/_docs/example-catalog/cd-examples/amazon-ecs.md
similarity index 75%
rename from _docs/yaml-examples/examples/amazon-ecs.md
rename to _docs/example-catalog/cd-examples/amazon-ecs.md
index b4bdc8bd4..de930d0bd 100644
--- a/_docs/yaml-examples/examples/amazon-ecs.md
+++ b/_docs/example-catalog/cd-examples/amazon-ecs.md
@@ -1,9 +1,10 @@
---
title: "Amazon ECS/Fargate"
-description: "How to use Codefresh to deploy Docker containers to ECS/Fargate"
-group: yaml-examples
-sub_group: examples
+description: "Use Codefresh to deploy Docker containers to ECS/Fargate"
+group: example-catalog
+sub_group: cd-examples
redirect_from:
+ - /docs/yaml-examples/examples/amazon-ecs/
- /docs/amazon-ecs/
- /docs/deploy-your-containers/
- /docs/deploy-your-containers/amazon-ecs/
@@ -24,8 +25,8 @@ max-width="100%"
1. Configure an ECS (or Fargate) Cluster with at least one running instance.
-1. Configure an ECS Service and Task Definition with a reference to **the image that you are going to build and push.** See [the official amazon docs](http://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html) for more details.
-1. Connect your [ECR to Codefresh]({{site.baseurl}}/docs/docker-registries/external-docker-registries/amazon-ec2-container-registry/) so that it can be used by name in Codefresh pipelines.
+1. Configure an ECS Service and Task Definition with a reference to **the image that you are going to build and push.** See [the official amazon docs](http://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html){:target="\_blank"} for more details.
+1. Connect your [ECR to Codefresh]({{site.baseurl}}/docs/integrations/docker-registries/amazon-ec2-container-registry/) so that it can be used by name in Codefresh pipelines.
1. Verify you have AWS Credentials (`AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`), with the following privileges:
`JSON`
@@ -60,7 +61,7 @@ max-width="100%"
## Create a CI/CD pipeline for ECS/Fargate
-Here is the whole pipeline:
+Here is the complete pipeline:
`codefresh.yml`
{% highlight yaml %}
@@ -106,13 +107,13 @@ steps:
This pipeline does the following:
-1. Clones the source code with a [Git clone step]({{site.baseurl}}/docs/codefresh-yaml/steps/git-clone/)
-1. Uses a [build step]({{site.baseurl}}/docs/codefresh-yaml/steps/build/) to create a Docker image
-1. Uses a [push step]({{site.baseurl}}/docs/codefresh-yaml/steps/push/) to push the docker image to ECR. The registry was previously [connected in Codefresh]({{site.baseurl}}/docs/docker-registries/external-docker-registries/) with the `ecr` identifier.
+1. Clones the source code with a [Git clone step]({{site.baseurl}}/docs/pipelines/steps/git-clone/)
+1. Uses a [build step]({{site.baseurl}}/docs/pipelines/steps/build/) to create a Docker image
+1. Uses a [push step]({{site.baseurl}}/docs/pipelines/steps/push/) to push the docker image to ECR. The registry was previously [connected to Codefresh]({{site.baseurl}}/docs/integrations/docker-registries/amazon-ec2-container-registry/) with the `ecr` identifier.
1. Runs `codefreshplugins/cf-deploy-ecs` to perform the actual deployment
-The pipeline needs [environment variables]({{site.baseurl}}/docs/configure-ci-cd-pipeline/pipelines/#pipeline-settings) that hold all the required parameters
+The pipeline needs [environment variables]({{site.baseurl}}/docs/pipelines/pipelines/#pipeline-settings) that hold all the required parameters.
{% include image.html
lightbox="true"
@@ -143,13 +144,13 @@ The `codefreshplugins/cf-deploy-ecs` step performs the following:
* The `cfecs-update` command exits with a timeout error if after --timeout (default = 900s) `runningCount` does not equal `desiredCount`
* The `cfecs-update` exits with an error if --max-failed (default = 2) or more ECS tasks were stopped with error for the task definition that you are deploying. ECS continuously retries failed tasks.
-You can also find the same step in the form of a [Codefresh plugin](https://codefresh.io/steps/step/ecs-deploy).
+You can also find the same step in the form of a [Codefresh plugin](https://codefresh.io/steps/step/ecs-deploy){:target="\_blank"}.
-## What to read next
-
-* [Codefresh YAML]({{site.baseurl}}/docs/codefresh-yaml/what-is-the-codefresh-yaml/)
-* [Pipeline steps]({{site.baseurl}}/docs/codefresh-yaml/steps/)
-* [Creating pipelines]({{site.baseurl}}/docs/configure-ci-cd-pipeline/pipelines/)
-* [External Registries]({{site.baseurl}}/docs/docker-registries/external-docker-registries/)
+## Related articles
+[CD pipeline examples]({{site.baseurl}}/docs/example-catalog/examples/#cd-examples)
+[Codefresh YAML for pipeline definitions]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/)
+[Steps in pipelines]({{site.baseurl}}/docs/pipelines/steps/)
+[Creating pipelines]({{site.baseurl}}/docs/pipelines/pipelines/)
+[External registries]({{site.baseurl}}/docs/integrations/docker-registries/)
diff --git a/_docs/example-catalog/cd-examples/deploy-to-heroku.md b/_docs/example-catalog/cd-examples/deploy-to-heroku.md
new file mode 100644
index 000000000..42a07ca0c
--- /dev/null
+++ b/_docs/example-catalog/cd-examples/deploy-to-heroku.md
@@ -0,0 +1,214 @@
+---
+title: "Deploy to Heroku"
+description: "Deploy your application or image to Heroku"
+group: example-catalog
+sub_group: cd-examples
+redirect_from:
+ - /docs/yaml-examples/examples/deploy-to-heroku/
+toc: true
+---
+
+Heroku is a container-based cloud PaaS (Platform as a Service) software that allows you to deploy, run, and manage your applications. Built on top of AWS, it supports Ruby, Node.js, Java, Python, Clojure, Scala, Go and PHP.
+
+This tutorial will cover two examples, depending on your use case. If you are not using containers, your use case is covered using the Codefresh heroku-deployer plugin ([Example #1](#pipeline-example-1-deploying-source-code-to-heroku-using-the-codefresh-heroku-plugin)). If you are using containers, you can achieve deployment by using a combination of build, push, and freestyle steps ([Example #2](#pipeline-example-2-deploy-a-docker-image-to-heroku)).
+
+## Example Django Application
+
+You can find the example project on [GitHub](https://github.com/codefresh-contrib/heroku-python-django-sample-app){:target="\_blank"}.
+
+The repository contains a Django starter project with the following commands:
+
+- `pip install -r requirements.txt` to install dependencies.
+- `python -m unittest composeexample.utils` runs unit tests.
+- `python manage.py runserver 0.0.0.0:8000` to start the application locally.
+
+Once launched the application presents the Django starter page at localhost:8000.
+
+## Pipeline Example #1: Deploying Source Code to Heroku Using the Codefresh Heroku Plugin
+
+### Prerequisites
+
+- A [Codefresh account]({{site.baseurl}}/docs/administration/account-user-management/create-codefresh-account/)
+- A [free Heroku account](https://signup.heroku.com){:target="\_blank"}
+- A Heroku API token (you can find this under **Account Settings** and then scrolling down, you will find the API Key)
+
+### Create the pipeline
+
+This pipeline has three stages: clone, test, and deploy.
+
+{% include image.html
+lightbox="true"
+file="/images/examples/deployments/heroku-deployer-pipeline.png"
+url="/images/examples/deployments/heroku-deployer-pipeline.png"
+alt="Codefresh UI Pipeline View"
+caption="Codefresh UI Pipeline View"
+max-width="100%"
+%}
+
+You should be able to copy and paste this YAML in the in-line editor of the Codefresh UI. It will automatically clone the project for you.
+
+Note that you need to change the environment variables in the deploy stage to your respective values. You can do this through the Codefresh UI. Navigate to the in-line editor, and to the right you will find a tab labeled **Variables**.
+
+{% include image.html
+lightbox="true"
+file="/images/examples/deployments/heroku-deployer-variables2.png"
+url="/images/examples/deployments/heroku-deployer-variables2.png"
+alt="Codefresh UI Pipeline Variables View"
+caption="Codefresh UI Pipeline Variables View"
+max-width="100%"
+%}
+
+`codefresh.yml`
+{% highlight yaml %}
+{% raw %}
+version: '1.0'
+stages:
+ - clone
+ - test
+ - deploy
+steps:
+ clone:
+ title: "Cloning main repository..."
+ stage: "clone"
+ type: "git-clone"
+ arguments:
+ repo: "codefresh-contrib/heroku-python-django-sample-app"
+ revision: "master"
+ git: "github"
+ run_unit_tests:
+ title: "Running unit tests..."
+ stage: "test"
+ type: "freestyle"
+ working_directory: "${{clone}}"
+ arguments:
+ image: "python:3.6-slim"
+ commands:
+ - "pip install -r requirements.txt --cache-dir=/codefresh/volume/pip-cache"
+ - "python -m unittest composeexample.utils"
+ deploy_to_heroku:
+ title: "Deploying to Heroku..."
+ stage: "deploy"
+ type: "heroku-deployer"
+ arguments:
+ APP_NAME: $APP_NAME
+ EMAIL: $EMAIL
+ API_TOKEN: $API_TOKEN
+{% endraw %}
+{% endhighlight %}
+
+The above pipeline has the following steps:
+
+1. A [git-clone]({{site.baseurl}}/docs/pipelines/steps/git-clone/) step that clones the main repository
+2. A [freestyle step]({{site.baseurl}}/docs/pipelines/steps/freestyle/) that installs dependencies and runs the unit tests
+3. A freestyle step that deploys the application to Heroku using the heroku-deployer plugin from the [Step Marketplace](https://codefresh.io/steps/step/heroku-deployer){:target="\_blank"}.
+
+## Pipeline Example #2: Deploy a Docker Image to Heroku
+
+This example differs from the plugin usage, as it deploys a built Docker image to Heroku.
+
+Note that you need to change the environment variables to your respective values. You can do this through the Codefresh UI. Navigate to the in-line editor, and to the right you will find a tab labeled **Variables**.
+
+{% include image.html
+lightbox="true"
+file="/images/examples/deployments/heroku-deployer-variables.png"
+url="/images/examples/deployments/heroku-deployer-variables.png"
+alt="Codefresh UI Pipeline Variables View"
+caption="Codefresh UI Pipeline Variables View"
+max-width="100%"
+%}
+
+## Prerequisites
+
+- A [Codefresh account]({{site.baseurl}}/docs/administration/account-user-management/create-codefresh-account/)
+- A [free Heroku account](https://signup.heroku.com){:target="\_blank"}
+- An empty repository already created in Heroku using the `heroku create ` command
+- A Heroku registry [connected to Codefresh]({{site.baseurl}}/docs/integrations/docker-registries/other-registries/#heroku-registries)
+- A Heroku API token (you can find this under **Account Settings** and then scrolling down, you will find the API Key)
+
+### Create the pipeline
+
+This pipeline has five stages: clone, build, test, push, and release.
+
+{% include image.html
+lightbox="true"
+file="/images/examples/deployments/heroku-vanilla-push-pipeline.png"
+url="/images/examples/deployments/heroku-vanilla-push-pipeline.png"
+alt="Codefresh UI Pipeline View"
+caption="Codefresh UI Pipeline View"
+max-width="100%"
+%}
+
+You should be able to copy and paste this YAML in the in-line editor of the Codefresh UI. It will automatically clone the project for you.
+
+`codefresh-heroku-push-image.yml`
+{% highlight yaml %}
+{% raw %}
+version: '1.0'
+version: '1.0'
+stages:
+ - clone
+ - build
+ - test
+ - push
+ - release
+steps:
+ clone:
+ title: "Cloning main repository..."
+ stage: "clone"
+ type: "git-clone"
+ arguments:
+ repo: "codefresh-contrib/heroku-python-django-sample-app"
+ revision: "master"
+ git: "github"
+ build:
+ title: "Building Docker Image..."
+ stage: "build"
+ type: "build"
+ working_directory: "./heroku-python-django-sample-app"
+ arguments:
+ image_name: "${{IMAGE_NAME}}"
+ tag: "master"
+ dockerfile: "Dockerfile"
+ run_unit_tests:
+ title: "Running unit tests..."
+ stage: "test"
+ type: "freestyle"
+ working_directory: "./heroku-python-django-sample-app"
+ arguments:
+ image: '${{build}}'
+ commands:
+ - "python -m unittest composeexample.utils"
+ push_image:
+ title: "Pushing image to Heroku..."
+ stage: "push"
+ type: "push"
+ arguments:
+ candidate: '${{build}}'
+ image_name: "${{IMAGE_NAME}}/web"
+ registry: "heroku"
+ release_image:
+ title: "Releasing image..."
+ stage: "release"
+ type: "freestyle"
+ arguments:
+ image: "nazarcodefresh/heroku-cli:alpine"
+ commands:
+ - >-
+ printf "machine api.heroku.com\n login $EMAIL\n password
+ $API_TOKEN\nmachine git.heroku.com\n login $EMAIL\n password
+ $API_TOKEN\n" > ~/.netrc
+ - "heroku container:release --app $IMAGE_NAME web"
+{% endraw %}
+{% endhighlight %}
+
+The pipeline does the following:
+1. Clones the main repository through the [git-clone step]({{site.baseurl}}/docs/pipelines/steps/git-clone/).
+1. Builds our Docker image through a [freestyle step]({{site.baseurl}}/docs/pipelines/steps/freestyle/).
+1. Runs unit tests on our Docker image through another freestyle step.
+1. Pushes to the Heroku registry through a [push step]({{site.baseurl}}/docs/pipelines/steps/push/).
+1. Releases the Docker image through another freestyle step.
+
+
+
+## Related articles
+[CD pipeline examples]({{site.baseurl}}/docs/example-catalog/examples/#cd-examples)
diff --git a/_docs/example-catalog/cd-examples/deploy-to-tomcat-via-scp.md b/_docs/example-catalog/cd-examples/deploy-to-tomcat-via-scp.md
new file mode 100644
index 000000000..f054a9755
--- /dev/null
+++ b/_docs/example-catalog/cd-examples/deploy-to-tomcat-via-scp.md
@@ -0,0 +1,124 @@
+---
+title: "Deploy to a VM via SCP"
+description: "Deploy your application to Tomcat using SCP"
+group: example-catalog
+sub_group: cd-examples
+redirect_from:
+ - /docs/yaml-examples/examples/deploy-to-tomcat-via-scp/
+toc: true
+---
+
+## Prerequisites
+
+- A [Codefresh account]({{site.baseurl}}/docs/administration/account-user-management/create-codefresh-account)
+- A distribution of [Tomcat](https://tomcat.apache.org/download-90.cgi){:target="\_blank"} setup on a remote server (running with port 8080 exposed)
+
+## The example Java Application
+
+You can find the example project on [GitHub](https://github.com/codefresh-contrib/scp-war-app){:target="\_blank"}.
+
+The example application is a simple Hello World Java application using the [Spark Java framework](http://sparkjava.com/){:target="\_blank"}:
+
+{% include image.html
+lightbox="true"
+file="/images/examples/deployments/scp-hello-world.png"
+url="/images/examples/deployments/scp-hello-world.png"
+alt="Hello World!"
+caption="Hello World!"
+max-width="100%"
+%}
+
+
+```java
+ @Override
+ public void init() {
+ get("/hello", (req, res) -> "Hello World");
+ }
+```
+
+## Create the pipeline
+
+Our pipeline has three stages: clone, package, and transfer.
+
+{% include image.html
+lightbox="true"
+file="/images/examples/deployments/scp-pipeline.png"
+url="/images/examples/deployments/scp-pipeline.png"
+alt="SCP pipeline"
+caption="Codefresh UI Pipeline View"
+max-width="100%"
+%}
+
+You should be able to copy and paste this YAML in the in-line editor of the Codefresh UI. It will automatically clone the project for you.
+
+Note that you need to change the environment variables under the `transfer` step to your respective values.
+
+`codefresh.yml`
+{% highlight yaml %}
+{% raw %}
+# More examples of Codefresh YAML can be found at
+# https://codefresh.io/docs/docs/example-catalog/example
+
+version: "1.0"
+# Stages can help you organize your steps in stages
+stages:
+ - "clone"
+ - "package"
+ - "transfer"
+
+steps:
+ clone:
+ title: "Cloning repository..."
+ type: "git-clone"
+ stage: "clone"
+ arguments:
+ repo: "codefresh-contrib/scp-war-app"
+
+ package:
+ title: "Packaging war..."
+ type: "freestyle"
+ stage: "package"
+ arguments:
+ image: "maven:3.5.2-jdk-8-alpine"
+ working_directory: "${{clone}}"
+ commands:
+ - "mvn -Dmaven.repo.local=/codefresh/volume/m2_repository clean package"
+
+ transfer:
+ title: "Transferring war to Tomcat..."
+ type: "freestyle"
+ stage: "transfer"
+ arguments:
+ image: "ictu/sshpass:latest"
+ working_directory: "${{package}}/target"
+ environment:
+ - USER=
+ - HOST=
+ - PASSWORD=
+ - TOMCAT_DIR=
+ commands:
+ - "echo | ssh-keygen -P '' -t rsa"
+ - "sshpass -p $PASSWORD ssh-copy-id -i /root/.ssh/id_rsa.pub -o StrictHostKeyChecking=no $USER@$HOST"
+ - "scp sparkjava-hello-world-1.0.war $USER@$HOST:$TOMCAT_DIR"
+{% endraw %}
+{% endhighlight %}
+
+The above pipeline does the following:
+
+1. Clones the main repository through the [git-clone step]({{site.baseurl}}/docs/pipelines/steps/git-clone/).
+2. Installs the dependencies via Maven and packages our `war` file through a [freestyle step]({{site.baseurl}}/docs/pipelines/steps/freestyle/).
+3. Transfers our application via scp to a Tomcat server through another freestyle step.
+
+Note that you will need to change the listed environment variables accordingly, either through the YAML itself, or through your pipeline settings:
+
+{% include image.html
+lightbox="true"
+file="/images/examples/deployments/scp-variables.png"
+url="/images/examples/deployments/scp-variables.png"
+alt="Pipeline variables"
+caption="Pipeline variables"
+max-width="100%"
+%}
+
+## Related articles
+[CD pipeline examples]({{site.baseurl}}/docs/example-catalog/examples/#cd-examples)
diff --git a/_docs/example-catalog/cd-examples/deploy-with-kustomize.md b/_docs/example-catalog/cd-examples/deploy-with-kustomize.md
new file mode 100644
index 000000000..ef5422532
--- /dev/null
+++ b/_docs/example-catalog/cd-examples/deploy-with-kustomize.md
@@ -0,0 +1,245 @@
+---
+title: "Deploy with Kustomize"
+description: "Deploy your services to Kubernetes using Kustomize"
+group: example-catalog
+sub_group: cd-examples
+redirect_from:
+ - /docs/yaml-examples/examples/deploy-with-kustomize/
+toc: true
+---
+
+[Kustomize](https://kustomize.io){:target="\_blank"} is a tool included with kubectl 1.14 that "lets you customize raw, template-free YAML files for multiple purposes, leaving the original YAML untouched and usable as is."
+
+Kustomize is more of an overlay engine, as opposed to a templating engine. You create a base configuration and overlays. Your overlays contain a *kustomization.yaml* file, and any variants/changes are applied over top of the base configuration. Kustomize does not use templates at all.
+
+While it is good for simple scenarios, we suggest that you use Helm for managing your Kubernetes applications. Helm is a full package manager for Kubernetes manifests that also provides templating capabilities. See [this example]({{site.baseurl}}/docs/example-catalog/cd-examples/helm/){:target="\_blank"} for more information.
+
+## The example application
+
+You can find the example project on [GitHub](https://github.com/codefresh-contrib/kustomize-sample-app){:target="\_blank"}.
+
+The sample application is a simple Spring Boot web app, that displays an environment variable, `MY_MYSQL_DB` on the page:
+
+```java
+public class HelloController {
+
+ String my_sql_db = System.getenv("MY_MYSQL_DB");
+
+ @RequestMapping("/")
+ public String index() {
+ return my_sql_db;
+ }
+```
+
+The project contains a [base](https://kubectl.docs.kubernetes.io/references/kustomize/glossary/#base){:target="\_blank"} and two [overlays](https://kubectl.docs.kubernetes.io/references/kustomize/glossary/#overlay){:target="\_blank"}, one for a staging environment and one for production.
+
+The base manifest holds a dummy variable for `MY_MYSQL_DB` which will be overlayed once we call the kustomize command in our pipeline.
+
+`base/deployment.yaml`
+```yaml
+...
+ env:
+ - name: MY_MYSQL_DB
+ valueFrom:
+ configMapKeyRef:
+ name: the-map
+ key: mysqlDB
+```
+
+We will overlay on top of the manifests a different value for `MY_MYSQL_DB` for the staging environment and production environment.
+
+`overlays/staging/config-map.yaml`
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+ name: the-map
+data:
+ mysqlDB: "staging-mysql.example.com:3306"
+```
+
+`overlays/production/config-map.yaml`
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+ name: the-map
+data:
+ mysqlDB: "prod-mysql.example.com:3306"
+```
+
+In addition, for the production environment, the number of replicas will be overlayed to 3 instead of 1 (as [defined in the base deployment](https://github.com/codefresh-contrib/kustomize-sample-app/blob/32e683f82940de0bf2de2da40fa6b150e2b24b23/base/deployment.yaml#L8){:target="\_blank"}).
+
+`overlays/production/deployment.yaml`
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+ name: the-deployment
+spec:
+ replicas: 3
+```
+
+## Prerequisites
+
+- A [free Codefresh account]({{site.baseurl}}/docs/administration/account-user-management/create-codefresh-account/)
+- A Kubernetes cluster [connected to your Codefresh account]({{site.baseurl}}/docs/integrations/kubernetes/#connect-a-kubernetes-cluster)
+
+## Create the staging environment pipeline
+
+This pipeline will have two stages: clone and deploy.
+
+{% include image.html
+lightbox="true"
+file="/images/examples/deployments/k8s-kustomize-staging-pipeline.png"
+url="/images/examples/deployments/k8s-kustomize-staging-pipeline.png"
+alt="Codefresh UI Pipeline View"
+caption="Codefresh UI Pipeline View"
+max-width="100%"
+%}
+
+You should be able to copy and paste this YAML in the in-line pipeline editor of the Codefresh UI. However, make sure to replace cluster context for the kubectl command under the arguments section with your own that you integrated with Codefresh. It will automatically clone the project for you and deploy.
+
+`staging-codefresh.yml`
+{% highlight yaml %}
+{% raw %}
+# More examples of Codefresh YAML can be found at
+# https://codefresh.io/docs/docs/example-catalog/
+
+version: "1.0"
+# Stages can help you organize your steps in stages
+
+stages:
+ - clone
+ - deploy
+
+steps:
+ clone:
+ title: Cloning main repository...
+ type: git-clone
+ stage: clone
+ arguments:
+ repo: https://github.com/codefresh-contrib/kustomize-sample-app.git
+ git: github
+ revision: master
+
+ deploy:
+ title: Deploying to Staging using Kustomize...
+ type: freestyle
+ stage: deploy
+ working_directory: ${{clone}}
+ arguments:
+ image: codefresh/kubectl:1.14.9
+ commands:
+ - kubectl config use-context anna-sandbox@codefresh-support
+ - kubectl apply -k overlays/staging
+{% endraw %}
+{% endhighlight %}
+
+The above pipeline does the following:
+1. Clones the main repository through a [git-clone step]({{site.baseurl}}/docs/pipelines/steps/git-clone/).
+2. Connects to our Kubernetes cluster we have integrated with Codefresh using `kubectl`, and deploys the application as a staging environment with the appropriate value for `MY_MYSQL_DB` as defined in our configMap using Kustomize (the `-k` flag), through a [freestyle step]({{site.baseurl}}/docs/pipelines/steps/freestyle/).
+
+>If you are using `kubectl` prior to 1.14, you can use the following command to deploy with Kustomize:
+ `kustomize build overlays/production | kubectl apply -f`
+
+## Create the production environment pipeline
+
+Likewise, this pipeline will have two stages: clone and deploy.
+
+{% include image.html
+lightbox="true"
+file="/images/examples/deployments/k8s-kustomize-prod-pipeline.png"
+url="/images/examples/deployments/k8s-kustomize-prod-pipeline.png"
+alt="Codefresh UI Pipeline View"
+caption="Codefresh UI Pipeline View"
+max-width="100%"
+%}
+
+You should be able to copy and paste this YAML in the in-line editor of the Codefresh UI and remember to replace cluster context for the kubectl command again with your own. Click Save and Run and it will automatically clone the project for you.
+
+`prod-codefresh.yml`
+{% highlight yaml %}
+{% raw %}
+# More examples of Codefresh YAML can be found at
+# https://codefresh.io/docs/docs/example-catalog/
+
+version: "1.0"
+# Stages can help you organize your steps in stages
+
+stages:
+ - clone
+ - deploy
+
+steps:
+ clone:
+ title: Cloning main repository...
+ type: git-clone
+ stage: clone
+ arguments:
+ repo: https://github.com/codefresh-contrib/kustomize-sample-app.git
+ git: github
+ revision: master
+
+ deploy:
+ title: Deploying to Production using Kustomize...
+ type: freestyle
+ stage: deploy
+ working_directory: ${{clone}}
+ arguments:
+ image: codefresh/kubectl:1.14.9
+ commands:
+ - kubectl config use-context anna-sandbox@codefresh-support
+ - kubectl apply -k overlays/production
+{% endraw %}
+{% endhighlight %}
+
+The above pipeline does the following:
+
+1. Clones the main repository through a [git-clone step]({{site.baseurl}}/docs/pipelines/steps/git-clone/).
+1. Connects to our Kubernetes cluster we have integrated with Codefresh using `kubectl`, and deploys the application as a staging environment with the appropriate value for `MY_MYSQL_DB` as defined in our configMap using Kustomize (the `-k` flag), through a [freestyle step]({{site.baseurl}}/docs/pipelines/steps/freestyle/).
+
+
+>Note that if you are using kubectl prior to 1.14, you can use the following command to deploy with Kustomize:
+>`kustomize build overlays/production | kubectl apply -f`
+
+## Verification
+
+After you run these pipelines, your deployments are displayed in the [Kubernetes dashboard]({{site.baseurl}}/docs/deployments/kubernetes/manage-kubernetes/#accessing-the-kubernetes-dashboard).
+
+{% include image.html
+lightbox="true"
+file="/images/examples/deployments/k8s-kustomize-dashboard.png"
+url="/images/examples/deployments/k8s-kustomize-dashboard.png"
+alt="Codefresh Kubernetes Deployments"
+caption="Codefresh Kubernetes Deployments"
+max-width="100%"
+%}
+
+You can test that the application deployed correctly to both environments by accessing the endpoints:
+
+{% include image.html
+lightbox="true"
+file="/images/examples/deployments/k8s-kustomize-staging-endpoint.png"
+url="/images/examples/deployments/k8s-kustomize-staging-endpoint.png"
+alt="Staging endpoint"
+caption="Staging endpoint"
+max-width="100%"
+%}
+
+{% include image.html
+lightbox="true"
+file="/images/examples/deployments/k8s-kustomize-prod-endpoint.png"
+url="/images/examples/deployments/k8s-kustomize-prod-endpoint.png"
+alt="Production endpoint"
+caption="Production endpoint"
+max-width="100%"
+%}
+
+
+## Related articles
+[CD pipeline examples]({{site.baseurl}}/docs/example-catalog/examples/#cd-examples)
+[Deployment options for Kubernetes]({{site.baseurl}}/docs/deployments/kubernetes/deployment-options-to-kubernetes)
+[Running custom kubectl commands]({{site.baseurl}}/docs/deployments/kubernetes/custom-kubectl-commands/)
+[Deploy with Helm]({{site.baseurl}}/docs/example-catalog/cd-examples/helm/)
+
diff --git a/_docs/example-catalog/cd-examples/docker-swarm.md b/_docs/example-catalog/cd-examples/docker-swarm.md
new file mode 100644
index 000000000..752256901
--- /dev/null
+++ b/_docs/example-catalog/cd-examples/docker-swarm.md
@@ -0,0 +1,222 @@
+---
+title: "Deploy to Docker SWARM"
+description: "Deploy to Docker Swarm with Codefresh"
+group: example-catalog
+sub_group: cd-examples
+redirect_from:
+ - /docs/yaml-examples/examples/docker-swarm/
+ - /docs/docker-swarm/
+ - /docs/deploy-to-docker-swarm/
+ - /docs/deploy-your-containers/docker-swarm/
+toc: true
+---
+
+Codefresh can easily deploy your application to [Docker Swarm](https://docs.docker.com/engine/swarm/){:target="\_blank"} using [Codefresh pipelines]({{site.baseurl}}/docs/pipelines/pipelines/).
+
+You will need to provide:
+
+1. The `docker-stack.yml` that contains the definition of the application
+1. The host where your Docker Swarm is running
+1. An SSH key that Codefresh can use to access remotely the Docker Swarm host
+1. The stack name that will be used once the application is deployed
+
+All this information will be passed to the pipeline in the form of build parameters.
+
+
+## Example application
+
+For an example Docker Swarm application, see [https://github.com/codefreshdemo/example-voting-app](https://github.com/codefreshdemo/example-voting-app){:target="\_blank"}
+
+To launch it locally you need to download [Docker](https://www.docker.com/products/overview){:target="\_blank"}.
+If you are on Mac or Windows, [Docker Compose](https://docs.docker.com/compose){:target="\_blank"} is automatically installed.
+On Linux, make sure you have the latest version of [Compose](https://docs.docker.com/compose/install/){:target="\_blank"}.
+
+
+Run in this root directory:
+
+{% highlight bash %}
+{% raw %}
+
+docker-compose up
+
+{% endraw %}
+{% endhighlight %}
+
+The app runs at `http://localhost:5000`, and the results are at `http://localhost:5001`.
+
+Alternately, if you want to run it on a Docker Swarm, first make sure you have a Swarm.
+If you don't, run:
+
+{% highlight bash %}
+{% raw %}
+
+docker swarm init
+
+{% endraw %}
+{% endhighlight %}
+
+Once you have your swarm, in this directory run:
+
+{% highlight bash %}
+{% raw %}
+
+docker stack deploy --compose-file docker-stack.yml vote
+
+{% endraw %}
+{% endhighlight %}
+
+{{site.data.callout.callout_warning}}
+The swarm master must have Python installed.
+{{site.data.callout.end}}
+
+## Deploy to Remote Swarm with Codefresh
+
+First you need to set up the following environment variables in your Codefresh pipeline:
+
+{: .table .table-bordered .table-hover}
+| `RDOCKER_HOST` | remote Docker Swarm master machine, accessible over SSH (for example, ubuntu@ec2-public-ip) |
+| `STACK_NAME` | is new Docker stack name (use \"vote\", for example) |
+| `SSH_KEY` | private SSH key, used to access Docker Swarm master machine |
+| `SPLIT_CHAR` | split character, you've used to replace `newline` in SSH key. Recommendation: use `,` (`comma` character). |
+
+The `SSH_KEY` variable has the contents of the [SSH key](https://www.ssh.com/ssh/public-key-authentication){:target="\_blank"} that can access the Docker Swarm host. Currently, in order to pass SSH key through Codefresh UI, you need to convert it to single line string (replacing `newline` with `comma`), like this:
+
+{% highlight bash %}
+{% raw %}
+SSH_KEY=$(cat ~/.ssh/my_ssh_key_file | tr '\n' ',')
+{% endraw %}
+{% endhighlight %}
+
+The `SPLIT_CHAR` variable should hold the replacement character that was used for the SSH key (in the example above it is the comma character)
+
+{% include image.html
+lightbox="true"
+file="/images/examples/docker-swarm/codefresh_env_vars.png"
+url="/images/examples/docker-swarm/codefresh_env_vars.png"
+alt="Docker Swarm build parameters"
+caption="Docker Swarm build parameters"
+max-width="70%"
+%}
+
+
+## Deploy to Docker Swarm with a YAML step
+
+Once you have defined all the variables, deploy to your cluster using the following [freestyle step]({{site.baseurl}}/docs/pipelines/steps/freestyle/).
+
+ `codefresh.yml`
+{% highlight yaml %}
+{% raw %}
+
+deploy_to_swarm:
+ image: codefresh/remote-docker
+ working_directory: ${{main_clone}}
+ commands:
+ - rdocker ${{RDOCKER_HOST}} docker stack deploy --compose-file docker-stack.yml ${{STACK_NAME}}
+ environment:
+ - SSH_KEY=${{SSH_KEY}}
+ when:
+ branch:
+ only:
+ - master
+
+{% endraw %}
+{% endhighlight %}
+
+You can also pass custom credentials like this:
+
+ `codefresh.yml`
+{% highlight yaml %}
+{% raw %}
+
+deploy_to_swarm:
+ image: codefresh/remote-docker
+ working_directory: ${{main_clone}}
+ commands:
+ - rdocker ${{RDOCKER_HOST}} docker login ${{MY_REGISTRY}} -u ${{MY_REGISTRY_USER}} -p ${{MY_REGISTRY_PASSWORD}} \&\& docker stack deploy --compose-file docker-compose.yml --with-registry-auth ${{STACK_NAME}}
+ environment:
+ - SSH_KEY=${{SSH_KEY}}
+ when:
+ branch:
+ only:
+ - master
+{% endraw %}
+{% endhighlight %}
+
+
+
+## Create a CI/CD pipeine for Docker Swarm
+
+Here is the complete pipeline:
+
+{% include
+image.html
+lightbox="true"
+file="/images/examples/docker-swarm/docker-swarm-pipeline.png"
+url="/images/examples/docker-swarm/docker-swarm-pipeline.png"
+alt="Docker Swarm pipeline"
+caption="Docker Swarm pipeline"
+max-width="100%"
+%}
+
+And here is the pipeline definition:
+
+ `codefresh.yml`
+{% highlight yaml %}
+{% raw %}
+version: '1.0'
+stages:
+ - prepare
+ - build
+ - deploy
+steps:
+ main_clone:
+ title: Cloning main repository...
+ stage: prepare
+ type: git-clone
+ repo: 'codefreshdemo/example-voting-app'
+ revision: master
+ git: github-1
+ MyResultDockerImage:
+ title: Building Result Docker Image
+ stage: build
+ type: build
+ image_name: resultApp
+ working_directory: ./result/
+ tag: master
+ dockerfile: Dockerfile
+ MyVoteDockerImage:
+ title: Building Vote Docker Image
+ stage: build
+ type: build
+ image_name: voteApp
+ working_directory: ./vote/
+ tag: master
+ dockerfile: Dockerfile
+ MyWorkerDockerImage:
+ title: Building Worker Docker Image
+ stage: build
+ type: build
+ image_name: workedApp
+ working_directory: ./worker/
+ tag: master
+ dockerfile: Dockerfile
+ DeployToSwarmNow:
+ image: codefresh/remote-docker
+ working_directory: ${{main_clone}}
+ stage: deploy
+ commands:
+ - rdocker ${{RDOCKER_HOST}} docker login ${{MY_REGISTRY}} -u ${{MY_REGISTRY_USER}} -p ${{MY_REGISTRY_PASSWORD}} \&\& docker stack deploy --compose-file docker-compose.yml --with-registry-auth ${{STACK_NAME}}
+ environment:
+ - SSH_KEY=${{SSH_KEY}}
+{% endraw %}
+{% endhighlight %}
+
+The values of `MY_REGISTRY`, `MY_REGISTRY_USER` and `MY_REGISTRY_PASSWORD` depend upon the type of [your connected registry]({{site.baseurl}}/docs/integrations/docker-registries/).
+
+## Related articles
+[CD pipeline examples]({{site.baseurl}}/docs/example-catalog/examples/#cd-examples)
+[Codefresh YAML for pipeline definitions]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/)
+[Steps in pipelines]({{site.baseurl}}/docs/pipelines/steps/)
+[Creating pipelines]({{site.baseurl}}/docs/pipelines/pipelines/)
+[How Codefresh pipelines work]({{site.baseurl}}/docs/pipelines/introduction-to-codefresh-pipelines/)
+
diff --git a/_docs/example-catalog/cd-examples/elastic-beanstalk.md b/_docs/example-catalog/cd-examples/elastic-beanstalk.md
new file mode 100644
index 000000000..ef1da01f3
--- /dev/null
+++ b/_docs/example-catalog/cd-examples/elastic-beanstalk.md
@@ -0,0 +1,137 @@
+---
+title: "Deploy to Elastic Beanstalk"
+description: ""
+group: example-catalog
+sub_group: cd-examples
+redirect_from:
+ - /docs/yaml-examples/examples/elastic-beanstalk/
+ - /docs/elastic-beanstalk/
+ - /docs/deploy-your-containers/elastic-beanstalk/
+toc: true
+---
+
+
+## Prerequisites
+
+- Configured Application in Elastic Beanstalk service
+ See: [http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/GettingStarted.html](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/GettingStarted.html){:target="_blank"}
+
+
+## Deployment with Codefresh
+- Add encrypted environment variables for AWS credentials:
+ * `AWS_ACCESS_KEY_ID`
+ * `AWS_SECRET_ACCESS_KEY`
+
+- Provide the following environment variables:
+ * `AWS_REGION`
+ * `AWS_ENV_NAME`
+ * `AWS_VERSION`
+ * `AWS_BRANCH`
+
+{% include
+image.html
+lightbox="true"
+file="/images/examples/elastic-beanstalk/codefresh_eb_env_vars.png"
+url="/images/examples/elastic-beanstalk/codefresh_eb_env_vars.png"
+alt="codefresh_eb_env_vars.png"
+max-width="40%"
+%}
+
+{{site.data.callout.callout_info}}
+{% raw %}
+The ``${{AWS_VERSION}}`` of application you can find in the Elastic Beanstalk service.
+{% endraw %}
+{{site.data.callout.end}}
+
+{% include
+image.html
+lightbox="true"
+file="/images/examples/elastic-beanstalk/codefresh_eb_version_label.png"
+url="/images/examples/elastic-beanstalk/codefresh_eb_version_label.png"
+alt="codefresh_eb_version_label.png"
+max-width="40%"
+%}
+
+{{site.data.callout.callout_info}}
+{% raw %}
+The ``${{AWS_ENV_NAME}}`` of application you can find in the Elastic Beanstalk service.
+{% endraw %}
+{{site.data.callout.end}}
+
+{% include
+image.html
+lightbox="true"
+file="/images/examples/elastic-beanstalk/codefresh_eb_environment.png"
+url="/images/examples/elastic-beanstalk/codefresh_eb_environment.png"
+alt="codefresh_eb_environment.png"
+max-width="40%"
+%}
+
+Add the following step to codefresh.yml:
+
+ `deploy_step`
+{% highlight yaml %}
+{% raw %}
+deploy-elastic-beanstalk:
+ fail-fast: false
+ image: garland/aws-cli-docker:latest
+ commands:
+ - sh -c "aws configure set region '${{AWS_REGION}}' && aws elasticbeanstalk update-environment --environment-name '${{AWS_ENV_NAME}}' --version-label '${{AWS_VERSION}}' "
+ when:
+ condition:
+ all:
+ masterBranch: "'${{CF_BRANCH}}' == '${{AWS_BRANCH}}'"
+{% endraw %}
+{% endhighlight %}
+
+{:.text-secondary}
+## Deployment Flow
+- Go to the Elastic Beanstalk service and create an application and environment.
+
+
+{% include
+image.html
+lightbox="true"
+file="/images/examples/elastic-beanstalk/codefresh_eb_environment-deploy.png"
+url="/images/examples/elastic-beanstalk/codefresh_eb_environment-deploy.png"
+alt="codefresh_eb_environment.png"
+max-width="40%"
+%}
+
+- Perform the following commands from root of your project:
+ * eb init
+ * eb create {% raw %}`${{AWS_ENV_NAME}}`{% endraw %}
+
+
+
+>Note:
+ If you don't have awsebcli - install EB CLI [http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/eb-cli3-install.html](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/eb-cli3-install.html){:target="_blank"}.
+
+
+{% include
+image.html
+lightbox="true"
+file="/images/examples/elastic-beanstalk/codefresh_eb_health.png"
+url="/images/examples/elastic-beanstalk/codefresh_eb_health.png"
+alt="codefresh_eb_health.png"
+max-width="40%"
+%}
+
+- Add this repository to Codefresh, provide the necessary environments variables and build this service
+
+{% include
+image.html
+lightbox="true"
+file="/images/examples/elastic-beanstalk/codefresh_eb_cf_step_deploy.png"
+url="/images/examples/elastic-beanstalk/codefresh_eb_cf_step_deploy.png"
+alt="codefresh_eb_cf_step_deploy.png"
+max-width="40%"
+%}
+
+## Example
+
+* [cf-example-deploy-elasticbeanstalk](https://github.com/codefreshdemo/cf-example-deploy-elasticbeanstalk){:target="_blank"}
+
+
+## Related articles
+[CD pipeline examples]({{site.baseurl}}/docs/example-catalog/examples/#cd-examples)
diff --git a/_docs/example-catalog/cd-examples/gitops-secrets.md b/_docs/example-catalog/cd-examples/gitops-secrets.md
new file mode 100644
index 000000000..3d3486e91
--- /dev/null
+++ b/_docs/example-catalog/cd-examples/gitops-secrets.md
@@ -0,0 +1,231 @@
+---
+title: "Secrets with GitOps"
+description: "Store secrets in Git with Bitnami sealed secrets"
+group: example-catalog
+sub_group: cd-examples
+redirect_from:
+ - /docs/yaml-examples/examples/gitops-secrets/
+toc: true
+---
+
+## Prerequisites
+
+- A [free Codefresh account]({{site.baseurl}}/docs/administration/account-user-management/create-codefresh-account/)
+- A Kubernetes cluster
+- The [Codefresh GitOps agent]({{site.baseurl}}/docs/integrations/argocd/) installed on the cluster
+
+## Using the Bitnami Sealed secrets controller
+
+If you follow [GitOps](https://codefresh.io/gitops/){:target="\_blank"}, then you should already know that everything should be placed under source control, and Git is to be used as the single source of truth.
+
+This presents a challenge with secrets that are needed by the application, as they must never be stored in Git in clear text under any circumstance.
+
+To solve this issue, we can use the [Bitnami Sealed secrets controller](https://github.com/bitnami-labs/sealed-secrets){:target="\_blank"}. This is a Kubernetes controller that can be used to encrypt/decrypt your application secrets in a secure way.
+
+The order of events is the following:
+
+1. You install the Bitnami Sealed secrets controller in the cluster. It generates a public and private key. The private key stays in the cluster and is never revealed.
+1. You take a raw secret and use the `kubeseal` utility to encrypt it. Encryption happens with the public key of the cluster that you can give to anybody.
+1. The encrypted secrets are stored in Git. There are safe to be committed and nobody can decrypt them without direct access to the cluster
+1. During runtime you deploy the sealed secret like any other Kubernetes manifest. The controller converts them to [plain Kubernetes secrets](https://kubernetes.io/docs/concepts/configuration/secret/){:target="\_blank"} on the fly using the private key of the cluster
+1. Your application reads the secrets like any other Kubernetes secret. Your application doesn't need to know anything about the sealed secrets controller or how the encryption decryption works.
+
+
+To use the controller first install it in your cluster:
+
+```
+helm repo add sealed-secrets https://bitnami-labs.github.io/sealed-secrets
+helm repo update
+helm install sealed-secrets-controller sealed-secrets/sealed-secrets
+```
+
+By default, the controller is installed at the `kube-system` namespace. The namespace
+and release names are important, since if you change the defaults, you need to set them up
+with `kubeseal` as well, as you work with secrets.
+
+Download the `kubeseal` CLI:
+```
+wget https://github.com/bitnami-labs/sealed-secrets/releases/download/v0.16.0/kubeseal-linux-amd64 -O kubeseal
+sudo install -m 755 kubeseal /usr/local/bin/kubeseal
+```
+
+## Example application
+
+You can find the example project at [https://github.com/codefresh-contrib/gitops-secrets-sample-app](https://github.com/codefresh-contrib/gitops-secrets-sample-app){:target="\_blank"}.
+
+It is a web application that prints out several secrets which are [read from the filesystem](https://github.com/codefresh-contrib/gitops-secrets-sample-app/blob/main/settings.ini){:target="\_blank"}:
+
+`settings.ini`
+```ini
+[security]
+# Path to key pair
+private_key = /secrets/sign/key.private
+public_key= /secrets/sign/key.pub
+
+[paypal]
+paypal_url = https://development.paypal.example.com
+paypal_cert=/secrets/ssl/paypal.crt
+
+[mysql]
+db_con= /secrets/mysql/connection
+db_user = /secrets/mysql/username
+db_password = /secrets/mysql/password
+```
+
+The application itself knows nothing about Kubernetes secrets, mounted volumes or any other cluster resource. It only reads its own filesystem at `/secrets`
+
+This folder is populated inside the pod with [secret mounting](https://github.com/codefresh-contrib/gitops-secrets-sample-app/blob/main/safe-to-commit/manifests/deployment.yml){:target="\_blank"}:
+
+```yaml
+---
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+ name: gitops-secrets-deploy
+spec:
+ replicas: 1
+ selector:
+ matchLabels:
+ app: gitops-secrets-app
+ template:
+ metadata:
+ labels:
+ app: gitops-secrets-app
+ spec:
+ containers:
+ - name: gitops-secrets-app
+ image: docker.io/kostiscodefresh/gitops-secrets-sample-app:latest
+ imagePullPolicy: Always
+ ports:
+ - containerPort: 8080
+ volumeMounts:
+ - name: mysql
+ mountPath: "/secrets/mysql"
+ readOnly: true
+ - name: paypal
+ mountPath: "/secrets/ssl"
+ readOnly: true
+ - name: sign-keys
+ mountPath: "/secrets/sign/"
+ readOnly: true
+ livenessProbe:
+ httpGet:
+ path: /health
+ port: 8080
+ readinessProbe:
+ httpGet:
+ path: /health
+ port: 8080
+ volumes:
+ - name: mysql
+ secret:
+ secretName: mysql-credentials
+ - name: paypal
+ secret:
+ secretName: paypal-cert
+ - name: sign-keys
+ projected:
+ sources:
+ - secret:
+ name: key-private
+ - secret:
+ name: key-public
+
+```
+
+This way there is a clear separation of concerns.
+
+
+
+You can find the secrets themselves at [https://github.com/codefresh-contrib/gitops-secrets-sample-app/tree/main/never-commit-to-git/unsealed_secrets](https://github.com/codefresh-contrib/gitops-secrets-sample-app/tree/main/never-commit-to-git/unsealed_secrets){:target="\_blank"}. There are encoded with base64 so they are **NOT** safe to commit in Git.
+
+>Note that for demonstration purposes, the Git repository contains raw secrets so that you can encrypt them yourself. In a production application, the Git repository must only contain sealed/encrypted secrets.
+
+## Preparing the secrets
+
+The critical point of this application is to encrypt all the secrets and place them in Git.
+By default, the sealed secrets controller encrypts a secret according to a specific namespace (this behavior is configurable), so you need to decide in advance which namespace wil host the application.
+
+Then encrypt all secrets as below:
+
+```
+kubectl create ns git-secrets
+cd safe-to-commit/sealed_secrets
+kubeseal -n git-secrets < ../../never-commit-to-git/unsealed_secrets/db-creds.yml > db-creds.json
+kubeseal -n git-secrets < ../../never-commit-to-git/unsealed_secrets/key-private.yml > key-private.json
+kubeseal -n git-secrets < ../../never-commit-to-git/unsealed_secrets/key-public.yml > key-public.json
+kubeseal -n git-secrets < ../../never-commit-to-git/unsealed_secrets/paypal-cert.yml > paypal-cert.json
+kubectl apply -f . -n git-secrets
+
+```
+
+You now have encrypted your plain secrets. These files are safe to commit to Git.
+You can see that they have been converted automatically to plain secrets with the command:
+
+```
+kubectl get secrets -n git-secrets
+```
+
+## Manually deploying the application
+
+Note that the application requires all secrets to be present:
+
+```
+cd safe-to-commit/manifests
+kubectl apply -f . -n git-secrets
+```
+
+You can now visit the application url to see how it has access to all the secrets.
+
+
+## Deploying the application with Codefresh GitOps
+
+Of course the big advantage of having everything committed into Git, is the ability to adopt GitOps
+for the whole application (including secrets).
+
+This means that you can simply [point Codefresh GitOps to your repository]({{site.baseurl}}/docs/integrations/argocd/#creating-argocd-applications) and have the application
+automatically deploy in the cluster.
+
+{% include image.html
+lightbox="true"
+file="/images/examples/sealed-secrets/add-app.png"
+url="/images/examples/sealed-secrets/add-app.png"
+alt="Creating a GitOps application"
+caption="Creating a GitOps application"
+max-width="50%"
+%}
+
+You can then see the application in the GitOps dashboard:
+
+{% include image.html
+lightbox="true"
+file="/images/examples/sealed-secrets/current-state.png"
+url="/images/examples/sealed-secrets/current-state.png"
+alt="GitOps dashboard"
+caption="GitOps dashboard"
+max-width="90%"
+%}
+
+If you visit its URL you will see the secrets being loaded:
+
+{% include image.html
+lightbox="true"
+file="/images/examples/sealed-secrets/app-secrets.png"
+url="/images/examples/sealed-secrets/app-secrets.png"
+alt="Application using secrets"
+caption="Application using secrets"
+max-width="90%"
+%}
+
+
+>Note that for simplicity reasons the same Git repository holds both the application source code and its
+manifests. In an actual application, you should have two Git repositories (one of the source code only and one of the manifests).
+
+
+## Related articles
+[CI pipeline examples]({{site.baseurl}}/docs/example-catalog/examples/#ci-examples)
+[Codefresh GitOps]({{site.baseurl}}/docs/ci-cd-guides/gitops-deployments/)
+[Using secrets]({{site.baseurl}}/docs/pipelines/configuration/secrets-store/)
+[Secrets with Mozilla Sops]({{site.baseurl}}/docs/example-catalog/ci-examples/decryption-with-mozilla-sops/)
+[Vault Secrets in the Pipeline]({{site.baseurl}}/docs/example-catalog/ci-examples/vault-secrets-in-the-pipeline/)
+
diff --git a/_docs/example-catalog/cd-examples/helm.md b/_docs/example-catalog/cd-examples/helm.md
new file mode 100644
index 000000000..8982b87a2
--- /dev/null
+++ b/_docs/example-catalog/cd-examples/helm.md
@@ -0,0 +1,228 @@
+---
+title: "Deploy with Helm"
+description: "Use Helm in a Codefresh pipeline"
+group: example-catalog
+sub_group: cd-examples
+redirect_from:
+ - /docs/yaml-examples/examples/helm/
+toc: true
+---
+
+[Helm](https://helm.sh/){:target="\_blank"} is the package manager for Kubernetes.
+Codefresh has comprehensive support for Helm:
+
+* Free [built-in Helm repository]({{site.baseurl}}/docs/deployments/helm/managed-helm-repository/) with each Codefresh account
+* [Helm chart dashboard]({{site.baseurl}}/docs/deployments/helm/helm-charts-and-repositories/) to track your charts
+* [Helm Release dashboard]({{site.baseurl}}/docs/deployments/helm/helm-releases-management/) to view your deployments
+* [Environment dashsboard]({{site.baseurl}}/docs/deployments/kubernetes/environment-dashboard/) to view Helm releases
+* [Helm promotion dashboard]({{site.baseurl}}/docs/deployments/helm/helm-environment-promotion/) to promote Helm releases
+* Add any external Helm repository on any other cloud provider
+
+Codefresh also provides a [pipeline step]({{site.baseurl}}/docs/deployments/helm/using-helm-in-codefresh-pipeline/) for deploying with Helm.
+
+For more insights on Helm charts see also our [Helm best practices]({{site.baseurl}}/docs/ci-cd-guides/helm-best-practices/) guide.
+
+
+## The example Helm project
+
+You can see the example project at [https://github.com/codefresh-contrib/helm-sample-app](https://github.com/codefresh-contrib/helm-sample-app){:target="\_blank"}. The repository contains a simple Go application, a Dockerfile and an example chart.
+
+
+## Prerequisites
+
+[At least one Kubernetes cluster]({{site.baseurl}}/docs/integrations/kubernetes/#connect-a-kubernetes-cluster) in your Codefresh account.
+
+
+
+
+
+## CI/CD pipeline with Helm deployment
+
+It is possible to deploy directly a Helm chart as it exists on the filesystem. This is not the recommended way to use Helm, because you are bypassing the Helm chart repository, but it is certainly the simplest Helm pipeline possible.
+
+{% include image.html
+lightbox="true"
+file="/images/examples/helm/helm-deploy-pipeline.png"
+url="/images/examples/helm/helm-deploy-pipeline.png"
+alt="Pipeline for Helm deployment"
+caption="Pipeline for Helm deployment"
+max-width="100%"
+%}
+
+Here is the whole pipeline:
+
+ `codefresh-do-not-store.yml`
+{% highlight yaml %}
+{% raw %}
+version: '1.0'
+stages:
+ - prepare
+ - build
+ - deploy
+steps:
+ clone:
+ title: Cloning main repository...
+ stage: prepare
+ type: git-clone
+ arguments:
+ repo: codefresh-contrib/helm-sample-app
+ revision: master
+ git: github
+ build:
+ title: Building Docker Image
+ stage: build
+ type: build
+ working_directory: ./helm-sample-app
+ arguments:
+ image_name: helm-sample-app-go
+ tag: multi-stage
+ dockerfile: Dockerfile
+ deploy:
+ title: Deploying Helm Chart
+ type: helm
+ stage: deploy
+ working_directory: ./helm-sample-app
+ arguments:
+ action: install
+ chart_name: charts/helm-example
+ release_name: my-go-chart-prod
+ helm_version: 3.0.2
+ kube_context: my-demo-k8s-cluster
+ custom_values:
+ - 'buildID=${{CF_BUILD_ID}}'
+ - 'image_pullPolicy=Always'
+ - 'image_tag=multi-stage'
+ - 'replicaCount=3'
+ - 'image_pullSecret=codefresh-generated-r.cfcr.io-cfcr-default'
+{% endraw %}
+{% endhighlight %}
+
+This pipeline does the following:
+
+1. Clones the source code through a [Git clone step]({{site.baseurl}}/docs/pipelines/steps/git-clone/)
+1. Builds a docker image through a [build step]({{site.baseurl}}/docs/pipelines/steps/build/)
+1. Deploys the Helm chart to a cluster named `my-demo-k8s-cluster` using the Helm step [from the Step Marketplace](https://codefresh.io/steps/step/helm){:target="\_blank"}.
+
+In this example, `charts/helm-example` refers to the [filesystem location in the code](https://github.com/codefresh-contrib/helm-sample-app/tree/master/charts/helm-example){:target="\_blank"} that was just checked out.
+
+The deployment will be visible in the [Helm releases dashboard]({{site.baseurl}}/docs/deployments/helm/helm-releases-management/).
+
+{% include image.html
+lightbox="true"
+file="/images/examples/helm/helm-release.png"
+url="/images/examples/helm/helm-release.png"
+alt="Helm release view"
+caption="Helm release view"
+max-width="100%"
+%}
+
+If you want to run this example yourself, make sure to edit the chart and put your own values there for the Docker image.
+
+## CI/CD pipeline with Helm deployment that also stores the chart
+
+It is recommended to use a Helm repository to store your chart before deploying it. This way you know what is deployed in your clusters
+and you can also reuse charts in other installations.
+
+First of all you need to import in your pipeline from the [shared configuration]({{site.baseurl}}/docs/pipelines/configuration/shared-configuration/) the settings for the internal Helm repository (or any other external repository that you have setup in Codefresh).
+ This will make available the internal Helm repository to your pipeline so that it can push/pull Helm charts from it.
+
+ {% include image.html
+ lightbox="true"
+ file="/images/examples/helm/import-helm-configuration.png"
+ url="/images/examples/helm/import-helm-configuration.png"
+ alt="Using the default Helm repository in a Pipeline"
+ caption="Using the default Helm repository in a Pipeline"
+ max-width="40%"
+ %}
+
+Once that is done you can change your pipeline to also store the chart first and *then* deploy it.
+
+
+{% include image.html
+lightbox="true"
+file="/images/examples/helm/helm-push-and-deploy-pipeline.png"
+url="/images/examples/helm/helm-push-and-deploy-pipeline.png"
+alt="Pipeline for Helm deployment that stores chart"
+caption="Pipeline for Helm deployment that stores chart"
+max-width="100%"
+%}
+
+Here is the whole pipeline:
+
+ `codefresh.yml`
+{% highlight yaml %}
+{% raw %}
+version: '1.0'
+stages:
+ - prepare
+ - build
+ - store
+ - deploy
+steps:
+ clone:
+ title: Cloning main repository...
+ stage: prepare
+ type: git-clone
+ arguments:
+ repo: codefresh-contrib/helm-sample-app
+ revision: master
+ git: github
+ build:
+ title: Building Docker Image
+ stage: build
+ type: build
+ working_directory: ./helm-sample-app
+ arguments:
+ image_name: helm-sample-app-go
+ tag: multi-stage
+ dockerfile: Dockerfile
+ store:
+ title: Storing Helm Chart
+ type: helm
+ stage: store
+ working_directory: ./helm-sample-app
+ arguments:
+ action: push
+ chart_name: charts/helm-example
+ kube_context: my-demo-k8s-cluster
+ deploy:
+ type: helm
+ stage: deploy
+ working_directory: ./helm-sample-app
+ arguments:
+ action: install
+ chart_name: charts/helm-example
+ release_name: my-go-chart-prod
+ helm_version: 3.0.2
+ kube_context: my-demo-k8s-cluster
+ custom_values:
+ - 'buildID=${{CF_BUILD_ID}}'
+ - 'image_pullPolicy=Always'
+ - 'image_tag=multi-stage'
+ - 'replicaCount=3'
+ - 'image_pullSecret=codefresh-generated-r.cfcr.io-cfcr-default'
+{% endraw %}
+{% endhighlight %}
+
+
+After you finish running your pipeline, not only the deployment will take place, but you will also see your chart in your [Helm Chart dashboard]({{site.baseurl}}/docs/deployments/helm/helm-charts-and-repositories/):
+
+{% include image.html
+lightbox="true"
+file="/images/examples/helm/helm-chart.png"
+url="/images/examples/helm/helm-chart.png"
+alt="Stored Helm chart"
+caption="Stored Helm chart"
+max-width="80%"
+%}
+
+It is also possible to [run your own Helm commands]({{site.baseurl}}/docs/deployments/helm/using-helm-in-codefresh-pipeline/#example-custom-helm-commands) in a Codefresh pipeline.
+
+
+## Related articles
+[CD pipeline examples]({{site.baseurl}}/docs/example-catalog/examples/#cd-examples)
+[Codefresh YAML for pipeline definitions]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/)
+[Steps in pipelines]({{site.baseurl}}/docs/pipelines/steps/)
+[Creating pipelines]({{site.baseurl}}/docs/pipelines/pipelines/)
+[How Codefresh pipelines work]({{site.baseurl}}/docs/pipelines/introduction-to-codefresh-pipelines/)
diff --git a/_docs/example-catalog/cd-examples/nomad.md b/_docs/example-catalog/cd-examples/nomad.md
new file mode 100644
index 000000000..65d9440a8
--- /dev/null
+++ b/_docs/example-catalog/cd-examples/nomad.md
@@ -0,0 +1,227 @@
+---
+title: "Deploy to Nomad"
+description: "Deploy Docker images to a Nomad cluster with Codefresh"
+group: example-catalog
+sub_group: cd-examples
+redirect_from:
+ - /docs/yaml-examples/examples/nomad/
+toc: true
+---
+
+Even though Codefresh has great support for Kubernetes and Helm deployments, there is no lock-in on using just Kubernetes. Codefresh can deploy on any infrastructure.
+
+
+[Nomad](https://www.nomadproject.io/){:target="\_blank"} is an alternative scheduling platform from Hashicorp. It supports docker containers (like Kubernetes), but you can also use Nomad to schedule VMs, Java apps, Go apps or any other standalone executable.
+
+There are several public Docker Images with Nomad, so it is very easy to use Codefresh pipelines to deploy to a Nomad cluster.
+
+
+{% include image.html
+lightbox="true"
+file="/images/examples/nomad/nomad-ci-pipeline.png"
+url="/images/examples/nomad/nomad-ci-pipeline.png"
+alt="Deploying to Nomad with Codefresh"
+caption="Deploying to Nomad with Codefresh"
+max-width="80%"
+%}
+
+In this example, we will use the image at [https://hub.docker.com/r/djenriquez/nomad](https://hub.docker.com/r/djenriquez/nomad){:target="\_blank"}.
+
+## The example Nomad project
+
+You can see the example project at [https://github.com/codefresh-contrib/nomad-sample-app](https://github.com/codefresh-contrib/nomad-sample-app){:target="\_blank"}. The repository contains a simple job specification that deploys a docker container on nomad cluster.
+
+
+Here is the whole job file:
+
+ `docker-job.hcl`
+{% highlight hcl %}
+{% raw %}
+job "example-job" {
+ # Specify this job should run in the region named "us". Regions
+ # are defined by the Nomad servers' configuration.
+ #region = "us"
+
+ # Spread the tasks in this job between us-west-1 and us-east-1.
+ datacenters = ["dc1"]
+
+ # Run this job as a "service" type. Each job type has different
+ # properties. See the documentation below for more examples.
+ type = "service"
+
+ # Specify this job to have rolling updates, two-at-a-time, with
+ # 30 second intervals.
+ update {
+ stagger = "30s"
+ max_parallel = 1
+ }
+
+ # A group defines a series of tasks that should be co-located
+ # on the same client (host). All tasks within a group will be
+ # placed on the same host.
+ group "example-group" {
+ # Specify the number of these tasks we want.
+ count = 3
+
+ # Create an individual task (unit of work). This particular
+ # task utilizes a Docker container to front a web application.
+ task "example-task" {
+ # Specify the driver to be "docker". Nomad supports
+ # multiple drivers.
+ driver = "docker"
+
+ # Configuration is specific to each driver.
+ config {
+ image = "r.cfcr.io/$CF_ACCOUNT/$CF_REPO_NAME:$CF_BRANCH_TAG_NORMALIZED"
+
+ auth {
+ username = "$CF_ACCOUNT"
+ password = "$CFCR_LOGIN_TOKEN"
+ server_address = "r.cfcr.io"
+ }
+
+ port_map {
+ http = 8080
+ }
+ }
+
+ # The service block tells Nomad how to register this service
+ # with Consul for service discovery and monitoring.
+ service {
+ # This tells Consul to monitor the service on the port
+ # labelled "http". Since Nomad allocates high dynamic port
+ # numbers, we use labels to refer to them.
+ port = "http"
+
+ check {
+ type = "http"
+ path = "/"
+ interval = "10s"
+ timeout = "2s"
+ }
+ }
+
+ # Specify the maximum resources required to run the task,
+ # include CPU, memory, and bandwidth.
+ resources {
+ cpu = 500 # MHz
+ memory = 128 # MB
+
+ network {
+ mbits = 100
+
+
+ port "http" {}
+
+
+
+ }
+ }
+ }
+ }
+}
+
+{% endraw %}
+{% endhighlight %}
+
+Notice that the job specification has several [Codefresh variables]({{site.baseurl}}/docs/pipelines/variables/) embedded. We will use [envsubst](https://www.gnu.org/software/gettext/manual/html_node/envsubst-Invocation.html){:target="\_blank"} in our pipeline to replace
+them with the correct values.
+
+## Prerequisites
+
+You need to create a Codefresh account and have a Nomad cluster running. You need to decide on how Codefresh will communicate
+with the nomad cluster. In this simple example we just use the `NOMAD_ADDR` variable to point the nomad client to our cluster. In a production environment you should use proper [ACL](https://www.nomadproject.io/guides/security/acl.html){:target="\_blank"} and [certificate](https://www.nomadproject.io/guides/security/securing-nomad.html){:target="\_blank"} variables as well.
+
+
+In this example the Nomad cluster is already setup on a VM at Google cloud.
+
+You also need to create a [token for the Docker registry]({{site.baseurl}}/docs/integrations/docker-registries/) so that Nomad can pull your private images on the cluster.
+
+## Create a CI/CD pipeline for Nomad deployments
+
+Here is the whole pipeline:
+
+ `codefresh.yml`
+{% highlight yaml %}
+{% raw %}
+version: "1.0"
+stages:
+ - "clone"
+ - "build"
+ - "deploy"
+steps:
+ main_clone:
+ type: "git-clone"
+ title: "Clone main repository..."
+ repo: "codefresh-contrib/nomad-sample-app"
+ revision: "${{CF_BRANCH}}"
+ stage: "clone"
+ build:
+ title: "Building Docker Image"
+ type: "build"
+ image_name: "nomad-sample-app"
+ tag: "${{CF_BRANCH_TAG_NORMALIZED}}"
+ dockerfile: "Dockerfile"
+ stage: "build"
+ prepareJob:
+ title: "Preparing Nomad job"
+ image: bhgedigital/envsubst
+ stage: deploy
+ commands:
+ - envsubst < docker-job.hcl > docker-job-export.hcl
+ - cat docker-job-export.hcl
+ runJob:
+ title: "Deploying Nomad job"
+ image: djenriquez/nomad
+ stage: deploy
+ commands:
+ - nomad run docker-job-export.hcl
+{% endraw %}
+{% endhighlight %}
+
+This pipeline does the following:
+
+1. Clones the source code through a [Git clone step]({{site.baseurl}}/docs/pipelines/steps/git-clone/).
+1. Creates a Docker image for a simple Go application through a [build step]({{site.baseurl}}/docs/pipelines/steps/build/). The image is automatically pushed to the default Docker registry.
+1. Replaces all variables in the job spec by running `envsubst`. These include:
+ * The Registry token so that Nomad can access the default Docker registry
+ * The docker image name and tag to be deployed
+1. Runs the job to deploy the image to Nomad through a [freestyle step]({{site.baseurl}}/docs/pipelines/steps/freestyle/).
+
+
+Run the pipeline and see your deployment succeed.
+
+Here are the environment variables defined for this pipeline.
+
+{% include image.html
+lightbox="true"
+file="/images/examples/nomad/nomad-variables.png"
+url="/images/examples/nomad/nomad-variables.png"
+alt="Pipeline variables for Nomad deployments"
+caption="Pipeline variables for Nomad deployments"
+max-width="50%"
+%}
+
+
+The `NOMAD_ADDR` variable is holding the URL of the cluster. The `CFCR_LOGIN_TOKEN` variable holds authentication for the Codefresh Docker registry.
+
+## Verify the deployment
+
+Nomad also comes with its own UI that can show you the result of a deployment.
+
+{% include image.html
+lightbox="true"
+file="/images/examples/nomad/nomad-ui-deployment.png"
+url="/images/examples/nomad/nomad-ui-deployment.png"
+alt="Nomad UI deployment"
+caption="Nomad UI deployment"
+max-width="80%"
+%}
+
+You can also use [Terraform]({{site.baseurl}}/docs/example-catalog/cd-examples/terraform/) in Codefresh pipelines.
+
+## Related articles
+[CD pipeline examples]({{site.baseurl}}/docs/example-catalog/examples/#cd-examples)
+[Codefresh YAML for pipeline definitions]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/)
+[Creating pipelines]({{site.baseurl}}/docs/pipelines/pipelines/)
+[How Codefresh pipelines work]({{site.baseurl}}/docs/pipelines/introduction-to-codefresh-pipelines/)
\ No newline at end of file
diff --git a/_docs/example-catalog/cd-examples/packer-gcloud.md b/_docs/example-catalog/cd-examples/packer-gcloud.md
new file mode 100644
index 000000000..efa9d9a82
--- /dev/null
+++ b/_docs/example-catalog/cd-examples/packer-gcloud.md
@@ -0,0 +1,134 @@
+---
+title: "Deploy to a Virtual Machine"
+description: "Deploy to Google Cloud in a Codefresh pipeline with Packer"
+group: example-catalog
+sub_group: cd-examples
+redirect_from:
+ - /docs/yaml-examples/examples/packer-gcloud/
+toc: true
+---
+
+Even though Codefresh is Kubernetes-native and designed for containers, it can still deploy traditional applications in the form of Virtual Machines to any Cloud provider.
+
+In this example, we will use [Packer](http://www.packer.io/){:target="\_blank"} to package an application into a VM disk image that will then be launched in Google Cloud.
+Because Packer itself is already offered [in a Docker container](https://hub.docker.com/r/hashicorp/packer/){:target="\_blank"}, it is very easy to run Packer in a Codefresh pipeline.
+
+Google also offers a [Docker image for GCloud](https://hub.docker.com/r/google/cloud-sdk/){:target="\_blank"} making the launching of the VM straightforward in a Codefresh pipeline.
+
+
+{% include image.html
+lightbox="true"
+file="/images/examples/packer-gcloud/packer-codefresh-pipeline.png"
+url="/images/examples/packer-gcloud/packer-codefresh-pipeline.png"
+alt="Running Packer inside Codefresh"
+caption="Running Packer inside Codefresh"
+max-width="80%"
+%}
+
+This Codefresh pipeline creates a VM image and then uses it to launch a Google Compute instance.
+
+
+## The example Packer/Gcloud project
+
+You can see the example project at [https://github.com/codefresh-contrib/vm-packer-sample-app](https://github.com/codefresh-contrib/vm-packer-sample-app){:target="\_blank"}. The repository contains a simple Go application as well as a packer template.
+
+You can play with it locally after installing the `packer` and `gcloud` executables.
+
+## Prerequisites
+
+You need to create a Codefresh account and a Google account first. Then you need to create a [Service account Key](https://cloud.google.com/iam/docs/creating-managing-service-account-keys){:target="\_blank"} which will allow `packer` and `gcloud` to communicate with Google cloud.
+
+
+Add your service account json as a pipeline variable called `SERVICE_ACCOUNT`. The content of this variable will be used
+in order to authenticate to Google cloud.
+
+{% include image.html
+lightbox="true"
+file="/images/examples/packer-gcloud/service-account-variable.png"
+url="/images/examples/packer-gcloud/service-account-variable.png"
+alt="Using a Service Account JSON in Codefresh"
+caption="Using a Service Account JSON in Codefresh"
+max-width="50%"
+%}
+
+## Create a CI/CD pipeline for Packer/GCloud
+
+Here is the whole pipeline:
+
+ `codefresh.yml`
+{% highlight yaml %}
+{% raw %}
+version: '1.0'
+stages:
+ - prepare
+ - build
+ - deploy
+steps:
+ main_clone:
+ title: 'Cloning main repository...'
+ type: git-clone
+ repo: 'codefresh-contrib/vm-packer-sample-app'
+ git: github
+ revision: 'master'
+ stage: prepare
+ SetupAuth:
+ title: 'Setup GCloud Auth'
+ image: 'alpine'
+ stage: prepare
+ commands:
+ - echo $SERVICE_ACCOUNT > account.json
+ BuildMyApp:
+ title: Compiling App code
+ stage: build
+ image: 'golang:1.12'
+ commands:
+ - go build -o sample src/sample/trivial-web-server.go
+ CreatePackerImage:
+ title: Baking VM image
+ stage: build
+ image: 'hashicorp/packer'
+ commands:
+ - packer validate my-google-cloud-example.json
+ - packer build -force my-google-cloud-example.json
+ DeployToVM:
+ title: Deploying to VM
+ stage: deploy
+ image: 'google/cloud-sdk'
+ commands:
+ - gcloud auth activate-service-account --key-file=account.json
+ - gcloud config set project firstkubernetes-176201
+ - gcloud compute instances create packer-demo-codefresh --image codefresh-simple-ubuntu-vm --zone europe-west1-b --metadata-from-file startup-script=startup.sh --tags http-server --preemptible --quiet
+
+{% endraw %}
+{% endhighlight %}
+
+This pipeline does the following:
+
+1. Clones the source code through a [Git clone step]({{site.baseurl}}/docs/pipelines/steps/git-clone/).
+1. Saves the content of the variable that holds the Google account as a file called `account.json`.
+1. Compiles the Go application through a [freestyle step]({{site.baseurl}}/docs/pipelines/steps/freestyle/).
+1. Runs `packer` to create a VM image based on Ubuntu that also contains the simple Go application.
+1. Runs `gcloud` to launch a VM with the image that was just created.
+
+
+Run the pipeline and see your deployment succeed. You can customize the image by editing the [Packer template](https://github.com/codefresh-contrib/vm-packer-sample-app/blob/master/my-google-cloud-example.json){:target="\_blank"}.
+
+Once the VM has finished launching you can access it with your web browser.
+
+{% include image.html
+lightbox="true"
+file="/images/examples/packer-gcloud/web-app-url.png"
+url="/images/examples/packer-gcloud/web-app-url.png"
+alt="Accessing the VM application"
+caption="Accessing the VM application"
+max-width="70%"
+%}
+
+
+You can follow the same procedure for any other cloud that has an API/CLI (such as AWS, Azure, Digital Ocean etc).
+
+## Related articles
+[CD pipeline examples]({{site.baseurl}}/docs/example-catalog/examples/#cd-examples)
+[Codefresh YAML for pipeline definitions]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/)
+[Creating pipelines]({{site.baseurl}}/docs/pipelines/pipelines/)
+[How Codefresh pipelines work]({{site.baseurl}}/docs/pipelines/introduction-to-codefresh-pipelines/)
\ No newline at end of file
diff --git a/_docs/example-catalog/cd-examples/pulumi.md b/_docs/example-catalog/cd-examples/pulumi.md
new file mode 100644
index 000000000..7c43b249b
--- /dev/null
+++ b/_docs/example-catalog/cd-examples/pulumi.md
@@ -0,0 +1,118 @@
+---
+title: "Deploy with Pulumi"
+description: "Use Pulumi in a Codefresh pipeline with Docker"
+group: example-catalog
+sub_group: cd-examples
+redirect_from:
+ - /docs/yaml-examples/examples/pulumi/
+toc: true
+---
+
+[Pulumi](https://pulumi.io/){:target="\_blank"} is a platform for *Infrastructure as Code*. It works like Terraform but allows you to use a proper programming language (TypeScript, Python, Go) to describe your infrastructure (instead of a configuration language).
+
+You can use Pulumi to deploy to Kubernetes or any other supported cloud platform. Because Pulumi itself is already offered [in a Docker container](https://hub.docker.com/r/pulumi/pulumi){:target="\_blank"}, it is very easy to run Pulumi in a Codefresh pipeline.
+
+
+{% include image.html
+lightbox="true"
+file="/images/examples/pulumi/pulumi-pipeline.png"
+url="/images/examples/pulumi/pulumi-pipeline.png"
+alt="Running Pulumi inside Codefresh"
+caption="Running Pulumi inside Codefresh"
+max-width="80%"
+%}
+
+## The example Pulumi project
+
+You can see the example project at [https://github.com/codefresh-contrib/pulumi-sample-app](https://github.com/codefresh-contrib/pulumi-sample-app){:target="\_blank"}. The repository contains a simple Pulumi stack based on Kubernetes and TypeScript.
+
+You can play with it locally after installing the `pulumi` executable.
+
+## Prerequisites
+
+You need to create a Codefresh account and a Pulumi account first. Then you need to create a [Pulumi token](https://app.pulumi.com/account/tokens){:target="\_blank"} which will allows Codefresh to communicate with Pulumi.
+
+[Add a Kubernetes cluster]({{site.baseurl}}/docs/integrations/kubernetes/#connect-a-kubernetes-cluster) in your Codefresh account from any cloud provider.
+
+Codefresh automatically creates a kubeconfig in any [freestyle step]({{site.baseurl}}/docs/pipelines/steps/freestyle/) with all your clusters. This is the same way that Pulumi communicated with Kubernetes, so the integration between Codefresh and Pulumi is ready out of the box.
+
+Create a [stack](https://pulumi.io/reference/stack.html){:target="\_blank"} in Pulumi or use the one provided in the example.
+
+Finally add you Pulumi token as a pipeline variable called `PULUMI_ACCESS_TOKEN`. All freestyle steps have automatic access to all pipeline variables, and Pulumi will search for a token by default with this name when logging in.
+
+
+## Create a CI/CD pipeline for Pulumi
+
+Here is the whole pipeline:
+
+ `codefresh.yml`
+{% highlight yaml %}
+{% raw %}
+version: '1.0'
+stages:
+ - prepare
+ - build
+ - deploy
+steps:
+ main_clone:
+ title: Cloning main repository...
+ type: git-clone
+ repo: '${{CF_REPO_OWNER}}/${{CF_REPO_NAME}}'
+ revision: '${{CF_REVISION}}'
+ stage: prepare
+ git: github-1
+ BuildProject:
+ title: Build project
+ stage: build
+ image: pulumi/pulumi
+ commands:
+ - yarn install
+ SelectMyCluster:
+ title: Select K8s cluster
+ stage: deploy
+ image: codefresh/kubectl:1.13.3
+ commands:
+ - kubectl config get-contexts
+ - kubectl config use-context "kostis-demo@FirstKubernetes"
+ RunPulumi:
+ title: Deploying
+ stage: deploy
+ image: pulumi/pulumi
+ commands:
+ - pulumi stack select dev --non-interactive
+ - pulumi stack --non-interactive
+ - pulumi up --non-interactive
+{% endraw %}
+{% endhighlight %}
+
+This pipeline does the following:
+
+1. Clones the source code through a [Git clone step]({{site.baseurl}}/docs/pipelines/steps/git-clone/).
+1. Runs `yarn install` to download dependencies. In this example we use TypeScript, but Go and Python would work as well (or any other language supported by Pulumi).
+1. Chooses the cluster that will be used for deployments, if you have more than one. Use your own cluster name as seen in the [Kubernetes dashboard]({{site.baseurl}}/docs/deployments/kubernetes/manage-kubernetes/) of Codefresh.
+1. Runs `pulumi up` with the same target cluster.
+
+The pipeline needs a [single environment variable]({{site.baseurl}}/docs/pipelines/variables/) that holds the content of your Pulumi Token.
+
+
+{% include image.html
+lightbox="true"
+file="/images/examples/pulumi/pulumi-access-token.png"
+url="/images/examples/pulumi/pulumi-access-token.png"
+alt="Passing the Pulumi Token in the pipeline parameters"
+caption="Passing the Pulumi Token in the pipeline parameters"
+max-width="60%"
+%}
+
+Run the pipeline and see your deployment succeed.
+
+## Handling Pull requests
+
+You can easily use the same pipeline or a different one for pull requests. In this case replace the `pulumi up` command with `pulumi preview`. Even better you can add an [approval step]({{site.baseurl}}/docs/pipelines/steps/approval/) to allows humans to inspect the pipeline first.
+
+
+## Related articles
+[CD pipeline examples]({{site.baseurl}}/docs/example-catalog/examples/#cd-examples)
+[Codefresh YAML for pipeline definitions]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/)
+[Creating pipelines]({{site.baseurl}}/docs/pipelines/pipelines/)
+[How Codefresh pipelines work]({{site.baseurl}}/docs/pipelines/introduction-to-codefresh-pipelines/)
diff --git a/_docs/example-catalog/cd-examples/secure-a-docker-container-using-http-basic-auth.md b/_docs/example-catalog/cd-examples/secure-a-docker-container-using-http-basic-auth.md
new file mode 100644
index 000000000..ce11ad7a2
--- /dev/null
+++ b/_docs/example-catalog/cd-examples/secure-a-docker-container-using-http-basic-auth.md
@@ -0,0 +1,93 @@
+---
+title: "Secure a Docker Container using HTTP Basic Auth"
+description: ""
+group: example-catalog
+sub_group: cd-examples
+redirect_from:
+ - /docs/yaml-examples/examples/secure-a-docker-container-using-http-basic-auth/
+ - /docs/securing-docker-container-with-http-basic-auth/
+ - /docs/on-demand-test-environment/examples-compositions/securing-docker-container-with-http-basic-auth/
+ - /docs/on-demand-test-environment/example-compositions/secure-a-docker-container-using-http-basic-auth/
+toc: true
+---
+Before making a product publicly available, you might want to restrict access to certain users. These are some options to accomplish this goal:
+
+ - Implement custom authentication within the system
+ - Configure the server to act as a proxy between the user and the application
+ - Limit access to specific IP addresses
+
+This article explains how to secure a container by exposing public ports, using an extra NGINX container to act as a proxy.
+
+## Expose Web App Public Port
+
+ `webapp`
+{% highlight yaml %}
+{% raw %}
+version: '3'
+services:
+ web:
+ image: codefreshio/webapp
+ ports:
+ - "3000"
+{% endraw %}
+{% endhighlight %}
+
+The architecture for this step is displayed in the diagram below. In this step example, Docker is forwarding an internal 3000 port to the host 80 port.
+
+{% include
+image.html
+lightbox="true"
+file="/images/examples/docker-https/codefresh_webapp_container.png"
+url="/images/examples/docker-https/codefresh_webapp_container.png"
+alt="codefresh_webapp_container.png"
+max-width="40%"
+%}
+
+## Add NGINX Proxy
+To secure the web-app we are going to specify these commands in the ```docker-compose.yml``` file.
+
+1. Remove the port that maps from the web-app (it won't be directly accessible)
+2. Add an extra NGINX container with custom configuration (proxy all traffic)
+3. Configure NGINX to communicate with the web-app
+
+ `docker-compose.yml`
+{% highlight yaml %}
+{% raw %}
+version: '3'
+services:
+ web:
+ image: ${{build-prj}}
+ auth:
+ image: ${{build-nginx}}
+ ports:
+ - 80
+ links:
+ - web
+ environment:
+ USER: ${{USERNAME}}
+ PASS: ${{PASSWORD}}
+{% endraw %}
+{% endhighlight %}
+
+The architecture for the ```docker-compose.yml``` file is displayed in the diagram below.
+
+{% include
+image.html
+lightbox="true"
+file="/images/examples/docker-https/codefresh_nginx_container.png"
+url="/images/examples/docker-https/codefresh_nginx_container.png"
+alt="codefresh_nginx_container.png"
+max-width="40%"
+%}
+
+{{site.data.callout.callout_info}}
+##### Example
+
+Just head over to the example [__repository__](https://github.com/codefreshdemo/cf-example-basic-auth-container){:target="_blank"} in GitHub and follow the instructions there.
+{{site.data.callout.end}}
+
+## Related articles
+[CD pipeline examples]({{site.baseurl}}/docs/example-catalog/examples/#cd-examples)
+[Codefresh YAML for pipeline definitions]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/)
+[Creating pipelines]({{site.baseurl}}/docs/pipelines/pipelines/)
+[How Codefresh pipelines work]({{site.baseurl}}/docs/pipelines/introduction-to-codefresh-pipelines/)
\ No newline at end of file
diff --git a/_docs/yaml-examples/examples/spring-boot-kafka-zookeeper.md b/_docs/example-catalog/cd-examples/spring-boot-kafka-zookeeper.md
similarity index 91%
rename from _docs/yaml-examples/examples/spring-boot-kafka-zookeeper.md
rename to _docs/example-catalog/cd-examples/spring-boot-kafka-zookeeper.md
index 675a1a5e6..0a0ecd4c4 100644
--- a/_docs/yaml-examples/examples/spring-boot-kafka-zookeeper.md
+++ b/_docs/example-catalog/cd-examples/spring-boot-kafka-zookeeper.md
@@ -1,9 +1,10 @@
---
title: "Spring Boot + Kafka + Zookeeper"
description: ""
-group: yaml-examples
-sub_group: examples
+group: example-catalog
+sub_group: cd-examples
redirect_from:
+ - /docs/yaml-examples/examples/spring-boot-kafka-zookeeper/
- /docs/spring-boot-kafka-zookeeper/
- /docs/on-demand-test-environment/example-compositions/spring-boot-kafka-zookeeper/
toc: true
@@ -65,7 +66,7 @@ You can configure the broker id in different ways:
1. Explicitly, using ```KAFKA_BROKER_ID```
2. Via a command, using ```BROKER_ID_COMMAND```, e.g. ```BROKER_ID_COMMAND: "hostname | awk -F'-' '{print $2}'"```
-If you don't specify a broker id in your docker-compose file, it will automatically be generated (see [https://issues.apache.org/jira/browse/KAFKA-1070](https://issues.apache.org/jira/browse/KAFKA-1070){:target="_blank"}. This allows scaling up and down. In this case it is recommended to use the ```--no-recreate``` option of docker-compose to ensure that containers are not re-created and thus keep their names and ids.
+If you don't specify a broker id in your docker-compose file, it will automatically be generated (see [https://issues.apache.org/jira/browse/KAFKA-1070](https://issues.apache.org/jira/browse/KAFKA-1070){:target="_blank"}). This allows scaling up and down. In this case it is recommended to use the ```--no-recreate``` option of docker-compose to ensure that containers are not re-created and thus keep their names and ids.
__Automatically create topics__
@@ -196,3 +197,8 @@ Tests run: 3, Failures: 0, Errors: 0, Skipped: 0
{% endraw %}
{% endhighlight %}
+## Related articles
+[CD pipeline examples]({{site.baseurl}}/docs/example-catalog/examples/#cd-examples)
+[Codefresh YAML for pipeline definitions]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/)
+[Creating pipelines]({{site.baseurl}}/docs/pipelines/pipelines/)
+[How Codefresh pipelines work]({{site.baseurl}}/docs/pipelines/introduction-to-codefresh-pipelines/)
\ No newline at end of file
diff --git a/_docs/example-catalog/cd-examples/terraform.md b/_docs/example-catalog/cd-examples/terraform.md
new file mode 100644
index 000000000..6bd7bb3e9
--- /dev/null
+++ b/_docs/example-catalog/cd-examples/terraform.md
@@ -0,0 +1,115 @@
+---
+title: "Deploy with Terraform"
+description: "Use Terraform in a Codefresh pipeline with Docker"
+group: example-catalog
+sub_group: cd-examples
+redirect_from:
+ - /docs/yaml-examples/examples/terraform/
+toc: true
+---
+
+[Terraform](https://www.terraform.io/){:target="\_blank"} is a platform for *Infrastructure as Code*. It allows you to describe your cloud infrastructure in a declarative manner.
+
+You can use Terraform to deploy to Kubernetes or any other supported cloud platform. Because Terraform itself is already offered [in a Docker container](https://hub.docker.com/r/hashicorp/terraform/){:target="\_blank"}, it is very easy to run Terraform in a Codefresh pipeline.
+
+
+{% include image.html
+lightbox="true"
+file="/images/examples/terraform/terraform-pipeline.png"
+url="/images/examples/terraform/terraform-pipeline.png"
+alt="Running Terraform inside Codefresh"
+caption="Running Terraform inside Codefresh"
+max-width="80%"
+%}
+
+## The example Terraform project
+
+You can see the example project at [https://github.com/codefresh-contrib/terraform-sample-app](https://github.com/codefresh-contrib/terraform-sample-app){:target="\_blank"}. The repository contains a simple Terraform definition that creates a VM on Google cloud.
+
+You can play with it locally after installing the `terraform` executable.
+
+## Prerequisites
+
+You need to [create a Codefresh account]({{site.baseurl}}/docs/administration/account-user-management/create-a-codefresh-account/) and a Google account first. Then you need to create a [Service account Key](https://cloud.google.com/iam/docs/creating-managing-service-account-keys){:target="\_blank"} which will allow terraform to communicate with Google cloud.
+
+
+Add your service account json as a pipeline variable called `ACCOUNT_JSON_CONTENT`. The content of this variable will be used
+in order to authenticate to Google cloud.
+
+## Create a CI/CD pipeline for Terraform
+
+Here is the whole pipeline:
+
+ `codefresh.yml`
+{% highlight yaml %}
+{% raw %}
+version: '1.0'
+stages:
+ - checkout
+ - prepare
+ - deploy
+steps:
+ main_clone:
+ title: Cloning main repository...
+ stage: checkout
+ type: git-clone
+ repo: 'codefresh-contrib/terraform-sample-app'
+ revision: master
+ git: github
+ SetupAuth:
+ image: alpine:3.9
+ title: Setting up Google cloud auth
+ stage: prepare
+ commands:
+ - echo $ACCOUNT_JSON_CONTENT > /codefresh/volume/account.json
+ - cf_export GOOGLE_CLOUD_KEYFILE_JSON=/codefresh/volume/account.json
+ DeployWithTerraform:
+ image: hashicorp/terraform:0.12.0
+ title: Deploying Terraform plan
+ stage: deploy
+ commands:
+ - terraform init
+ - terraform apply -auto-approve
+
+{% endraw %}
+{% endhighlight %}
+
+This pipeline does the following:
+
+1. Clones the source code through a [Git clone step]({{site.baseurl}}/docs/pipelines/steps/git-clone/).
+1. Creates a pipeline variable with the path of the Google service account by running [cf_export]({{site.baseurl}}/docs/pipelines/variables/#exporting-environment-variables-from-a-freestyle-step).
+1. Creates the VM on Google cloud by running `terraform init/apply`.
+
+>For simplicity, we auto-approve the Terraform plan in the example pipeline. In a production pipeline, you would instead use an [approval step]({{site.baseurl}}/docs/pipelines/steps/approval/) to inspect the plan before actually applying it.
+
+The pipeline needs a [single environment variable]({{site.baseurl}}/docs/pipelines/variables/) that holds the content of the service account.
+
+
+{% include image.html
+lightbox="true"
+file="/images/examples/terraform/google_cloud_json.png"
+url="/images/examples/terraform/google_cloud_json.png"
+alt="Passing the Google account in the pipeline parameters"
+caption="Passing the Google account in the pipeline parameters"
+max-width="60%"
+%}
+
+
+Run the pipeline and see your deployment succeed.
+
+
+Note that in a production pipeline you should also handle the [Terraform state](https://www.terraform.io/docs/state/){:target="\_blank"} in a proper manner. The example provided is using a file for [state storage](https://www.terraform.io/docs/backends/index.html){:target="\_blank"} which is not appropriate when using Terraform in a team environment. Instead you should use one of the [storage backends](https://www.terraform.io/docs/backends/types/index.html){:target="\_blank"} that support High Availability and Locking.
+
+
+
+
+## Handling Pull requests
+
+You can easily use the same pipeline or a different one for pull requests. In this case replace the `terraform apply` command with `terraform plan`. Even better, you can add an [approval step]({{site.baseurl}}/docs/pipelines/steps/approval/) to allow humans to inspect the pipeline first.
+
+
+## Related articles
+[CD pipeline examples]({{site.baseurl}}/docs/example-catalog/examples/#cd-examples)
+[Codefresh YAML for pipeline definitions]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/)
+[Creating pipelines]({{site.baseurl}}/docs/pipelines/pipelines/)
+[How Codefresh pipelines work]({{site.baseurl}}/docs/pipelines/introduction-to-codefresh-pipelines/)
diff --git a/_docs/example-catalog/cd-examples/transferring-php-ftp.md b/_docs/example-catalog/cd-examples/transferring-php-ftp.md
new file mode 100644
index 000000000..8eb928465
--- /dev/null
+++ b/_docs/example-catalog/cd-examples/transferring-php-ftp.md
@@ -0,0 +1,119 @@
+---
+title: "Deploy to VM via FTP"
+description: "Deploying a PHP application to a VM using FTP"
+group: example-catalog
+sub_group: cd-examples
+redirect_from:
+ - /docs/yaml-examples/examples/transferring-php-ftp/
+ - /docs/learn-by-example/java/spring-mvc-jdbc-template/
+toc: true
+---
+
+## Prerequisites
+
+- A [Codefresh account]- A [Codefresh account]({{site.baseurl}}/docs/administration/account-user-management/create-codefresh-account/)
+- A remote machine with an FTP server and SSH setup (ensure that your FTP directory, I.e., `/srv/ftp/pub` has the proper write permissions for the FTP user).
+
+>Note that as you may already know, FTP is extremely insecure as it relies on plain-text passwords and usernames, making data very vulnerable to sniffing. A more secure solution would be to use SFTP or SCP.
+
+## Example PHP project
+
+The example project can be found on [GitHub](https://github.com/codefresh-contrib/ftp-php-app){:target="\_blank"}. The application is a simple PHP application that displays an example timer.
+
+{% include image.html
+lightbox="true"
+file="/images/examples/php-file-transfer/test-environment.png"
+url="/images/examples/php-file-transfer/test-environment.png"
+alt="Example PHP Application"
+caption="Example PHP Application"
+max-width="90%"
+%}
+
+## Create the pipeline
+
+Our pipeline includes four stages:
+
+- A stage for cloning
+- A stage for packaging
+- A stage for transferring files
+
+{% include image.html
+lightbox="true"
+file="/images/examples/php-file-transfer/pipeline.png"
+url="/images/examples/php-file-transfer/pipeline.png"
+alt="Codefresh UI Pipeline View"
+caption="Codefresh UI Pipeline View"
+max-width="90%"
+%}
+
+Here is the entire pipeline:
+
+`codefresh.yml`
+{% highlight yaml %}
+{% raw %}
+# More examples of Codefresh YAML can be found at
+# https://codefresh.io/docs/docs/example-catalog/
+
+version: "1.0"
+# Stages can help you organize your steps in stages
+stages:
+ - "clone"
+ - "install"
+ - "transfer"
+steps:
+ clone:
+ title: "Cloning main repository..."
+ type: "git-clone"
+ arguments:
+ repo: "codefresh-contrib/ftp-php-app"
+ git: "github"
+ stage: "clone"
+ install_dependencies:
+ title: "Collecting Php dependencies..."
+ type: "freestyle"
+ working_directory: "./ftp-php-app"
+ arguments:
+ image: "composer:1.9.3"
+ commands:
+ - "composer install --ignore-platform-reqs --no-interaction --no-plugins --no-scripts --prefer-dist"
+ stage: "install"
+ steps:
+ ftp_transfer:
+ title: "Transferring application to VM via ftp..."
+ type: "freestyle"
+ working_directory: "./ftp-php-app"
+ arguments:
+ image: "dockito/lftp-client:latest"
+ environment:
+ - USER=
+ - PASSWORD=
+ - HOST=
+ - PUB_FTP_DIR=
+ commands:
+ - lftp -e "set ftp:use-site-utime2 false; mirror -x ^\.git/$ -X flat-logo.png -p -R ftp-php-ap $PUB_FTP_DIR/ftp-php-app; exit" -u $USER,$PASSWORD $HOST
+ stage: "transfer"
+{% endraw %}
+{% endhighlight %}
+
+This pipeline does the following:
+
+1. Clones the main repository through a [Git-clone step]({{site.baseurl}}/docs/pipelines/steps/git-clone/).
+2. Installs the necessary PHP dependencies for our application through a [freestyle step]({{site.baseurl}}/docs/pipelines/steps/freestyle/).
+3. Transfers our application via FTP through another freestyle step. Note that you will need to change the environment variables to your respective values, either in the YAML itself (above), or through the pipeline settings:
+
+{% include image.html
+lightbox="true"
+file="/images/examples/php-file-transfer/variables.png"
+url="/images/examples/php-file-transfer/variables.png"
+alt="Codefresh Environment Variables"
+caption="Codefresh Environment Variables"
+max-width="90%"
+%}
+
+## Related articles
+[CD pipeline examples]({{site.baseurl}}/docs/example-catalog/examples/#cd-examples)
+[Codefresh YAML for pipeline definitions]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/)
+[Creating pipelines]({{site.baseurl}}/docs/pipelines/pipelines/)
+[How Codefresh pipelines work]({{site.baseurl}}/docs/pipelines/introduction-to-codefresh-pipelines/)
+
+
diff --git a/_docs/example-catalog/cd-examples/trigger-a-k8s-deployment-from-docker-registry.md b/_docs/example-catalog/cd-examples/trigger-a-k8s-deployment-from-docker-registry.md
new file mode 100644
index 000000000..00a982c87
--- /dev/null
+++ b/_docs/example-catalog/cd-examples/trigger-a-k8s-deployment-from-docker-registry.md
@@ -0,0 +1,137 @@
+---
+title: "Trigger a Kubernetes Deployment from a Docker Hub Push Event"
+description: "Learn how to trigger a Kubernetes deployment when an image is updated"
+group: example-catalog
+sub_group: cd-examples
+redirect_from:
+ - /docs/yaml-examples/examples/trigger-a-k8s-deployment-from-docker-registry/
+toc: true
+---
+
+In this example, we will cover how to trigger a Kubernetes deployment from a Docker Hub Push event using a Dockerhub [registry trigger]({{site.baseurl}}/docs/pipelines/triggers/dockerhub-triggers/#create-a-new-dockerhub-trigger).
+
+Our example has two pipelines: one for packaging code (CI), and the second for deploying code (CD).
+
+## Prerequisites
+
+- A [Codefresh account]({{site.baseurl}}/docs/administration/account-user-management/create-codefresh-account/)
+- A Docker Hub registry [connected to your Codefresh account]({{site.baseurl}}/docs/integrations/docker-registries/#docker-hub)
+- A Kubernetes cluster [connected to your Codefresh account]({{site.baseurl}}/docs/integrations/kubernetes/#connect-a-kubernetes-cluster)
+- A service for your application [deployed to your cluster]({{site.baseurl}}/docs/deployments/kubernetes/manage-kubernetes/#viewing-your-kubernetes-services)
+
+## Example Project
+
+You can see the example project on [GitHub](https://github.com/codefresh-contrib/registry-trigger-sample-app/tree/master){:target="\_blank"}. The repository contains a simple Hello World NodeJs app as well as 2 pipelines.
+
+## Create the CI Pipeline
+
+As mentioned before, our first pipeline will handle the CI process.
+The pipeline has three stages:
+
+- A stage for cloning
+- A stage for building the image
+- A stage for pushing the image to DockerHub
+
+{% include image.html
+lightbox="true"
+file="/images/examples/deployments/k8s-deployment-ci-pipeline.png"
+url="/images/examples/deployments/k8s-deployment-ci-pipeline.png"
+alt="Codefresh UI CI Pipeline View"
+caption="Codefresh UI CI Pipeline View"
+max-width="90%"
+%}
+
+ `codefresh-CI-pipeline.yml`
+{% highlight yaml %}
+{% raw %}
+version: '1.0'
+
+stages:
+- checkout
+- build
+- push
+
+steps:
+ clone:
+ title: Cloning main repository...
+ type: git-clone
+ stage: checkout
+ arguments:
+ repo: 'codefresh-contrib/registry-trigger-sample-app'
+ revision: 'master'
+ git: github
+ build_my_app:
+ title: Building image...
+ type: build
+ stage: build
+ arguments:
+ image_name: registry-trigger-sample-app
+ working_directory: ${{clone}}
+ tag: 'master'
+ dockerfile: Dockerfile
+ push_to_my_registry:
+ stage: 'push'
+ type: push
+ title: Pushing to Dockerhub...
+ arguments:
+ candidate: ${{build_my_app}}
+ tag: 'latest'
+ registry: dockerhub
+ image_name: annabaker/registry-trigger-sample-app
+{% endraw %}
+{% endhighlight %}
+
+This pipeline does the following:
+
+1. Clones the source code through a [Git clone step]({{site.baseurl}}/docs/pipelines/steps/git-clone/).
+2. Builds a docker image tagged with the Application version through a [build step]({{site.baseurl}}/docs/pipelines/steps/build/).
+3. Pushes the Docker image through a [push step]({{site.baseurl}}/docs/pipelines/steps/push/) to the Docker Hub registry you have integrated with Codefresh.
+
+## Create the CD Pipeline
+
+This pipeline contains one stage/step, for deploying.
+
+{% include image.html
+lightbox="true"
+file="/images/examples/deployments/k8s-deployment-CD-pipeline.png"
+url="/images/examples/deployments/k8s-deployment-CD-pipeline.png"
+alt="Codefresh UI CD Pipeline View"
+caption="Codefresh UI CD Pipeline View"
+max-width="90%"
+%}
+
+Note that for the trigger mechanism to take place, you will need to [add a Docker Hub registry trigger]({{site.baseurl}}/docs/pipelines/triggers/dockerhub-triggers/#create-a-new-dockerhub-trigger) to the pipeline.
+
+ `codefresh-CD-pipeline.yml`
+{% highlight yaml %}
+{% raw %}
+version: "1.0"
+
+stages:
+ - "deploy"
+
+steps:
+ deploy_to_k8s:
+ title: Running Deploy Script...
+ type: deploy
+ kind: kubernetes
+ arguments:
+ cluster: anna-demo@FirstKubernetes
+ namespace: default
+ service: registry-trigger-sample-app
+ candidate:
+ image: annabaker/registry-trigger-sample-app:latest
+ registry: 'dockerhub'
+{% endraw %}
+{% endhighlight %}
+
+This pipeline does the following:
+
+1. Deploys the image to Kubernetes through a [deploy step]({{site.baseurl}}/docs/pipelines/steps/deploy/). The deploy step uses a [Registry trigger]({{site.baseurl}}/docs/pipelines/triggers/dockerhub-triggers/#create-a-new-dockerhub-trigger) to kick off the pipeline when the updated image is pushed to the registry.
+
+## Related articles
+[CD pipeline examples]({{site.baseurl}}/docs/example-catalog/examples/#cd-examples)
+[Codefresh YAML for pipeline definitions]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/)
+[Creating pipelines]({{site.baseurl}}/docs/pipelines/pipelines/)
+[How Codefresh pipelines work]({{site.baseurl}}/docs/pipelines/introduction-to-codefresh-pipelines/)
+[Triggers in pipelines]({{site.baseurl}}/docs/pipelines/triggers/)
diff --git a/_docs/example-catalog/cd-examples/use-kubectl-as-part-of-freestyle-step.md b/_docs/example-catalog/cd-examples/use-kubectl-as-part-of-freestyle-step.md
new file mode 100644
index 000000000..16dc08fef
--- /dev/null
+++ b/_docs/example-catalog/cd-examples/use-kubectl-as-part-of-freestyle-step.md
@@ -0,0 +1,43 @@
+---
+title: "Use kubectl as part of freestyle step"
+description: "How to run manually kubectl in a Codefresh pipeline"
+group: example-catalog
+sub_group: cd-examples
+redirect_from:
+ - /docs/yaml-examples/examples/use-kubectl-as-part-of-freestyle-step/
+ - /docs/use-kubectl-as-part-of-freestyle-step/
+toc: true
+---
+
+
+Running Kubernetes commands in Codefresh as part of the workflow is very easy.
+
+
+Codefresh is adding all your clusters into the workflow ready to be used as part of your CI/CD pipeline.
+The context remains the same as it appears in the [Codefresh Kubernetes dashboard]({{site.baseurl}}/docs/deployments/kubernetes/manage-kubernetes/).
+
+>If your cluster name includes spaces then make sure that you use quotes in the `kubectl` command.
+
+* Use image: `codefresh/kubectl`
+* Add your commands:
+ * `kubectl config get-contexts`. Will print the cluster that we added to the workflow
+ * `kubectl config use-context "my-cluster-name"`. The name is the same as in `Account settings` → `Integrations` → `Kubernetes`
+ * `kubectl get po -owide`
+ * `kubectl get nodes`
+
+
+## Follow the example
+
+* Add this [Git repo](https://github.com/Codefresh-Examples/kubectl-in-freestyle-step){:target="_blank"} to your account
+* Change the pipeline configuration to use `codefresh.yml`.
+* Build.
+
+## Running parallel steps with kubectl
+
+More complex examples can be found in the [custom kubectl commands]({{site.baseurl}}/docs/deployments/kubernetes/custom-kubectl-commands/) documentation page.
+
+## Related articles
+[CD pipeline examples]({{site.baseurl}}/docs/example-catalog/examples/#cd-examples)
+[Codefresh YAML for pipeline definitions]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/)
+[Creating pipelines]({{site.baseurl}}/docs/pipelines/pipelines/)
+[How Codefresh pipelines work]({{site.baseurl}}/docs/pipelines/introduction-to-codefresh-pipelines/)
\ No newline at end of file
diff --git a/_docs/example-catalog/cd-examples/web-terminal.md b/_docs/example-catalog/cd-examples/web-terminal.md
new file mode 100644
index 000000000..4d1df20f8
--- /dev/null
+++ b/_docs/example-catalog/cd-examples/web-terminal.md
@@ -0,0 +1,49 @@
+---
+title: "Web terminal"
+description: ""
+group: example-catalog
+sub_group: cd-examples
+redirect_from:
+ - /docs/yaml-examples/examples/web-terminal/
+ - /docs/web-terminal/
+ - /docs/on-demand-test-environment/example-compositions/web-terminal/
+toc: true
+---
+This example shows you how to access containers running in a Codefresh standup environment.
+
+## Looking around
+In the root of this repository you'll find a file named `docker-compose.yml`.
+Here are the contents of this file:
+
+ `Composition.yml`
+{% highlight yaml %}
+version: '3'
+services:
+ my-service:
+ image: 'containers101/whomi:master'
+ volumes:
+ - my-service:/app
+ ports:
+ - '1337'
+ terminal:
+ image: 'containers101/cfterminal:master'
+ ports:
+ - '8000'
+ volumes_from:
+ - my-service
+volumes:
+ my-service:
+ driver: local
+{% endhighlight %}
+
+{{site.data.callout.callout_info}}
+##### Example
+
+Just head over to the example [__repository__](https://github.com/codefreshdemo/cf-example-web-termial){:target="_blank"} in GitHub and follow the instructions there.
+{{site.data.callout.end}}
+
+## Related articles
+[CD pipeline examples]({{site.baseurl}}/docs/example-catalog/examples/#cd-examples)
+[Codefresh YAML for pipeline definitions]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/)
+[Creating pipelines]({{site.baseurl}}/docs/pipelines/pipelines/)
+[How Codefresh pipelines work]({{site.baseurl}}/docs/pipelines/introduction-to-codefresh-pipelines/)
\ No newline at end of file
diff --git a/_docs/example-catalog/ci-examples.md b/_docs/example-catalog/ci-examples.md
new file mode 100644
index 000000000..360e3d8d9
--- /dev/null
+++ b/_docs/example-catalog/ci-examples.md
@@ -0,0 +1,100 @@
+---
+title: "CI Example catalog"
+description: "A collection of CI examples for Codefresh pipelines"
+group: example-catalog
+redirect_from:
+ - /docs/yaml-examples/examples/
+ - /docs/learn-by-example/scala/
+ - /docs/learn-by-example/python/
+ - /docs/learn-by-example/nodejs/
+ - /docs/learn-by-example/mobile/
+ - /docs/learn-by-example/java/
+ - /docs/learn-by-example/golang/
+ - /docs/learn-by-example/cc/
+ - /docs/examples-v01/
+ - examples.html
+ - /docs/catalog-examples/
+ - /docs/examples/
+ - /docs/pipelines-examples/
+ - /docs/pipelines/pipelines-examples/
+ - /docs/example-catalog/examples/
+toc: true
+---
+Codefresh enables you to define the steps of your pipeline in a [YAML file]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/). By default, the file is named `codefresh.yml`, and is located in the root directory of the repository.
+
+### Programming-language specific examples
+
+Codefresh is agnostic as far as programming languages are concerned. All major programming languages are supported:
+
+- [Go Web App]({{site.baseurl}}/docs/example-catalog/ci-examples/golang-hello-world/) or [Go CLI]({{site.baseurl}}/docs/example-catalog/ci-examples/goreleaser)
+- [Spring Java app with Maven]({{site.baseurl}}/docs/example-catalog/ci-examples/spring-boot-2/) or [Gradle]({{site.baseurl}}/docs/example-catalog/ci-examples/gradle/). Also how to [upload JAR to Nexus/Artifactory]({{site.baseurl}}/docs/example-catalog/ci-examples/publish-jar/)
+- Node [Express.js App]({{site.baseurl}}/docs/example-catalog/ci-examples/lets-chat/) or [React.js App]({{site.baseurl}}/docs/example-catalog/ci-examples/react/)
+- [Php App]({{site.baseurl}}/docs/example-catalog/ci-examples/php)
+- [Python Django App]({{site.baseurl}}/docs/example-catalog/ci-examples/django/)
+- [Ruby On Rails App]({{site.baseurl}}/docs/example-catalog/ci-examples/ruby)
+- [C]({{site.baseurl}}/docs/example-catalog/ci-examples/c-make/) or [C++]({{site.baseurl}}/docs/example-catalog/ci-examples/cpp-cmake)
+- [Rust]({{site.baseurl}}/docs/example-catalog/ci-examples/rust/)
+- [C# .NET core]({{site.baseurl}}/docs/example-catalog/ci-examples/dotnet/)
+- [Scala App]({{site.baseurl}}/docs/example-catalog/ci-examples/scala-hello-world/)
+- [Android (Mobile)]({{site.baseurl}}/docs/example-catalog/ci-examples/android/)
+- [NodeJS + Angular2 + MongoDB]({{site.baseurl}}/docs/example-catalog/ci-examples/nodejs-angular2-mongodb/)
+
+### Source code checkout examples
+
+You can check out code from one or more repositories in any pipeline phase. Codefresh includes [built-in GIT integration]({{site.baseurl}}/docs/integrations/git-providers/) with all the popular GIT providers and can be used with [git-clone]({{site.baseurl}}/docs/pipelines/steps/git-clone/) steps.
+
+- [Cloning Git repositories using the built-in integration]({{site.baseurl}}/docs/example-catalog/ci-examples/git-checkout/)
+- [Cloning Git repositories using manual Git commands]({{site.baseurl}}/docs/example-catalog/ci-examples/git-checkout-custom/)
+- [Checking out from Subversion, Perforce, Mercurial, etc]({{site.baseurl}}/docs/example-catalog/ci-examples/non-git-checkout/)
+
+### Build/push examples
+
+Codefresh has native support for [building]({{site.baseurl}}/docs/pipelines/steps/build/) and [pushing]({{site.baseurl}}/docs/pipelines/steps/push/) Docker containers.
+You can also compile traditional applications that are not Dockerized yet.
+
+- [Build an Image with the Dockerfile in root directory]({{site.baseurl}}/docs/example-catalog/ci-examples/build-an-image-with-the-dockerfile-in-root-directory/)
+- [Build an Image by specifying the Dockerfile location]({{site.baseurl}}/docs/example-catalog/ci-examples/build-an-image-specify-dockerfile-location)
+- [Build an Image from a different Git repository]({{site.baseurl}}/docs/example-catalog/ci-examples/build-an-image-from-a-different-git-repository)
+- [Build and Push an Image]({{site.baseurl}}/docs/example-catalog/ci-examples/build-and-push-an-image)
+- [Build an Image with build arguments]({{site.baseurl}}/docs/example-catalog/ci-examples/build-an-image-with-build-arguments)
+- [Share data between steps]({{site.baseurl}}/docs/example-catalog/ci-examples/shared-volumes-between-builds)
+- [Upload or download from a Google Storage Bucket]({{site.baseurl}}/docs/example-catalog/ci-examples/uploading-or-downloading-from-gs/)
+- [Get Short SHA ID and use it in a CI process]({{site.baseurl}}/docs/example-catalog/ci-examples/get-short-sha-id-and-use-it-in-a-ci-process)
+- [Call a CD pipeline from a CI pipeline]({{site.baseurl}}/docs/example-catalog/ci-examples/call-child-pipelines)
+
+### Unit and integration test examples
+
+Codefresh has support for both [unit]({{site.baseurl}}/docs/testing/unit-tests/) and [integration]({{site.baseurl}}/docs/testing/integration-tests/) tests, as well as [test reporting]({{site.baseurl}}/docs/testing/test-reports/).
+
+- [Run unit tests]({{site.baseurl}}/docs/example-catalog/ci-examples/run-unit-tests)
+- [Run integration tests]({{site.baseurl}}/docs/example-catalog/ci-examples/run-integration-tests/)
+- [Run integration tests with MongoDB]({{site.baseurl}}/docs/example-catalog/ci-examples/integration-tests-with-mongo/)
+- [Run integration tests with MySQL]({{site.baseurl}}/docs/example-catalog/ci-examples/integration-tests-with-mysql/)
+- [Run integration tests with PostgreSQL]({{site.baseurl}}/docs/example-catalog/ci-examples/integration-tests-with-postgres/)
+- [Run integration tests with Redis]({{site.baseurl}}/docs/example-catalog/ci-examples/integration-tests-with-redis/)
+- [Populate a database with existing data]({{site.baseurl}}/docs/example-catalog/ci-examples/populate-a-database-with-existing-data)
+- [Shared volumes of service from composition step for other yml steps]({{site.baseurl}}/docs/example-catalog/ci-examples/shared-volumes-of-service-from-composition-step-for-other-yml-steps)
+- [Launch Composition]({{site.baseurl}}/docs/example-catalog/ci-examples/launch-composition)
+- [Launch Composition and define Service Environment variables using a file]({{site.baseurl}}/docs/example-catalog/ci-examples/launching-a-composition-and-defining-a-service-environment-variables-using-a-file)
+- [Run multiple kinds of unit tests using fan-in-fan-out parallel pipeline]({{site.baseurl}}/docs/example-catalog/ci-examples/fan-in-fan-out)
+
+### Code coverage examples
+
+- [Run coverage reports with Codecov]({{site.baseurl}}/docs/example-catalog/ci-examples/codecov-testing)
+- [Run coverage reports with Coveralls]({{site.baseurl}}/docs/example-catalog/ci-examples/coveralls-testing)
+- [Run coverage reports with Codacy]({{site.baseurl}}/docs/example-catalog/ci-examples/codacy-testing)
+
+### Secrets examples
+
+Codefresh can automatically export secret key-value pairs using the Vault plugin from the [Step Marketplace](https://codefresh.io/steps/step/vault){:target="\_blank"}.
+
+- [Vault secrets in the Pipeline]({{site.baseurl}}/docs/example-catalog/ci-examples/vault-secrets-in-the-pipeline/)
+- [Decryption with Mozilla SOPS]({{site.baseurl}}/docs/example-catalog/ci-examples/decryption-with-mozilla-sops/)
+- [GitOps with Bitnami sealed secrets]({{site.baseurl}}/docs/example-catalog/cd-examples/gitops-secrets)
+
+### Notification examples
+
+- [Send notification to Slack]({{site.baseurl}}/docs/example-catalog/ci-examples/sending-the-notification-to-slack)
+- [Send notification to Jira]({{site.baseurl}}/docs/example-catalog/ci-examples/sending-the-notification-to-jira)
+
+
diff --git a/_docs/example-catalog/ci-examples/android.md b/_docs/example-catalog/ci-examples/android.md
new file mode 100644
index 000000000..667b8e6ad
--- /dev/null
+++ b/_docs/example-catalog/ci-examples/android.md
@@ -0,0 +1,82 @@
+---
+title: "Compile and package an Android application"
+description: "Using Codefresh pipelines"
+group: example-catalog
+sub_group: ci-examples
+redirect_from:
+ - /docs/learn-by-example/mobile/android/
+toc: true
+---
+
+Android applications use Java/Gradle for their build system. Because Codefresh already supports [Gradle]({{site.baseurl}}/docs/example-catalog/ci-examples/gradle/), it is also very easy to build Android projects.
+
+Any Gradle command can run inside a Docker image that contains the Android SDK. As an example, we will use a [Nextcloud](https://hub.docker.com/r/nextcloudci/android){:target="\_blank"} image from Dockerhub.
+
+
+## The example project
+
+You can see the example project at [https://github.com/codefresh-contrib/android-sample-app](https://github.com/codefresh-contrib/android-sample-app){:target="\_blank"}. The repository contains a Hello World Android project with the following tasks:
+
+* `./gradlew test` runs unit tests
+* `./gradlew build` builds the application
+
+
+## Create a CI pipeline that compiles/releases Android
+
+In most cases you would create a similar pipeline to a Gradle project.
+
+{% include image.html
+lightbox="true"
+file="/images/examples/mobile/android-ci-pipeline.png"
+url="/images/examples/mobile/android-ci-pipeline.png"
+alt="Building and Testing an Android app"
+caption="Building and Testing an Android app"
+max-width="80%"
+%}
+
+Here is the [full pipeline](https://github.com/codefresh-contrib/android-sample-app/blob/master/codefresh.yml){:target="\_blank"} that uses a Docker image with the Android SDK in order to run Gradle.
+
+ `codefresh.yml`
+{% highlight yaml %}
+{% raw %}
+version: '1.0'
+stages:
+ - prepare
+ - test
+ - build
+steps:
+ main_clone:
+ title: Cloning main repository...
+ stage: prepare
+ type: git-clone
+ repo: 'codefresh-contrib/android-sample-app'
+ revision: master
+ git: github
+ TestIt:
+ title: Running Tests
+ stage: test
+ image: nextcloudci/android:android-48
+ commands:
+ - chmod +x ./gradlew
+ - ./gradlew test --no-daemon --gradle-user-home=/codefresh/volume/.gradle
+ BuildIt:
+ title: Packaging Android App
+ stage: build
+ image: nextcloudci/android:android-48
+ commands:
+ - ./gradlew build --no-daemon --gradle-user-home=/codefresh/volume/.gradle
+{% endraw %}
+{% endhighlight %}
+
+This pipeline clones the source code, runs unit tests and finally builds the Android application.
+
+Codefresh is smart enough that [caches automatically]({{site.baseurl}}/docs/pipelines/introduction-to-codefresh-pipelines/#how-caching-works-in-codefresh) for us the workspace of a build (`/codefresh/volume`). This works great for build tools that keep their cache in the project folder, but not for Maven/Gradle which keep their cache externally. By changing the location of the Gradle cache we make sure that Codefresh will cache automatically the Gradle libraries resulting in much faster builds.
+
+
+
+## Related articles
+[Codefresh YAML for pipeline definitions]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/)
+[Steps in pipelines]({{site.baseurl}}/docs/pipelines/steps/)
+[Creating pipelines]({{site.baseurl}}/docs/pipelines/pipelines/)
+[How Codefresh pipelines work]({{site.baseurl}}/docs/pipelines/introduction-to-codefresh-pipelines/)
+
diff --git a/_docs/example-catalog/ci-examples/build-an-image-from-a-different-git-repository.md b/_docs/example-catalog/ci-examples/build-an-image-from-a-different-git-repository.md
new file mode 100644
index 000000000..b6de4578e
--- /dev/null
+++ b/_docs/example-catalog/ci-examples/build-an-image-from-a-different-git-repository.md
@@ -0,0 +1,96 @@
+---
+title: "Build an Image from a different Git repository"
+description: "Build microservices from other repositories"
+group: example-catalog
+sub_group: ci-examples
+redirect_from:
+ - /docs/yaml-examples/examples/build-an-image-from-a-different-git-repository/
+ - /docs/build-an-image-from-a-different-git-repository/
+toc: true
+---
+
+In most cases, your Codefresh pipeline checks out a single Git repository. Codefresh has great support also for [monorepos]({{site.baseurl}}/docs/pipelines/triggers/git-triggers/#using-the-modified-files-field-to-constrain-triggers-to-specific-folderfiles) if you have placed all your applications in a single repository.
+
+A Codefresh pipeline is not really tied to a specific Git repository, which means that by [checking out multiple Git repositories]({{site.baseurl}}/docs/example-catalog/ci-examples/git-checkout/#cloning-multiple-repositories) you can build Docker images from other unrelated repositories in a single pipeline if you wish to do so.
+
+## Building Docker images from other Git repositories
+
+
+Here is a Codefresh pipeline that checks out two microservices from two different Git repositories.
+
+{% include image.html
+lightbox="true"
+file="/images/examples/docker-build/build-from-other-git-repo.png"
+url="/images/examples/docker-build/build-from-other-git-repo.png"
+alt="Checkout and build docker images"
+caption="Checkout and build docker images"
+max-width="100%"
+%}
+
+And here is the [pipeline definition]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/).
+
+ `codefresh.yml`
+{% highlight yaml %}
+{% raw %}
+version: '1.0'
+stages:
+ - 'clone phase'
+ - 'build phase'
+steps:
+ checkoutApp1:
+ title: 'Cloning first repository...'
+ type: git-clone
+ repo: kostis-codefresh/example_nodejs_postgres
+ revision: experiment1
+ git: github
+ stage: 'clone phase'
+ checkoutApp2:
+ title: 'Cloning second repository...'
+ type: git-clone
+ repo: kostis-codefresh/trivial-go-web
+ revision: master
+ git: github
+ stage: 'clone phase'
+ myFirstDockerImage:
+ title: 'Building Microservice A'
+ type: build
+ dockerfile: Dockerfile
+ image_name: my-nodejs-image
+ tag: from-develop-branch
+ working_directory: './example_nodejs_postgres'
+ stage: 'build phase'
+ mySecondDockerImage:
+ title: 'Building Microservice B'
+ type: build
+ dockerfile: Dockerfile
+ working_directory: './trivial-go-web'
+ image_name: my-app-image
+ tag: from-master-branch
+ stage: 'build phase'
+{% endraw %}
+{% endhighlight %}
+
+The pipeline first checks out two different Git repositories, which themselves contain Dockerfiles. Then it creates a Docker image for each one using the respective Dockerfile.
+
+You can see both images in the [Docker image dashboard]({{site.baseurl}}/docs/ci-cd-guides/working-with-docker-registries/#viewing-docker-images) .
+
+{% include image.html
+lightbox="true"
+file="/images/examples/docker-build/two-docker-images.png"
+url="/images/examples/docker-build/two-docker-images.png"
+alt="Docker images from other Git repos"
+caption="Docker images from other Git repos"
+max-width="100%"
+%}
+
+
+Notice that there are no explicit push steps in the pipeline, as all successful Codefresh pipelines automatically push to the private Docker registry.
+
+
+## Related articles
+[CI/CD pipeline examples]({{site.baseurl}}/docs/example-catalog/examples/#ci-examples)
+[Git clone step]({{site.baseurl}}/docs/pipelines/steps/git-clone/)
+[Build an Image with the Dockerfile in root directory]({{site.baseurl}}/docs/example-catalog/ci-examples/build-an-image-with-the-dockerfile-in-root-directory/)
+[Build step in pipelines in pipelines]({{site.baseurl}}/docs/pipelines/steps/build/)
+[Build and push an image]({{site.baseurl}}/docs/example-catalog/ci-examples/build-and-push-an-image/)
+[Parallel pipelines]({{site.baseurl}}/docs/pipelines/advanced-workflows/)
diff --git a/_docs/example-catalog/ci-examples/build-an-image-specify-dockerfile-location.md b/_docs/example-catalog/ci-examples/build-an-image-specify-dockerfile-location.md
new file mode 100644
index 000000000..6fb157dc5
--- /dev/null
+++ b/_docs/example-catalog/ci-examples/build-an-image-specify-dockerfile-location.md
@@ -0,0 +1,75 @@
+---
+title: "Build an Image by specifying a Dockerfile location"
+description: "How to choose a Dockerfile to build with Codefresh pipelines"
+group: example-catalog
+sub_group: ci-examples
+redirect_from:
+ - /docs/yaml-examples/examples/build-an-image-specify-dockerfile-location/
+ - /docs/build-an-image-specify-dockerfile-location/
+toc: true
+---
+
+You may have a project where the Dockerfile is **not** in the root folder of the project. Maybe the repository has multiple projects inside, each with its own Dockerfile, or you simply want to use a different folder for the Docker context.
+
+>The source code of the repository is at [https://github.com/codefreshdemo/cf-example-dockerfile-other-location](https://github.com/codefreshdemo/cf-example-dockerfile-other-location){:target="\_blank"}. Feel free to fork it if you want to follow along.
+
+If you don't have a Codefresh account already, you can easily create a free one from the [sign-up page]({{site.baseurl}}/docs/administration/account-user-management/create-codefresh-account/).
+
+
+## Building a Dockerfile from a different folder
+
+By default, if you run a single command like the one below, Docker uses the Dockerfile of the current folder:
+
+```
+docker build . -t my-web-app
+```
+
+If your Dockerfile is in a different folder, specify it explicitly with:
+
+```
+docker build . -t my-web-app -f subfolder/Dockerfile
+```
+
+Codefresh supports a similar syntax as well. The `dockerfile` property of the [build step]({{site.baseurl}}/docs/pipelines/steps/build/) can accept a full path.
+
+Here is the full pipeline:
+
+ `codefresh.yml`
+{% highlight yaml %}
+version: '1.0'
+steps:
+ main_clone:
+ title: Cloning main repository...
+ type: git-clone
+ repo: 'codefreshdemo/cf-example-dockerfile-other-location'
+ revision: 'master'
+ git: github
+ build_my_app:
+ title: Building Node.Js Docker Image
+ type: build
+ image_name: my-app
+ working_directory: '.'
+ tag: 'master'
+ dockerfile: docker/Dockerfile
+{% endhighlight %}
+
+This pipeline checks out the source code of the repository and then builds a Dockerfile found at the subfolder `docker` while still keeping as Docker context the root directory.
+
+{% include image.html
+lightbox="true"
+file="/images/examples/docker-build/build-spefify-dockerfile.png"
+url="/images/examples/docker-build/build-spefify-dockerfile.png"
+alt="Building a Docker image with specific Dockerfile"
+caption="Building a Docker image with specific Dockerfile"
+max-width="100%"
+%}
+
+You could also change the Docker build context by editing the `working_directory` property. By default, it looks at the root folder of the project, but any subfolder path is also valid.
+
+## Related articles
+[CI/CD pipeline examples]({{site.baseurl}}/docs/example-catalog/examples/#ci-examples)
+[Build an Image with the Dockerfile in root directory]({{site.baseurl}}/docs/example-catalog/ci-examples/build-an-image-with-the-dockerfile-in-root-directory/)
+[Build an Image from a different Git repository]({{site.baseurl}}/docs/example-catalog/ci-examples/build-an-image-from-a-different-git-repository)
+[Build and push an Image]({{site.baseurl}}/docs/example-catalog/ci-examples/build-and-push-an-image)
+[Build an Image With build arguments]({{site.baseurl}}/docs/example-catalog/ci-examples/build-an-image-with-build-arguments)
+[Steps in pipelines]({{site.baseurl}}/docs/pipelines/steps/)
diff --git a/_docs/example-catalog/ci-examples/build-an-image-with-build-arguments.md b/_docs/example-catalog/ci-examples/build-an-image-with-build-arguments.md
new file mode 100644
index 000000000..63ff90ff1
--- /dev/null
+++ b/_docs/example-catalog/ci-examples/build-an-image-with-build-arguments.md
@@ -0,0 +1,134 @@
+---
+title: "Build an Image with build arguments"
+description: "Use Docker arguments in Codefresh pipelines"
+group: example-catalog
+sub_group: ci-examples
+redirect_from:
+ - /docs/yaml-examples/examples/build-an-image-with-build-arguments/
+ - /docs/build-an-image-with-build-arguments/
+toc: true
+---
+
+Building a Docker image that requires build arguments is very easy with Codefresh pipelines.
+
+The source code of the repository is at [https://github.com/codefreshdemo/cf-example-build-arguments](https://github.com/codefreshdemo/cf-example-build-arguments){:target="\_blank"}. Feel free to fork it if you want to follow along.
+
+If you don't have a Codefresh account already, you can easily create a free one from the [sign-up page]({{site.baseurl}}/docs/administration/account-user-management/create-a-codefresh-account/).
+
+## Using Docker build arguments
+
+The example application is a very simple NodeJS application with the following DYouockerfile:
+
+`Dockerfile`
+{% highlight docker %}
+{% raw %}
+ARG NODE_VERSION
+FROM node:$NODE_VERSION
+
+ARG APP_DIR
+
+RUN mkdir -p $APP_DIR
+
+WORKDIR $APP_DIR
+
+COPY package.json .
+RUN npm install --silent
+COPY . .
+EXPOSE 3000
+
+ENV PORT 3000
+
+CMD [ "npm", "start" ]
+{% endraw %}
+{% endhighlight %}
+
+This Dockerfile expects two [build arguments](https://docs.docker.com/engine/reference/builder/#/arg){:target="\_blank"}:
+
+* `NODE_VERSION` is the version of Node image to use as base
+* `APP_DIR` is the source directory to be used inside the container
+
+## Building a Dockerfile passing values for build arguments
+
+When you build an image locally on your workstation, you can define build arguments with the `--build-arg` syntax:
+
+```
+docker build . -t my-node-app --build-arg NODE_VERSION=8 --build-arg APP_DIR=/usr/src/app
+```
+
+You can get the same result within a Codefresh pipeline:
+
+
+ `codefresh.yml`
+{% highlight yaml %}
+{% raw %}
+version: '1.0'
+steps:
+ main_clone:
+ title: Cloning main repository...
+ type: git-clone
+ repo: 'codefreshdemo/cf-example-build-arguments'
+ revision: 'master'
+ git: github
+ build_my_app:
+ title: Building Node.Js Docker Image
+ type: build
+ image_name: my-app
+ working_directory: '.'
+ tag: 'master'
+ dockerfile: Dockerfile
+ build_arguments:
+ - NODE_VERSION=8
+ - APP_DIR=/usr/src/app
+{% endraw %}
+{% endhighlight %}
+
+This pipeline checks out the source code of the repository and then builds the Dockerfile by passing the values `8` and `/usr/src/app` to the two arguments.
+
+{% include image.html
+lightbox="true"
+file="/images/examples/docker-build/docker-build-arguments.png"
+url="/images/examples/docker-build/docker-build-arguments.png"
+alt="Using Docker build arguments in a pipeline"
+caption="Using Docker build arguments in a pipeline"
+max-width="100%"
+%}
+
+## Using Codefresh variables as build arguments
+
+In the previous pipeline, the Docker build arguments are defined in the pipeline itself, but you can also use [pipeline variables]({{site.baseurl}}/docs/pipelines/pipelines/#creating-new-pipelines), [shared configuration]({{site.baseurl}}/docs/pipelines/configuration/shared-configuration/), or any other standard mechanism you already have in place.
+
+ `codefresh.yml`
+{% highlight yaml %}
+{% raw %}
+version: '1.0'
+steps:
+ main_clone:
+ title: Cloning main repository...
+ type: git-clone
+ repo: 'codefreshdemo/cf-example-build-arguments'
+ revision: 'master'
+ git: github
+ build_my_app:
+ title: Building Node.Js Docker Image
+ type: build
+ image_name: my-app
+ working_directory: '.'
+ tag: 'master'
+ dockerfile: Dockerfile
+ build_arguments:
+ - NODE_VERSION=${{NODE_VERSION_FROM_SHARED_CONFIG}}
+ - APP_DIR=${{APP_DIR_PIPELINE_VARIABLE}}
+{% endraw %}
+{% endhighlight %}
+
+In this case, you can also use any of the built-in [Codefresh variables]({{site.baseurl}}/docs/pipelines/variables/).
+
+
+
+## Related articles
+[CI/CD pipeline examples]({{site.baseurl}}/docs/example-catalog/examples/#ci-examples)
+[Build step in pipelines]({{site.baseurl}}/docs/pipelines/steps/build/)
+[Build an Image with the Dockerfile in root directory]({{site.baseurl}}/docs/example-catalog/ci-examples/build-an-image-with-the-dockerfile-in-root-directory/)
+[Build an Image by specifying the Dockerfile location]({{site.baseurl}}/docs/example-catalog/ci-examples/build-an-image-specify-dockerfile-location)
+[Build an Image from a different Git repository]({{site.baseurl}}/docs/example-catalog/ci-examples/build-an-image-from-a-different-git-repository)
+[Build and push an Image]({{site.baseurl}}/docs/example-catalog/ci-examples/build-and-push-an-image)
diff --git a/_docs/example-catalog/ci-examples/build-an-image-with-the-dockerfile-in-root-directory.md b/_docs/example-catalog/ci-examples/build-an-image-with-the-dockerfile-in-root-directory.md
new file mode 100644
index 000000000..3ac88e4ac
--- /dev/null
+++ b/_docs/example-catalog/ci-examples/build-an-image-with-the-dockerfile-in-root-directory.md
@@ -0,0 +1,72 @@
+---
+title: "Build an Image with the Dockerfile in root directory"
+description: "Get started quickly with building Docker images"
+group: example-catalog
+sub_group: ci-examples
+redirect_from:
+ - /docs/yaml-examples/examples/build-an-image-with-the-dockerfile-in-root-directory/
+ - /docs/build-an-image-dockerfile-in-root-directory/
+ - /docs/deploy-to-kubernetes/get-ready-to-deploy/build-an-image/
+ - /docs/yaml-examples/examples/build-an-image-dockerfile-in-root-directory/
+toc: true
+---
+Building a Docker image is one of the basic operations in Codefresh pipelines.
+
+>The source code of the repository is at [https://github.com/codefreshdemo/cf-yml-example-build-dockerfile-inroot](https://github.com/codefreshdemo/cf-yml-example-build-dockerfile-inroot){:target="\_blank"}. Feel free to fork it if you want to follow along.
+
+If you don't have a Codefresh account already, you can easily create a free one from the [sign-up page]({{site.baseurl}}/docs/administration/account-user-management/create-codefresh-account/).
+
+
+## Building a Dockerfile from the root folder
+
+By default, if you run a single command like the one below, Docker uses the Dockerfile of the current folder:
+
+```
+docker build . -t my-web-app
+```
+
+You can get the same result within a Codefresh pipeline:
+
+
+ `codefresh.yml`
+{% highlight yaml %}
+{% raw %}
+version: '1.0'
+steps:
+ main_clone:
+ title: Cloning main repository...
+ type: git-clone
+ repo: 'codefreshdemo/cf-yml-example-build-dockerfile-inroot'
+ revision: 'master'
+ git: github
+ build_my_app:
+ title: Building Node.Js Docker Image
+ type: build
+ image_name: my-app
+ working_directory: '${{main_clone}}'
+ tag: 'master'
+ dockerfile: Dockerfile
+{% endraw %}
+{% endhighlight %}
+
+This pipeline checks out the source code of the repository and then builds a dockerfile found at the root folder of the project.
+
+{% include image.html
+lightbox="true"
+file="/images/examples/docker-build/build-dockerfile-root.png"
+url="/images/examples/docker-build/build-dockerfile-root.png"
+alt="Building a Docker image with a default Dockerfile"
+caption="Building a Docker image with a default Dockerfile"
+max-width="100%"
+%}
+
+You can also change the Docker build context by editing the `working_directory` property. By default, it looks at the root folder of the project, but any subfolder path is also valid.
+
+
+## Related articles
+[CI/CD pipeline examples]({{site.baseurl}}/docs/example-catalog/examples/#ci-examples)
+[Build step in pipelines]({{site.baseurl}}/docs/pipelines/steps/build/)
+[Build an Image by specifying the Dockerfile location]({{site.baseurl}}/docs/example-catalog/ci-examples/build-an-image-specify-dockerfile-location)
+[Build an Image from a different Git repository]({{site.baseurl}}/docs/example-catalog/ci-examples/build-an-image-from-a-different-git-repository)
+[Build and push an Image]({{site.baseurl}}/docs/example-catalog/ci-examples/build-and-push-an-image)
+[Build an Image with build arguments]({{site.baseurl}}/docs/example-catalog/ci-examples/build-an-image-with-build-arguments)
diff --git a/_docs/example-catalog/ci-examples/build-and-push-an-image.md b/_docs/example-catalog/ci-examples/build-and-push-an-image.md
new file mode 100644
index 000000000..4021b032c
--- /dev/null
+++ b/_docs/example-catalog/ci-examples/build-and-push-an-image.md
@@ -0,0 +1,137 @@
+---
+title: "Build and push an Image"
+description: "Build Docker images and push them to registries with Codefresh"
+group: example-catalog
+sub_group: ci-examples
+redirect_from:
+ - /docs/yaml-examples/examples/build-and-push-an-image/
+ - /docs/build-and-push-an-image/
+ - /docs/docker-registries/push-image-to-a-docker-registry/
+toc: true
+---
+
+Building a Docker image and then pushing it to a registry is one of the most basic scenarios for creating a pipeline.
+In this example we will use a demo Node.js application that will be packaged in a Docker image.
+
+The source code of the repository is at [https://github.com/codefreshdemo/cf-example-build-and-push](https://github.com/codefreshdemo/cf-example-build-and-push){:target="\_blank"}. Feel free to fork it if you want to follow along.
+
+If you don't have a Codefresh account already, you can easily create a free one from the [sign-up page]({{site.baseurl}}/docs/administration/account-user-management/create-a-codefresh-account/).
+
+
+## Building and push Docker image to default registry
+
+Building a Docker image with Codefresh is easy, and only requires a simple step. In addition, all successful pipelines in Codefresh automatically push to [your default Docker registry]({{site.baseurl}}/docs/integrations/docker-registries/#the-default-registry), without additional configuration, if you have one.
+
+Here is the most basic pipeline that clones a repo and builds an image:
+
+`codefresh.yml`
+{% highlight yaml %}
+{% raw %}
+version: '1.0'
+stages:
+- checkout
+- build
+steps:
+ clone:
+ title: Cloning main repository...
+ type: git-clone
+ stage: checkout
+ repo: 'codefreshdemo/cf-example-build-and-push'
+ revision: 'master'
+ git: github
+ build_my_app:
+ title: Building Node.Js Docker Image
+ type: build
+ stage: build
+ image_name: my-node-js-app
+ working_directory: {{clone}}
+ tag: 'master'
+ dockerfile: Dockerfile
+{% endraw %}
+{% endhighlight %}
+
+## Building and pushing Docker image to _any registry_.
+
+You can push your image to any [registry]({{site.baseurl}}/docs/integrations/docker-registries/).
+
+* First you need to connect your external registry in the integrations page. Here are the instructions for:
+
+ * [Docker Hub]({{site.baseurl}}/docs/integrations/docker-registries/docker-hub/)
+ * [Google Container Registry]({{site.baseurl}}/docs/integrations/docker-registries/google-container-registry/)
+ * [Amazon EC2 Container Registry]({{site.baseurl}}/docs/integrations/docker-registries/amazon-ec2-container-registry/)
+ * [Bintray.io]({{site.baseurl}}/docs/integrations/docker-registries/bintray-io/)
+ * [Quay.io]({{site.baseurl}}/docs/integrations/docker-registries/quay-io/)
+ * [Other Registries]({{site.baseurl}}/docs/integrations/docker-registries/other-registries/)
+
+* Then add a [push step]({{site.baseurl}}/docs/pipelines/steps/push/) in your pipeline and use the registry name of your integration.
+
+Here is the full example:
+
+`codefresh.yml`
+{% highlight yaml %}
+{% raw %}
+version: '1.0'
+stages:
+- checkout
+- build
+- push
+steps:
+ clone:
+ title: Cloning main repository...
+ type: git-clone
+ stage: checkout
+ repo: 'codefreshdemo/cf-example-build-and-push'
+ revision: 'master'
+ git: github
+ build_my_app:
+ title: Building Node.Js Docker Image
+ type: build
+ stage: build
+ image_name: my-node-js-app
+ working_directory: {{clone}}
+ tag: 'master'
+ dockerfile: Dockerfile
+ push_to_my_registry:
+ stage: 'push'
+ type: push
+ title: Pushing to a registry
+ candidate: ${{build_my_app}}
+ tag: 'v1.0.0'
+ registry: dockerhub
+ image_name: kkapelon/my-node-js-app
+{% endraw %}
+{% endhighlight %}
+
+Here we use a specific tag - `v1.0.0` but
+Codefresh has several variables that you can use to tag images. Common examples are `CF_BRANCH_TAG_NORMALIZED`, `CF_SHORT_REVISION` or `CF_BUILD_ID`. Read more on [variables]({{site.baseurl}}/docs/pipelines/variables/).
+
+{% include image.html
+ lightbox="true"
+ file="/images/examples/docker-build/build-and-push-pipeline.png"
+ url="/images/examples/docker-build/build-and-push-pipeline.png"
+ alt="Pushing image to external registry"
+ caption="Pushing image to external registry"
+ max-width="100%"
+ %}
+
+
+If you run the pipeline, the Docker image is pushed *both* to the private Docker regisry (by the build step) *and* the external docker registry (by the push step).
+
+
+## More options for pushing images
+
+Codefresh has several options when it comes to pushing images:
+
+* You can specify multiple tags to be pushed
+* You can use directly ECR registries
+* You can embed credentials in the push steps
+
+Read more in [push steps]({{site.baseurl}}/docs/pipelines/steps/push/) in pipelines.
+
+
+## Related articles
+[CI/CD pipeline examples]({{site.baseurl}}/docs/example-catalog/examples/#ci-examples)
+[Build an Image with the Dockerfile in root directory]({{site.baseurl}}/docs/example-catalog/ci-examples/build-an-image-dockerfile-in-root-directory/)
+[Build an Image by specifying the Dockerfile location]({{site.baseurl}}/docs/example-catalog/ci-examples/build-an-image-specify-dockerfile-location)
+[Build an Image from a different Git repository]({{site.baseurl}}/docs/example-catalog/ci-examples/build-an-image-from-a-different-git-repository)
+[Build an Image With Build arguments]({{site.baseurl}}/docs/example-catalog/ci-examples/build-an-image-with-build-arguments)
diff --git a/_docs/example-catalog/ci-examples/c-make.md b/_docs/example-catalog/ci-examples/c-make.md
new file mode 100644
index 000000000..82f7a38b3
--- /dev/null
+++ b/_docs/example-catalog/ci-examples/c-make.md
@@ -0,0 +1,76 @@
+---
+title: "Compile and test a C application"
+description: "Using Codefresh pipelines"
+group: example-catalog
+sub_group: ci-examples
+redirect_from:
+ - /docs/learn-by-example/cc/c-make/
+toc: true
+---
+
+Codefresh can work with any C/C++ application very easily as both `gcc` and `g++` are already offered in Dockerhub. There is also another example available with [C++ and cmake]({{site.baseurl}}/docs/example-catalog/ci-examples/cpp-cmake).
+
+## The example C project
+
+You can see the example project at [https://github.com/codefresh-contrib/c-sample-app](https://github.com/codefresh-contrib/c-sample-app){:target="\_blank"}. The repository contains a C starter project with a `Makefile` and several targets:
+
+* `make` compiles the code.
+* `make test` runs unit tests
+* `make clean` removes artifacts and binaries.
+
+There are also extra targets for `tags` and `etags`.
+
+## Create a CI pipeline for C applications
+
+Creating a CI/CD pipeline for C is very easy, because Codefresh can run any [gcc image](https://hub.docker.com/_/gcc/){:target="\_blank"} that you wish. Gcc docker images already contain the `make` utility.
+
+{% include image.html
+lightbox="true"
+file="/images/examples/cc/c-make-pipeline.png"
+url="/images/examples/cc/c-make-pipeline.png"
+alt="Compiling a C application in a pipeline"
+caption="Compiling a C application in a pipeline"
+max-width="80%"
+%}
+
+Here is the [full pipeline](https://github.com/codefresh-contrib/c-sample-app/blob/master/codefresh.yml){:target="\_blank"} that compiles the application after checking out the code.
+
+ `codefresh.yml`
+{% highlight yaml %}
+{% raw %}
+version: '1.0'
+stages:
+ - checkout
+ - build
+steps:
+ main_clone:
+ title: Cloning main repository...
+ stage: checkout
+ type: git-clone
+ repo: 'codefresh-contrib/c-sample-app'
+ revision: master
+ git: github
+ compile_my_sources:
+ title: Compile
+ stage: build
+ image: gcc
+ commands:
+ - make
+ run_my_tests:
+ title: Test
+ stage: build
+ image: gcc
+ commands:
+ - make test
+{% endraw %}
+{% endhighlight %}
+
+This pipeline clones the source code, compiles the code and runs unit tests. In all cases we use the public Docker image of Gcc that also contains `make`.
+
+
+## Related articles
+[C++ example]({{site.baseurl}}/docs/example-catalog/ci-examples/cpp-cmake/)
+[Codefresh YAML for pipeline definitions]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/)
+[Steps in pipelines]({{site.baseurl}}/docs/pipelines/steps/)
+[Creating pipelines]({{site.baseurl}}/docs/pipelines/pipelines/)
+[How Codefresh pipelines work]({{site.baseurl}}/docs/pipelines/introduction-to-codefresh-pipelines/)
\ No newline at end of file
diff --git a/_docs/example-catalog/ci-examples/call-child-pipelines.md b/_docs/example-catalog/ci-examples/call-child-pipelines.md
new file mode 100644
index 000000000..276e28afc
--- /dev/null
+++ b/_docs/example-catalog/ci-examples/call-child-pipelines.md
@@ -0,0 +1,110 @@
+---
+title: "Call a CD pipeline from a CI pipeline"
+description: "How to call child pipelines from a parent pipeline"
+group: example-catalog
+sub_group: ci-examples
+redirect_from:
+ - /docs/yaml-examples/examples/call-child-pipelines/
+toc: true
+---
+
+In Codefresh you can easily create nested pipelines by calling other pipelines from within an existing pipeline. The [codefresh-run plugin](https://codefresh.io/steps/step/codefresh-run){:target="\_blank"} allows you to launch another pipeline, and optionally wait for its completion.
+
+{% include image.html
+lightbox="true"
+file="/images/examples/nested-pipelines/call-other-pipeline.png"
+url="/images/examples/nested-pipelines/call-other-pipeline.png"
+alt="Parent and child pipelines"
+caption="Parent and child pipelines"
+max-width="80%"
+%}
+
+A very common pattern in Codefresh is to have a parent pipeline responsible for Continuous Integration (packaging code), that calls a child pipeline for Continuous Delivery (taking care of deployment).
+
+## Example project
+
+You can see the example project at [https://github.com/codefresh-contrib/call-child-pipeline-sample-app](https://github.com/codefresh-contrib/call-child-pipeline-sample-app){:target="\_blank"}. The repository contains a NodeJs app as well as three - one parent and two child pipelines.
+
+## Create a pipeline that calls other pipelines
+
+Here is the definition of the parent pipeline:
+
+ `codefresh.yml`
+{% highlight yaml %}
+{% raw %}
+version: '1.0'
+stages:
+ - prepare
+ - package
+ - deploy
+steps:
+ main_clone:
+ title: 'Cloning main repository...'
+ type: git-clone
+ repo: '${{CF_REPO_OWNER}}/${{CF_REPO_NAME}}'
+ revision: '${{CF_REVISION}}'
+ git: github
+ stage: prepare
+ read_my_app_version:
+ title: Reading Application version
+ stage: prepare
+ image: node:latest
+ commands:
+ - export PACKAGE_VERSION=$(node -p "require('./package.json').version")
+ - cf_export PACKAGE_VERSION
+ build_my_docker_image:
+ title: 'Building My Docker Image'
+ stage: package
+ type: build
+ dockerfile: Dockerfile
+ image_name: my-app-image
+ tag: ${{PACKAGE_VERSION}}
+ call_qa_pipeline:
+ title: Deploy to QA
+ stage: deploy
+ type: codefresh-run
+ arguments:
+ PIPELINE_ID: child-pipelines/qa-pipeline
+ VARIABLE:
+ - CF_BRANCH=${{CF_BRANCH}}
+ - CF_REVISION=${{CF_REVISION}}
+ - APP_VERSION=${{PACKAGE_VERSION}}
+ when:
+ branch:
+ only:
+ - develop
+ call_prod_pipeline:
+ title: Deploy to Prod
+ stage: deploy
+ type: codefresh-run
+ arguments:
+ PIPELINE_ID: child-pipelines/prod-pipeline
+ VARIABLE:
+ - CF_BRANCH=${{CF_BRANCH}}
+ - CF_REVISION=${{CF_REVISION}}
+ - APP_VERSION=${{PACKAGE_VERSION}}
+ when:
+ branch:
+ only:
+ - /^release.*/i
+
+
+{% endraw %}
+{% endhighlight %}
+
+This pipeline does the following:
+
+1. Clones the source code through a [Git clone step]({{site.baseurl}}/docs/pipelines/steps/git-clone/).
+1. Creates a variable that contains the Application version as specified in `package.json` through [cf_export]({{site.baseurl}}/docs/pipelines/variables/#using-cf_export-command).
+1. Builds a docker image tagged with the Application version through a [build step]({{site.baseurl}}/docs/pipelines/steps/build/).
+1. Optionally runs the downstream QA pipeline if the branch is named `develop`. It also passes several environment variables to the child pipeline (including the Application version).
+1. Optionally runs the downstream Prod pipeline if the branch name starts with `release`. It also passes several environment variables to the child pipeline (including the Application version).
+
+The last two steps use [conditions]({{site.baseurl}}/docs/pipelines/conditional-execution-of-steps/) to decide if they will run or not.
+
+## Related articles
+[CI/CD pipeline examples]({{site.baseurl}}/docs/example-catalog/examples/#ci-examples)
+[Codefresh YAML for pipeline definitions]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/)
+[Steps in pipelines]({{site.baseurl}}/docs/pipelines/steps/)
+[Creating pipelines]({{site.baseurl}}/docs/pipelines/pipelines/)
+[Pipeline plugins](https://codefresh.io/steps/){:target="\_blank"}
\ No newline at end of file
diff --git a/_docs/example-catalog/ci-examples/codacy-testing.md b/_docs/example-catalog/ci-examples/codacy-testing.md
new file mode 100644
index 000000000..355246c63
--- /dev/null
+++ b/_docs/example-catalog/ci-examples/codacy-testing.md
@@ -0,0 +1,175 @@
+---
+title: "Codacy coverage reports"
+description: "How to forward coverage reports to Codacy"
+group: example-catalog
+sub_group: ci-examples
+redirect_from:
+ - /docs/yaml-examples/examples/codacy-testing/
+toc: true
+---
+
+[Codacy](https://www.codacy.com/){:target="\_blank"} is a code review tool that allows automatic analysis, code coverage tracking, and extensive reports, for you and your team to improve your code quality over time.
+
+Analysis reports displayed within Codacy dashboard:
+{% include image.html
+lightbox="true"
+file="/images/testing/codacy/codacy-report.png"
+url="/images/testing/codacy/codacy-report.png"
+alt="Codacy UI with coverage reports"
+max-width="100%"
+%}
+
+## Prerequisites for using Codacy
+* A simple [Codefresh pipeline, up and running]({{site.baseurl}}/docs/quick-start/ci-quick-start/create-ci-pipeline/)
+* A [Codacy account](https://www.codacy.com/){:target="\_blank"} (free, pro or enterprise)
+* A testing tool added to your project that produces coverage reports
+
+Codacy supports over [30 different language integrations](https://docs.codacy.com/getting-started/supported-languages-and-tools/){:target="\_blank"}. Depending on the programming language used, it requires little to no set-up.
+
+You could try it out by cloning our [node example application](https://github.com/codefresh-contrib/codacy-sample-app){:target="\_blank"} that utilises [jest](https://jestjs.io/){:target="\_blank"}.
+
+## Create an account with Codacy
+Codacy has a free version, a pro version, and an on-premises version. The latter two have a free trial, which allows you to test all features over the course of two weeks. You can sign-up via GitHub, Bitbucket, or GitLab.
+
+When you log into Codacy for the first time, it will ask you to provide access to a repository. At this stage, Codacy will not download any code from your repository but merely access its names. You can then either provide access to selective repositories or your entire git account.
+
+{% include image.html
+lightbox="true"
+file="/images/testing/codacy/codacy-add-repo.png"
+url="/images/testing/codacy/codacy-add-repo.png"
+alt="Add repository to codacy"
+max-width="80%"
+%}
+
+## Generate Project API token
+To use Codacy, we need a project API token. To generate the token, select your project => go to settings => integrations => add integration => select “Project API”. Make sure that you select the API token from here and not your general project settings.
+
+{% include image.html
+lightbox="true"
+file="/images/testing/codacy/create-api-token.png"
+url="/images/testing/codacy/create-api-token.png"
+alt="Create Project API token"
+max-width="80%"
+%}
+
+## Codefresh pipeline
+
+If the project you want to use Codacy in does not have a pipeline, [create a new pipeline]({{site.baseurl}}/docs/quick-start/ci-quick-start/create-ci-pipeline/).
+
+{% include image.html
+lightbox="true"
+file="/images/testing/codacy/create-codacy-pipeline.png"
+url="/images/testing/codacy/create-codacy-pipeline.png"
+alt="Create Codacy Pipeline"
+max-width="80%"
+%}
+
+**Setting-up step**
+
+This step is based on our [TypeScript application](https://github.com/codefresh-contrib/codacy-sample-app){:target="\_blank"}. Before we set up our pipeline, we will add our Project API token as our environment variable. Note that we have specified our token in the variables section on the right, as displayed in the following screenshot.
+
+{% include image.html
+lightbox="true"
+file="/images/testing/codacy/codacy-variable.png"
+url="/images/testing/codacy/codacy-variable.png"
+alt="Provide Codacy ENV variable"
+max-width="80%"
+%}
+
+Once the variable is called through the [Codefresh YAML syntax]({{site.baseurl}}/docs/pipelines/variables/), it automatically uses the value provided within the variables section. If you are using this example as your pipeline, please delete anything in your pipeline. We can then add the following pipeline to our Inline YAML within the Workflow section in our UI:
+
+{% highlight yaml %}
+{% raw %}
+version: "1.0"
+# Stages can help you organize your steps in stages
+stages:
+ - "clone"
+ - "build"
+ - "test"
+
+steps:
+ clone:
+ title: "Cloning repository"
+ type: "git-clone"
+ repo: "anais-codefresh/codacy-sample-app"
+ # CF_BRANCH value is auto set when pipeline is triggered
+ # Learn more at codefresh.io/docs/docs/pipelines/variables/
+ revision: "${{CF_BRANCH}}"
+ git: "github"
+ stage: "clone"
+
+ build:
+ title: "Building Docker image"
+ type: "build"
+ image_name: "anaisurlichs/codacy-sample-app"
+ working_directory: "${{clone}}"
+ tag: "${{CF_BRANCH_TAG_NORMALIZED}}"
+ dockerfile: "Dockerfile"
+ stage: "build"
+ registry: "dockerhub"
+
+ tests:
+ title: "Running test"
+ type: "freestyle"
+ working_directory: '${{clone}}'
+ arguments:
+ image: 'node:15.2'
+ commands:
+ - "npm install --save-dev jest"
+ - "npm run test"
+ stage: "test"
+
+ codacy:
+ title: "Pushing reports to codacy"
+ type: "freestyle"
+ working_directory: '${{clone}}'
+ arguments:
+ image: 'alpine:3.8'
+ commands:
+ - "export CODACY_PROJECT_TOKEN=${{CODACY_PROJECT_TOKEN}}"
+ - "wget -qO - https://coverage.codacy.com/get.sh | sh"
+ stage: "test"
+{% endraw %}
+{% endhighlight %}
+
+The last two steps, ’tests’ and ’codacy’, are used to run our tests, create our coverage reports and forward those to Codacy. If you are using your own project and existing pipeline, add those two steps to your pipeline. In case you are using your own application, make sure to adapt the commands within the test step to run the tests of your application. Additionally, ensure that both the ’repo’ and the ’image_name’ point to your integrations.
+
+Once you run the pipeline, the steps will create the coverage report and forwards it to Codacy.
+
+{% include image.html
+lightbox="true"
+file="/images/testing/codacy/codacy-pipeline.png"
+url="/images/testing/codacy/codacy-pipeline.png"
+alt="Pipeline with Codacy step"
+max-width="80%"
+%}
+
+## View reports
+
+You can view the updated coverage reports within Codacy's UI every time you make a commit and/or run the Codefresh pipeline directly.
+
+{% include image.html
+lightbox="true"
+file="/images/testing/codacy/codacy-report.png"
+url="/images/testing/codacy/codacy-report.png"
+alt="Codacy UI Analysis Dashboard"
+max-width="80%"
+%}
+
+You can access further information on the coverage report by opening the file tab and accessing a specific file from your repository.
+
+{% include image.html
+lightbox="true"
+file="/images/testing/codacy/file-analysis.png"
+url="/images/testing/codacy/file-analysis.png"
+alt="Codacy report details"
+max-width="90%"
+%}
+
+## Related articles
+[CI pipeline examples]({{site.baseurl}}/docs/example-catalog/examples/#ci-examples)
+[Codefresh YAML for pipeline definitions]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/)
+[Steps in pipelines]({{site.baseurl}}/docs/pipelines/steps/)
+[Unit tests]({{site.baseurl}}/docs/testing/unit-tests/)
+[Integration tests]({{site.baseurl}}/docs/testing/integration-tests/)
+[SonarQube Integration]({{site.baseurl}}/docs/testing/sonarqube-integration/)
diff --git a/_docs/example-catalog/ci-examples/codecov-testing.md b/_docs/example-catalog/ci-examples/codecov-testing.md
new file mode 100644
index 000000000..e716f82f3
--- /dev/null
+++ b/_docs/example-catalog/ci-examples/codecov-testing.md
@@ -0,0 +1,130 @@
+---
+title: "Codecov coverage reports"
+description: "How to forward coverage reports to Codecov"
+group: example-catalog
+sub_group: ci-examples
+redirect_from:
+ - /docs/yaml-examples/examples/codecov-testing/
+toc: true
+---
+
+[Codecov account](https://codecov.io/){:target="\_blank"} is a code analysis tool with which users can group, merge, archive, and compare coverage reports. Code coverage describes which lines of code were executed by the test suite and which ones were not. However, this is not to be confused with a testing tool.
+
+Analysis reports displayed within the Codecov dashboard:
+{% include image.html
+lightbox="true"
+file="/images/testing/codecov/analysis-report.png"
+url="/images/testing/codecov/analysis-report.png"
+alt="Codecov UI Analysis reports"
+max-width="50%"
+%}
+
+## Prerequisites for using Codecov
+
+* A [Codefresh pipeline, up and running]({{site.baseurl}}/docs/quick-start/ci-quick-start/create-ci-pipeline/)
+* A [Codecov account](https://codecov.io/){:target="\_blank"} (free or enterprise)
+* A testing tool added to your project that produces coverage reports
+
+Note that reports should ideally be written in .json, .xml, or txt. To be sure, please double check that your coverage [report format](https://docs.codecov.io/docs/supported-report-formats){:target="\_blank"} is supported. You can find a variety of examples for different programming languages and suggestions for respective testing tools in the [Codecov docs](https://docs.codecov.io/docs/supported-languages){:target="\_blank"}.
+
+To test Codecov and follow along with the next section, you can clone our [Codecov sample app](https://github.com/codefresh-contrib/codecov-sample-app){:target="\_blank"}.
+
+## Create a Codecov account
+
+Once you sign up to Codecov, you can add a new repository. The UI will then provide you with an access token to the repository. While it is recommended that you take note of the token, you will still be able to access it within the **Settings** tap.
+
+{% include image.html
+lightbox="true"
+file="/images/testing/codecov/codecov-interface.png"
+url="/images/testing/codecov/codecov-interface.png"
+alt="Codecov Project Repository UI"
+max-width="50%"
+%}
+
+## Codefresh pipeline
+
+In this case, we divided testing and connecting Codefresh to Codecov into two different steps. If they can be run within the same image, you could also connect them.
+
+**Testing step**
+Runs the command(s) for our testing tool. This will generate the code coverage report upon running the pipeline. Please refer to the Codecov documentation for [supported testing frameworks](https://docs.codecov.io/docs/supported-report-formats){:target="\_blank"}. The [README of each example](https://docs.codecov.io/docs/supported-languages){:target="\_blank"} refers to possible frameworks that can be used.
+
+In general, ensure that the framework you use for testing and generating code coverage reports:
+* Produce code coverage reports in the supported file format
+* Is compatible with the programming language that your program is written in
+
+{% highlight yaml %}
+{% raw %}
+ test:
+ title: "Running test"
+ type: "freestyle" # Run any command
+ image: "node:14.19.0" # The image in which command will be executed
+ working_directory: "${{clone}}" # Running command where code cloned
+ commands:
+ - "npm install --save-dev jest"
+ - "npx jest --coverage"
+ stage: "test"
+{% endraw %}
+{% endhighlight %}
+
+**Codecov step**
+
+{% highlight yaml %}
+{% raw %}
+upload:
+ title: "Running test"
+ type: "freestyle" # Run any command
+ image: "node:14.19.0" # The image in which command will be executed
+ working_directory: "${{clone}}" # Running command where code cloned
+ commands:
+ - "ci_env=`curl -s https://codecov.io/env`"
+ - "npm install codecov -g"
+ - "codecov -t ${{CODECOV_TOKEN}} -f ./coverage/clover.xml"
+ stage: "upload"
+{% endraw %}
+{% endhighlight %}
+
+The commands run inside of the node Docker image:
+* `ci_env= curl -s https://codecov.io/env`: Sets the CI environment variable to take note that we are using Codefresh
+* `npm install codecov -g`: Installs the odecov CLI
+* `codecov -t ${{CODECOV_TOKEN}} -f ./coverage/clover.xml`: Sets the Codevoc access token provided in the UI when we connect to a new Git repository and point to the file that contains our coverage report.
+
+Once you run the pipeline, the steps will create the coverage report and forward it to Codecov.
+
+{% include image.html
+lightbox="true"
+file="/images/testing/codecov/codecov-pipeline.png"
+url="/images/testing/codecov/codecov-pipeline.png"
+alt="Pipeline with codecov step"
+max-width="50%"
+%}
+
+## View reports
+
+You can view the updated coverage reports within the Codecov UI every time you make a commit and/or run the Codefresh pipeline directly.
+
+{% include image.html
+lightbox="true"
+file="/images/testing/codecov/codecov-report.png"
+url="/images/testing/codecov/codecov-report.png"
+alt="Pipeline with codecov step"
+max-width="50%"
+%}
+
+You can access further information on the coverage report by opening the link to the file displayed in the table.
+
+{% include image.html
+lightbox="true"
+file="/images/testing/codecov/codecov-report-details.png"
+url="/images/testing/codecov/codecov-report-details.png"
+alt="Codecov report details"
+max-width="50%"
+%}
+
+## Related articles
+[CI pipeline examples]({{site.baseurl}}/docs/example-catalog/examples/#ci-examples)
+[Codefresh YAML for pipeline definitions]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/)
+[Steps in pipelines]({{site.baseurl}}/docs/pipelines/steps/)
+[Unit tests]({{site.baseurl}}/docs/testing/unit-tests/)
+[Integration tests]({{site.baseurl}}/docs/testing/integration-tests/)
+[SonarQube integration]({{site.baseurl}}/docs/testing/sonarqube-integration/)
+
diff --git a/_docs/example-catalog/ci-examples/coveralls-testing.md b/_docs/example-catalog/ci-examples/coveralls-testing.md
new file mode 100644
index 000000000..4257d0481
--- /dev/null
+++ b/_docs/example-catalog/ci-examples/coveralls-testing.md
@@ -0,0 +1,223 @@
+---
+title: "Coveralls coverage reports"
+description: "How to forward coverage reports to Coveralls"
+group: example-catalog
+sub_group: ci-examples
+redirect_from:
+ - /docs/yaml-examples/examples/coveralls-testing/
+toc: true
+---
+
+[Coveralls](https://coveralls.io/){:target="\_blank"} is a web service that allows users to track the code coverage of their application over time in order to optimize the effectiveness of their unit tests. This section details how coverage reports can be generated and forwarded to Coveralls with every Codefresh build.
+
+Analysis reports displayed within Coveralls dashboard:
+{% include image.html
+lightbox="true"
+file="/images/testing/coveralls/coveralls-sample-app.png"
+url="/images/testing/coveralls/coveralls-sample-app.png"
+alt="Coveralls UI Analysis reports"
+max-width="80%"
+%}
+
+## Prerequisites for using Coveralls
+
+* A simple [Codefresh pipeline up and running]({{site.baseurl}}/docs/quick-start/ci-quick-start/create-ci-pipeline/)
+* A [Coveralls account](https://coveralls.io/) (free or enterprise) -- Note that all open-source projects are free on Coveralls
+* A testing tool added to your project that produces coverage reports
+
+Coveralls supports [22 different language integrations](https://docs.coveralls.io/about-coveralls){:target="\_blank"}. Each example provided in the official documentation suggests several coverage report tools that can be used in combination with Coveralls.
+
+You could try it out by cloning our [node example application](https://github.com/codefresh-contrib/coveralls-sample-app){:target="\_blank"} that utilises [jest](https://jestjs.io/){:target="\_blank"}.
+
+## Prepare your repository
+
+If you are using your own application as an example, you have to make a few modifications to the repository. Please have a look at the Coveralls example section for other languages.
+
+First, install Coveralls in your project:
+{% highlight yaml %}
+{% raw %}
+npm install coveralls --save-dev
+{% endraw %}
+{% endhighlight %}
+
+Coveralls requires a [script](https://github.com/nickmerwin/node-coveralls){:target="\_blank"} that takes standard input and sends it to coveralls.io to report your code coverage. Depending on the framework that you are using, you will have to add a different script to your application.
+
+Any coverage reports can be forwarded that are within a [lcov data format](https://github.com/linux-test-project/lcov){:target="\_blank"} (including [mocha's LCOV reporter](https://www.npmjs.com/package/mocha-lcov-reporter){:target="\_blank"}). For this, we are going to set-up a “bin” folder, and within the folder a coveralls.js file that contains the following content:
+
+{% highlight yaml %}
+{% raw %}
+#!/usr/bin/env node
+
+'use strict';
+
+const { handleInput } = require('..');
+
+process.stdin.resume();
+process.stdin.setEncoding('utf8');
+
+let input = '';
+
+process.stdin.on('data', chunk => {
+ input += chunk;
+});
+
+process.stdin.on('end', () => {
+ handleInput(input, err => {
+ if (err) {
+ throw err;
+ }
+ });
+});
+{% endraw %}
+{% endhighlight %}
+
+## Create a Coveralls account
+
+Once you sign-up to Coveralls, you can add a new repository. The UI will then provide you with an access token to the repository. Take note of the token since it will be required in the next sections.
+
+{% include image.html
+lightbox="true"
+file="/images/testing/coveralls/add-repository.png"
+url="/images/testing/coveralls/add-repository.png"
+alt="Coveralls repository"
+max-width="80%"
+%}
+
+## Codefresh pipeline
+
+
+If the project you want to use Coveralls in does not have a pipeline, [create a new pipeline]({{site.baseurl}}/docs/quick-start/ci-quick-start/create-ci-pipeline/).
+
+{% include image.html
+lightbox="true"
+file="/images/testing/coveralls/create-coveralls-pipeline.png"
+url="/images/testing/coveralls/create-coveralls-pipeline.png"
+alt="Create Coveralls Pipeline"
+max-width="80%"
+%}
+
+Once you ’create’ the pipeline, a standard codefresh.yml file is generated with three steps:
+* The first step will clone your repository;
+* The second step will both, build and push your repository to the container registry that you have connected with Codefresh;
+* And the third step currently does not do much.
+In the next section, we will modify the testing step.
+
+**Testing step**
+
+The testing step requires three different environment variables to connect to Coveralls:
+* `export COVERALLS_SERVICE_NAME="codefresh"`
+* `export COVERALLS_GIT_BRANCH="insert the branch that you will be using with your application"`
+* `export COVERALLS_REPO_TOKEN="insert the secret repo token from coveralls.io"`
+
+{% highlight yaml %}
+{% raw %}
+ test:
+ title: "Running test"
+ type: "freestyle" # Run any command
+ image: "node:15.2" # The image in which command will be executed
+ working_directory: "${{clone}}" # Running command where code cloned
+ commands:
+ - "export COVERALLS_SERVICE_NAME=${{COVERALLS_SERVICE_NAME}}"
+ - "export COVERALLS_GIT_BRANCH=${{CF_BRANCH}}"
+ - "export COVERALLS_REPO_TOKEN=${{COVERALLS_REPO_TOKEN}}"
+ - "npm install --save-dev jest"
+ - "npm run test"
+ stage: "test"
+{% endraw %}
+{% endhighlight %}
+
+We specify several variables within this step. Those, which start with ’CF’ are [Codefresh-specific steps]({{site.baseurl}}/docs/pipelines/variables/) and the value is automatically provided by Codefresh once you run the pipeline. Our entire codefresh.yml will look as such:
+
+{% highlight yaml %}
+{% raw %}
+version: "1.0"
+stages:
+ - "clone"
+ - "build"
+ - "test"
+
+steps:
+ clone:
+ title: "Cloning repository"
+ type: "git-clone"
+ repo: "anais-codefresh/coveralls-sample-app"
+ # CF_BRANCH value is auto set when pipeline is triggered
+ # Learn more at codefresh.io/docs/docs/pipelines/variables/
+ revision: "${{CF_BRANCH}}"
+ git: "github"
+ stage: "clone"
+
+ build:
+ title: "Building Docker image"
+ type: "build"
+ image_name: "anaisurlichs/coveralls-sample-app"
+ working_directory: "${{clone}}"
+ tag: "${{CF_BRANCH_TAG_NORMALIZED}}"
+ dockerfile: "Dockerfile"
+ stage: "build"
+ registry: "dockerhub"
+
+ test:
+ title: "Running test"
+ type: "freestyle" # Run any command
+ image: "node:15.2" # The image in which command will be executed
+ working_directory: "${{clone}}" # Running command where code cloned
+ commands:
+ - "export COVERALLS_SERVICE_NAME=${{COVERALLS_SERVICE_NAME}}"
+ - "export COVERALLS_GIT_BRANCH=${{CF_BRANCH}}"
+ - "export COVERALLS_REPO_TOKEN=${{COVERALLS_REPO_TOKEN}}"
+ - "npm install --save-dev jest"
+ - "npm run test"
+ stage: "test"
+{% endraw %}
+{% endhighlight %}
+
+Once you run the pipeline the steps will create the coverage report and forward it to Coveralls.
+
+{% include image.html
+lightbox="true"
+file="/images/testing/coveralls/coveralls-pipeline.png"
+url="/images/testing/coveralls/coveralls-pipeline.png"
+alt="Pipeline with Coveralls step"
+max-width="80%"
+%}
+
+## View reports
+
+You can view the updated coverage reports within Coveralls UI every time you make a commit and/or run the Codefresh pipeline directly.
+
+{% include image.html
+lightbox="true"
+file="/images/testing/coveralls/coveralls-sample-app.png"
+url="/images/testing/coveralls/coveralls-sample-app.png"
+alt="Coveralls UI Analysis reports"
+max-width="80%"
+%}
+
+You can access further information on the coverage report by opening the link to the file displayed in the table.
+
+{% include image.html
+lightbox="true"
+file="/images/testing/coveralls/coveralls-specific-report.png"
+url="/images/testing/coveralls/coveralls-specific-report.png"
+alt="Coveralls report details"
+max-width="80%"
+%}
+
+And view a the code coverage of a specific file:
+{% include image.html
+lightbox="true"
+file="/images/testing/coveralls/coveralls-coverage.png"
+url="/images/testing/coveralls/coveralls-coverage.png"
+alt="Coveralls report details"
+max-width="80%"
+%}
+
+
+## Related articles
+[CI pipeline examples]({{site.baseurl}}/docs/example-catalog/examples/#ci-examples)
+[Codefresh YAML for pipeline definitions]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/)
+[Steps in pipelines]({{site.baseurl}}/docs/pipelines/steps/)
+[Unit tests]({{site.baseurl}}/docs/testing/unit-tests/)
+[Integration tests]({{site.baseurl}}/docs/testing/integration-tests/)
+[SonarQube integration]({{site.baseurl}}/docs/testing/sonarqube-integration/)
diff --git a/_docs/example-catalog/ci-examples/cpp-cmake.md b/_docs/example-catalog/ci-examples/cpp-cmake.md
new file mode 100644
index 000000000..8e5220adc
--- /dev/null
+++ b/_docs/example-catalog/ci-examples/cpp-cmake.md
@@ -0,0 +1,127 @@
+---
+title: "Compile and test a C++ application"
+description: "Using Codefresh pipelines"
+group: example-catalog
+sub_group: ci-examples
+redirect_from:
+ - /docs/learn-by-example/cc/cpp-cmake/
+toc: true
+---
+
+Codefresh can work with any C/C++ application very easily as both `gcc` and `g++` are already offered in Dockerhub. There is also another example available with [C and make]({{site.baseurl}}/docs/example-catalog/ci-examples/c-make).
+
+## The example C++ project
+
+You can see the example project at [https://github.com/codefresh-contrib/cpp-sample-app](https://github.com/codefresh-contrib/cpp-sample-app){:target="\_blank"}. The repository contains a C++ starter project with a `CMakeLists.txt` file:
+
+* `cmake .` creates the makefiles.
+* `make test` runs unit tests
+* `make` compiles the code
+
+The project is also using the [boost testing libraries](https://www.boost.org/){:target="\_blank"}.
+
+## Cmake, g++ and Docker
+
+Creating a CI/CD pipeline for C is very easy, because Codefresh can run any [gcc image](https://hub.docker.com/_/gcc/){:target="\_blank"} that you wish. Gcc docker images already contain the `make` utility but not the the `cmake` one. Therefore we will first create a Dockerfile that has `g++`, cmake and the boost libraries. You can follow the same pattern for other development tools that you use.
+
+
+Here is the Dockerfile:
+
+ `Dockerfile`
+{% highlight docker %}
+{% raw %}
+FROM gcc:9.2
+
+ENV DEBIAN_FRONTEND noninteractive
+
+RUN apt-get update && apt-get install -y cmake libgtest-dev libboost-test-dev && rm -rf /var/lib/apt/lists/*
+
+CMD ["cmake"]
+
+{% endraw %}
+{% endhighlight %}
+
+This docker build does the following:
+
+1. Starts from the GCC image
+1. Installs cmake and boost
+1. Sets cmake as the default command
+
+## Create a CI pipeline for C++ applications
+
+We can now use the custom Docker image in order to compile/test the C++ application:
+
+{% include image.html
+lightbox="true"
+file="/images/examples/cc/cpp-cmake-pipeline.png"
+url="/images/examples/cc/cpp-cmake-pipeline.png"
+alt="Compiling a C++ application in a pipeline"
+caption="Compiling a C++ application in a pipeline"
+max-width="80%"
+%}
+
+Here is the [full pipeline](https://github.com/codefresh-contrib/cpp-sample-app/blob/master/codefresh.yml){:target="\_blank"} that compiles the application after checking out the code.
+
+ `codefresh.yml`
+{% highlight yaml %}
+{% raw %}
+version: '1.0'
+stages:
+ - checkout
+ - prepare
+ - build
+steps:
+ main_clone:
+ title: Cloning main repository...
+ stage: checkout
+ type: git-clone
+ repo: 'codefresh-contrib/cpp-sample-app'
+ revision: master
+ git: github
+ build_dev_image:
+ title: Building Dev Image
+ stage: prepare
+ type: build
+ image_name: cmake
+ working_directory: ./dev/
+ tag: 'latest'
+ dockerfile: Dockerfile
+ create_makefiles:
+ title: Create Makefiles
+ stage: prepare
+ image: ${{build_dev_image}}
+ commands:
+ - cmake .
+ compile_my_sources:
+ title: Compile
+ stage: build
+ image: ${{build_dev_image}}
+ commands:
+ - make
+ run_my_tests:
+ title: Test
+ stage: build
+ image: ${{build_dev_image}}
+ commands:
+ - make test
+{% endraw %}
+{% endhighlight %}
+
+This pipeline:
+
+1. clones the source code
+1. Creates a development docker image that has g++, cmake and boost
+1. Runs cmake on the source code to create the make files
+1. Compiles the source code
+1. Runs unit tests
+
+You can add additional tools in the pipeline by extending the Dockerfile mentioned in the previous section. You can also
+change the version of Gcc/g++ by starting from a different public or private Docker image.
+
+
+## Related articles
+[C example]({{site.baseurl}}/docs/example-catalog/ci-examples/c-make/)
+[Codefresh YAML for pipeline definitions]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/)
+[Steps in pipelines]({{site.baseurl}}/docs/pipelines/steps/)
+[Creating pipelines]({{site.baseurl}}/docs/pipelines/pipelines/)
+[How Codefresh pipelines work]({{site.baseurl}}/docs/pipelines/introduction-to-codefresh-pipelines/)
\ No newline at end of file
diff --git a/_docs/example-catalog/ci-examples/decryption-with-mozilla-sops.md b/_docs/example-catalog/ci-examples/decryption-with-mozilla-sops.md
new file mode 100644
index 000000000..12876a79a
--- /dev/null
+++ b/_docs/example-catalog/ci-examples/decryption-with-mozilla-sops.md
@@ -0,0 +1,179 @@
+---
+title: "Decrypt with Mozilla SOPS"
+description: "Store secrets in your repository and decrypt them using Mozilla SOPS"
+group: example-catalog
+sub_group: ci-examples
+redirect_from:
+ - /docs/yaml-examples/examples/decryption-with-mozilla-sops/
+toc: true
+---
+
+## Prerequisites
+
+- A [Codefresh account]({{site.baseurl}}/docs/administration/account-user-management/create-codefresh-account/)
+- A public and private GnuGP key pair
+- A credentials yaml, that is encrypted using Mozilla SOPS, and stored in your repository
+
+## Example Java application
+
+You can find the example project on [GitHub](https://github.com/codefresh-contrib/mozilla-sops-app){:target="\_blank"}.
+
+The example application retrieves the system variable "password," from the pipeline and uses it to authenticate to a Redis database, but you are free to use any type of database of your choosing.
+
+```java
+ String password = System.getenv("password");
+ String host = System.getProperty("server.host");
+
+ RedisClient redisClient = new RedisClient(
+ RedisURI.create("redis://" + password + "@" + host + ":6379"));
+ RedisConnection connection = redisClient.connect();
+```
+
+Also in the example application is a simple unit test that ensures we are able to read and write data to the database.
+
+An encrypted credentials file is stored in the repository (along with a public key):
+
+`credentials.yaml`
+```yaml
+password: ENC[AES256_GCM,data:Jsth2tY8GhLgj6Jct27l,iv:3vcKVoD5ms29R5SWHiFhDhSAvvJTRzjn9lA6woroUQ8=,tag:OjkLvcHxE4m5RSCV7ej+FA==,type:str]
+sops:
+ kms: []
+ gcp_kms: []
+ azure_kv: []
+ lastmodified: '2020-03-30T19:12:49Z'
+ mac: ENC[AES256_GCM,data:jGMTkFhXjgGMdWBpaSWjGZP6fta3UuYjEsnqziNELQZ2cLScT9v+GKg/c8iJYv1Gfiz3aw4ivYYrWzwmZehIbPHaw3/XBv/VRCQhzRWYKaf6pPFUXIS7XALSf9L9VbGOXL/CGPRae3t3HpaOor+knd6iQk2WR3K9kSeib4RBSCE=,iv:WSP8hBwaBv3ymTGltBOaVVC1sT08IG4hwqESlG8rN9w=,tag:3hZvCuql+ASWe/Mm5Bl7xg==,type:str]
+ pgp:
+ - created_at: '2020-03-30T19:12:49Z'
+ enc: |
+ -----BEGIN PGP MESSAGE-----
+ hQGMA9TqgBq6RQVRAQv/UouNaHfxkJ5PwXLvda97Fgj/2ew2VXPAlAnLvoGvTsb2
+ U4GXcaE7c4mYf7wSKF9k/F0FZTUEnd3CRji/OqjrNyvj5zI/9KGRABCKvzjsx+ZG
+ JolVnDifHl78Mor1CUPQ4JXasHKbVSlNLMGgDHIsvpeC7f7pIi8YDUDIa3/zXhFK
+ jcKzz4nlrW1Ph8zukmQk49Xvv6+DFj2NTptOB3U6mh79RCdnyCSRHxA3f0X00Pi5
+ g0p5x46S5E04uC2wXrZv8i/gyQbLHxwjmdbLq+P1Peu4/i9eSZZOpx0mc1KJ2mjr
+ oKRvgnUFz3xuYrSNzjC1vM01UbuSytlwx+S3J7VVLPSZRso1sbgv2+ylUOAHS+gZ
+ 64uL0j/BZrF4wZI8y8zr0nJ6cZLiiF3LeXhfcuWJJ7+5p1OBEvfO+sWorLahIZTw
+ pogYPDpz4rGnrJRKBkNsVlYuUG8aNerIfhEBr6n//VJtt7QXTEXraLCTt4a6z/Fl
+ R6YSeNCKWQlURrTfm4Kv0lwBzMTLUb+Fg3HO8ShhiE9/2dKTSJkRJMVXRDp22Fm1
+ vO/wMFUjg6Dkrj1LVqQ9zcXc5QElgc4mF/V7SazacbQ7/g67tVtUrTit9LXgR9A0
+ k7wU5iT5oWLJtWwpkA==
+ =Il2p
+ -----END PGP MESSAGE-----
+ fp: C70833A85193F72C2D72CB9DBC109AFC69E0185D
+ encrypted_regex: password
+ version: 3.5.0
+```
+You cannot run the application locally, as it needs to run in the pipeline in order to use our environment variables to connect.
+
+## Create pipeline
+
+The pipeline contains four stages:
+
+- A stage for cloning
+- A stage for importing the private/public keypair
+- A stage for decrypting the credentials file
+- A stage for packaging our jar and running unit tests
+
+{% include image.html
+lightbox="true"
+file="/images/examples/secrets/mozilla-sops-pipeline.png"
+url="/images/examples/secrets/mozilla-sops-pipeline.png"
+alt="Codefresh UI Pipeline View"
+caption="Codefresh UI Pipeline View"
+max-width="90%"
+%}
+
+First, you need to add a pipeline variable, `PRIV_KEY`, for your private key. You can do that in the UI by navigating to the in-line YAML editor and to the right-hand side, you will find the **Variables** tab:
+
+{% include image.html
+lightbox="true"
+file="/images/examples/secrets/mozilla-sops-pipeline-vars.png"
+url="/images/examples/secrets/mozilla-sops-pipeline-vars.png"
+alt="Mozilla SOPS Pipeline Variables"
+caption="Pipeline Variables"
+max-width="90%"
+%}
+
+
+
+Here is the entire pipeline:
+
+`codefresh.yaml`
+{% highlight yaml %}
+{% raw %}
+# More examples of Codefresh YAML can be found at
+# https://codefresh.io/docs/docs/example-catalog/ci-examples/
+
+version: "1.0"
+# Stages can help you organize your steps in stages
+stages:
+ - "clone"
+ - "import"
+ - "decrypt"
+ - "package"
+
+steps:
+ clone:
+ title: "Cloning repository..."
+ type: "git-clone"
+ stage: "clone"
+ arguments:
+ repo: "codefresh-contrib/mozilla-sops-app"
+ revision: "master"
+
+ import_keys:
+ title: "Importing gpg keys..."
+ type: "freestyle"
+ stage: "import"
+ working_directory: '${{clone}}'
+ arguments:
+ image: "vladgh/gpg"
+ commands:
+ - gpg --import public.key
+ - echo -e "${{PRIV_KEY}}" > private.key
+ - gpg --allow-secret-key-import --import private.key
+
+ decrypt_password:
+ title: "Decrypting password..."
+ type: "freestyle"
+ working_directory: "${{clone}}"
+ stage: "decrypt"
+ arguments:
+ image: "mozilla/sops"
+ commands:
+ - cp -r /codefresh/volume/.gnupg /root/.gnupg
+ - cf_export password=$(sops --decrypt --extract '["password"]' credentials.yaml)
+
+ package_jar:
+ title: "Packaging jar and running unit tests..."
+ working_directory: ${{clone}}
+ stage: "package"
+ arguments:
+ image: "maven:3.5.2-jdk-8-alpine"
+ commands:
+ - mvn -Dmaven.repo.local=/codefresh/volume/m2_repository -Dserver.host=my-redis-db-host clean package
+ services:
+ composition:
+ my-redis-db-host:
+ image: 'redis:4-alpine'
+ command: 'redis-server --requirepass $password'
+ ports:
+ - 6379
+{% endraw %}
+{% endhighlight %}
+
+This pipeline does the following:
+
+1. Clones the main repository through a [git-clone step]({{site.baseurl}}/docs/pipelines/steps/git-clone/).
+2. Uses a GPG image and imports the public and private key pair through a [freestyle step]({{site.baseurl}}/docs/pipelines/steps/freestyle/).
+3. Decrypts the credentials file through a different freestyle step. At this step, SOPS looks for the .gnupg directory (where the keyring is stored) under /root. We need to copy it from the [Codefresh Volume]({{site.baseurl}}/docs/pipelines/steps/freestyle/#custom-volumes), as /root is not saved between containers.
+4. The last step, `package_jar`, does a few special things to take note of:
+ - Spins up a [Service Container]({{site.baseurl}}/docs/pipelines/service-containers/) running Redis on port 6379 , and sets the password to the database using our exported environment variable
+ - Sets `maven.repo.local` to cache Maven dependencies into the local codefresh volume to [speed up builds]({{site.baseurl}}/docs/example-catalog/ci-examples/spring-boot-2/#caching-the-maven-dependencies)
+ - Runs unit tests and packages the jar. Note how you can directly refer to the service container's name (`my-redis-db-host`) when we set `server.host`
+
+## Related articles
+[CI pipeline examples]({{site.baseurl}}/docs/example-catalog/examples/#ci-examples)
+[Codefresh YAML for pipeline definitions]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/)
+[Vault secrets in pipelines]({{site.baseurl}}/docs/example-catalog/ci-examples/vault-secrets-in-the-pipeline/)
+
diff --git a/_docs/learn-by-example/python/django.md b/_docs/example-catalog/ci-examples/django.md
similarity index 75%
rename from _docs/learn-by-example/python/django.md
rename to _docs/example-catalog/ci-examples/django.md
index 92ba13757..8adffae20 100644
--- a/_docs/learn-by-example/python/django.md
+++ b/_docs/example-catalog/ci-examples/django.md
@@ -2,9 +2,10 @@
title: "Python Django example"
description: "Create Docker images for Python applications"
excerpt: ""
-group: learn-by-example
-sub_group: python
+group: example-catalog
+sub_group: ci-examples
redirect_from:
+ - /docs/learn-by-example/python/django/
- /docs/django/
- /docs/python/django/
toc: true
@@ -13,7 +14,7 @@ Codefresh can work with Python projects using any of the popular frameworks. In
## The example Django project
-You can see the example project at [https://github.com/codefreshdemo/cf-example-python-django](https://github.com/codefreshdemo/cf-example-python-django). The repository contains a Django starter project with the following commands:
+You can see the example project at [https://github.com/codefreshdemo/cf-example-python-django](https://github.com/codefreshdemo/cf-example-python-django){:target="\_blank"}. The repository contains a Django starter project with the following commands:
* `pip install -r requirements.txt` install dependencies.
* `python -m unittest composeexample.utils` runs unit tests.
@@ -67,14 +68,14 @@ Creating a CI/CD pipeline for Django is very easy if you already have the Docker
{% include image.html
lightbox="true"
-file="/images/learn-by-example/python/python-build-test.png"
-url="/images/learn-by-example/python/python-build-test.png"
+file="/images/examples/python/python-build-test.png"
+url="/images/examples/python/python-build-test.png"
alt="Creating a Docker image for Python"
caption="Creating a Docker image for Python"
max-width="80%"
%}
-Here is the [full pipeline](https://github.com/codefresh-contrib/gradle-sample-app/blob/master/codefresh.yml) that creates the Docker image after checking out the code.
+Here is the [full pipeline](https://github.com/codefresh-contrib/gradle-sample-app/blob/master/codefresh.yml){:target="\_blank"} that creates the Docker image after checking out the code.
`codefresh.yml`
{% highlight yaml %}
@@ -121,14 +122,14 @@ Sometimes if you have a complex application you might want to run integration te
{% include image.html
lightbox="true"
-file="/images/learn-by-example/python/python-test-build.png"
-url="/images/learn-by-example/python/python-test-build.png"
+file="/images/examples/python/python-test-build.png"
+url="/images/examples/python/python-test-build.png"
alt="Building the image after tests have run"
caption="Building the image after tests have run"
max-width="80%"
%}
-Here is the [full pipeline](https://github.com/codefreshdemo/cf-example-python-django/blob/master/codefresh-build-after-test.yml) builds the docker image after tests have already executed.
+Here is the [full pipeline](https://github.com/codefreshdemo/cf-example-python-django/blob/master/codefresh-build-after-test.yml){:target="\_blank"} builds the docker image after tests have already executed.
`codefresh.yml`
{% highlight yaml %}
@@ -164,12 +165,11 @@ steps:
{% endraw %}
{% endhighlight %}
-Codefresh is smart enough that [caches automatically]({{site.baseurl}}/docs/configure-ci-cd-pipeline/pipeline-caching/) for us the workspace of a build (`/codefresh/volume`). This works great for build tools that keep their cache in the project folder, but not for pip which keeps its cache externally (e.g. `~/.cache/pip`). By changing the location of the Pip cache on the project folder (the `pip-cache` name is arbitrary) we make sure that Codefresh will cache automatically the Pip libraries resulting in much faster builds.
+Codefresh is smart enough that [caches automatically]({{site.baseurl}}/docs/pipelines/pipeline-caching/) for us the workspace of a build (`/codefresh/volume`). This works great for build tools that keep their cache in the project folder, but not for pip which keeps its cache externally (e.g. `~/.cache/pip`). By changing the location of the Pip cache on the project folder (the `pip-cache` name is arbitrary) we make sure that Codefresh will cache automatically the Pip libraries resulting in much faster builds.
-## What to read next
-
-* [Python examples]({{site.baseurl}}/docs/learn-by-example/python/)
-* [Codefresh YAML]({{site.baseurl}}/docs/codefresh-yaml/what-is-the-codefresh-yaml/)
-* [Pipeline steps]({{site.baseurl}}/docs/codefresh-yaml/steps/)
-* [Creating pipelines]({{site.baseurl}}/docs/configure-ci-cd-pipeline/pipelines/)
-* [How pipelines work]({{site.baseurl}}/docs/configure-ci-cd-pipeline/introduction-to-codefresh-pipelines/)
\ No newline at end of file
+## Related articles
+[Python examples]({{site.baseurl}}/docs/example-catalog/ci-examples/python/)
+[Codefresh YAML for pipeline definitions]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/)
+[Steps in pipelines]({{site.baseurl}}/docs/pipelines/steps/)
+[Creating pipelines]({{site.baseurl}}/docs/pipelines/pipelines/)
+[How Codefresh pipelines work]({{site.baseurl}}/docs/pipelines/introduction-to-codefresh-pipelines/)
\ No newline at end of file
diff --git a/_docs/example-catalog/ci-examples/dotnet.md b/_docs/example-catalog/ci-examples/dotnet.md
new file mode 100644
index 000000000..64f724e0d
--- /dev/null
+++ b/_docs/example-catalog/ci-examples/dotnet.md
@@ -0,0 +1,117 @@
+---
+title: "C# on .NET Core"
+description: "How to build a C# project in Codefresh"
+group: example-catalog
+sub_group: ci-examples
+redirect_from:
+ - /docs/learn-by-example/dotnet/
+toc: true
+---
+
+Codefresh can work with any .NET core application very easily as there are official [Docker images from Microsoft](https://hub.docker.com/_/microsoft-dotnet-core){:target="\_blank"}.
+
+## The example C# project
+
+You can see the example project at [https://github.com/dotnet-architecture/eShopOnWeb](https://github.com/dotnet-architecture/eShopOnWeb){:target="\_blank"}. The repository contains a C# Web project with 3 kinds of tests. It has different tags for each version of .NET Core and has
+
+* a `docker-compose.yml` file for local development
+* a `tests` directory with all types of tests
+* a Dockerfile at `/src/Web`
+
+There are also previous releases at [https://github.com/dotnet-architecture/eShopOnWeb/releases](https://github.com/dotnet-architecture/eShopOnWeb/releases){:target="\_blank"}.
+
+### Create a CI pipeline for C# applications
+
+Creating a CI/CD pipeline for C# is very easy, because Codefresh can run any SDK image version that you wish.
+
+{% include image.html
+lightbox="true"
+file="/images/examples/dotnet/dotnetcore-pipeline.png"
+url="/images/examples/dotnet/dotnetcore-pipeline.png"
+alt="Compiling a C# application in a pipeline"
+caption="Compiling a C# application in a pipeline"
+max-width="80%"
+%}
+
+Here is the full pipeline that compiles the application after checking out the code.
+
+ `codefresh.yml`
+{% highlight yaml %}
+{% raw %}
+version: '1.0'
+stages:
+ - checkout
+ - test
+ - build
+steps:
+ main_clone:
+ title: Cloning main repository...
+ stage: checkout
+ type: git-clone
+ repo: 'dotnet-architecture/eShopOnWeb'
+ revision: 'netcore3.0'
+ git: github-1
+ my_unit_tests:
+ title: Unit tests
+ stage: test
+ image: mcr.microsoft.com/dotnet/core/sdk:3.0
+ working_directory: './tests/UnitTests/'
+ commands:
+ - dotnet test
+ my_integration_tests:
+ title: Integration tests
+ stage: test
+ image: mcr.microsoft.com/dotnet/core/sdk:3.0
+ working_directory: './tests/IntegrationTests/'
+ commands:
+ - dotnet test
+ my_functional_tests:
+ title: Fuctional tests
+ stage: test
+ image: mcr.microsoft.com/dotnet/core/sdk:3.0
+ working_directory: './tests/FunctionalTests/'
+ commands:
+ - dotnet test
+ my_app_docker_image:
+ title: Building Docker Image
+ type: build
+ stage: build
+ image_name: dotnetcore-eshop
+ working_directory: ./
+ tag: latest
+ dockerfile: src/Web/Dockerfile
+{% endraw %}
+{% endhighlight %}
+
+This pipeline:
+
+1. clones the source code
+1. Uses the official `mcr.microsoft.com/dotnet/core/sdk:3.0` image to run unit/integration/functional tests in 3 different folders
+1. Builds the application docker image using the root folder as Docker context but with the Dockerfile located at `./src/Web`
+
+You can see the resulting image in the [image dashboard]({{site.baseurl}}/docs/docker-registries/working-with-docker-registries/#viewing-docker-images):
+
+{% include image.html
+lightbox="true"
+file="/images/examples/dotnet/dotnetcore-image.png"
+url="/images/examples/dotnet/dotnetcore-image.png"
+alt="Building a .NET core docker image"
+caption="Building a .NET core docker image"
+max-width="80%"
+%}
+
+
+
+
+## Related articles
+[C/C++ examples]({{site.baseurl}}/docs/learn-by-example/cc/)
+[Codefresh YAML for pipeline definitions]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/)
+[Steps in pipelines]({{site.baseurl}}/docs/pipelines/steps/)
+[Creating pipelines]({{site.baseurl}}/docs/pipelines/pipelines/)
+[How Codefresh pipelines work]({{site.baseurl}}/docs/pipelines/introduction-to-codefresh-pipelines/)
+
+
+
+
+
+
diff --git a/_docs/example-catalog/ci-examples/fan-in-fan-out.md b/_docs/example-catalog/ci-examples/fan-in-fan-out.md
new file mode 100644
index 000000000..5a6b6cea2
--- /dev/null
+++ b/_docs/example-catalog/ci-examples/fan-in-fan-out.md
@@ -0,0 +1,206 @@
+---
+title: "Fan-out-fan-in pipeline"
+description: "Use parallel mode to fan-in and fan-out your step dependencies"
+group: example-catalog
+sub_group: ci-examples
+redirect_from:
+ - /docs/yaml-examples/examples/fan-in-fan-out/
+toc: true
+---
+
+In pipelines, the concept of fan-in/fan-out is depicted in the diagram below. This pipeline offers parallel sub-flows within the same pipeline. Fan-out refers to spreading a task to multiple destinations in parallel, and fan-in is the opposite, where we spread multiple tasks to the same destination.
+
+{% include image.html
+lightbox="true"
+file="/images/examples/unit-tests/parallel-pipeline-examples.png"
+url="/images/examples/unit-tests/parallel-pipeline-examples.png"
+alt="parallel pipeline diagraam"
+caption="Parallel Mode Diagram"
+max-width="100%"
+%}
+
+As you can see in the diagram, Step1 fans out to Step2 and Step4 (which run in parallel), while Step3 and Step4 fan-in to Step5.
+
+You can achieve parallelism in your Codefresh pipelines by using the following:
+
+- Simple parallel jobs ([inserting parallel steps into a sequential pipeline]({{site.baseurl}}/docs/pipelines/advanced-workflows/#inserting-parallel-steps-in-a-sequential-pipeline))
+- [Full parallel mode]({{site.baseurl}}/docs/pipelines/advanced-workflows/#parallel-pipeline-mode)
+- Fan-out/fan-in parallel pipelines, as described in this article
+
+## Prerequisites
+
+- A [Codefresh account]({{site.baseurl}}/docs/administration/account-user-management/create-codefresh-account/)
+
+## Example project
+
+You can find the example Spring boot application on [GitHub](https://github.com/codefresh-contrib/fan-out-fan-in-sample-app.git){:target="\_blank"}. It is a simple Hello World application with several different types of tests we will use to run using Codefresh's parallel mode.
+
+## Create the pipeline
+
+Our pipeline will have five stages: setup, start, web-tests, smoke, and end:
+
+{% include image.html
+lightbox="true"
+file="/images/examples/unit-tests/fan-in-fan-out-pipeline.png"
+url="/images/examples/unit-tests/fan-in-fan-out-pipeline.png"
+alt="fan-in-fan-out UI pipeline view"
+caption="Codefresh UI Pipeline View"
+max-width="100%"
+%}
+
+You should be able to copy and paste this YAML in the in-line editor in the Codefresh UI. It will automatically clone the project for you.
+
+`codefresh.yml`
+{% highlight yaml %}
+{% raw %}
+version: "1.0"
+mode: parallel
+stages:
+- setup
+- start
+- web-tests
+- smoke
+- end
+steps:
+ Clone:
+ title: Cloning main repository...
+ stage: setup
+ type: git-clone
+ arguments:
+ repo: codefresh-contrib/fan-out-fan-in-sample-app
+ git: github
+ revision: master
+ Build_image:
+ title: Building Docker Image...
+ type: build
+ stage: setup
+ working_directory: ${{Clone}}
+ arguments:
+ image_name: spring-backend
+ tag: latest
+ dockerfile: Dockerfile
+ when:
+ steps:
+ - name: Clone
+ on:
+ - success
+ Step1:
+ title: Running unit tests...
+ stage: start
+ working_directory: ${{Clone}}/complete
+ arguments:
+ image: maven:3.5.2-jdk-8-alpine
+ commands:
+ - mvn -Dmaven.repo.local=/codefresh/volume/m2_repository -Dgroups="unit" test
+ when:
+ steps:
+ - name: Build_image
+ on:
+ - success
+ services:
+ composition:
+ spring_backend:
+ image: ${{Build_image}}
+ ports:
+ - 8080
+ Step2:
+ title: Running web mock test...
+ stage: web-tests
+ working_directory: ${{Clone}}/complete
+ arguments:
+ image: maven:3.5.2-jdk-8-alpine
+ commands:
+ - mvn -Dmaven.repo.local=/codefresh/volume/m2_repository -Dgroups="web-mock" test
+ when:
+ steps:
+ - name: Step1
+ on:
+ - success
+ services:
+ composition:
+ spring_backend:
+ image: ${{Build_image}}
+ ports:
+ - 8080
+ Step3:
+ title: Running smoke test...
+ stage: smoke
+ working_directory: ${{Clone}}/complete
+ arguments:
+ image: maven:3.5.2-jdk-8-alpine
+ commands:
+ - mvn -Dmaven.repo.local=/codefresh/volume/m2_repository -Dgroups="smoke" test
+ when:
+ steps:
+ - name: Step2
+ on:
+ - success
+ services:
+ composition:
+ spring_backend:
+ image: ${{Build_image}}
+ ports:
+ - 8080
+ Step4:
+ title: Running web layer tests...
+ stage: web-tests
+ working_directory: ${{Clone}}/complete
+ arguments:
+ image: maven:3.5.2-jdk-8-alpine
+ commands:
+ - mvn -Dmaven.repo.local=/codefresh/volume/m2_repository -Dgroups="web-layer" test
+ when:
+ steps:
+ - name: Step1
+ on:
+ - success
+ services:
+ composition:
+ spring_backend:
+ image: ${{Build_image}}
+ ports:
+ - 8080
+ Step5:
+ title: Running integration tests...
+ stage: end
+ working_directory: ${{Clone}}/complete
+ arguments:
+ image: maven:3.5.2-jdk-8-alpine
+ commands:
+ - mvn -Dmaven.repo.local=/codefresh/volume/m2_repository -Dgroups="integration" test
+ when:
+ steps:
+ - name: Step3
+ on:
+ - success
+ - name: Step4
+ on:
+ - success
+ services:
+ composition:
+ spring_backend:
+ image: ${{Build_image}}
+ ports:
+ - 8080
+{% endraw %}
+{% endhighlight %}
+
+>Note the special use of `mode: parallel` declared at the root of our yaml. This syntax makes the pipeline use the full parallel mode.
+The order of your build steps doesn't matter in this case, each step is executed according to its [condition]({{site.baseurl}}/docs/pipelines/conditional-execution-of-steps/).
+
+- Step1 (unit tests) fans out to Step2 and Step4 (web tests), which run in parallel
+- Step3 (smoke tests) does not execute until Step2 is completed
+- Step3 and Step4 fan in to the final step, Step5 (integration tests)
+
+This pipeline does the following:
+
+1. Clones the main repository through a [Git-clone step]({{site.baseurl}}/docs/pipelines/steps/git-clone/).
+2. Builds the cloned source code into a Docker image through a [build step]({{site.baseurl}}/docs/pipelines/steps/build/).
+3. Runs [freestyle steps]({{site.baseurl}}/docs/pipelines/steps/freestyle/) that:
+ - Run unit tests according to their respective @Tags
+ - Use the image built in the second step as a [service container]({{site.baseurl}}/docs/pipelines/service-containers/)
+
+## Related articles
+[CI pipeline examples]({{site.baseurl}}/docs/example-catalog/examples/#ci-examples)
+[Parallel pipeline mode]({{site.baseurl}}/docs/pipelines/advanced-workflows/#parallel-pipeline-mode)
+
diff --git a/_docs/learn-by-example/general.md b/_docs/example-catalog/ci-examples/general.md
similarity index 82%
rename from _docs/learn-by-example/general.md
rename to _docs/example-catalog/ci-examples/general.md
index 20d5bd508..5e583f6b8 100644
--- a/_docs/learn-by-example/general.md
+++ b/_docs/example-catalog/ci-examples/general.md
@@ -1,7 +1,7 @@
---
title: "General"
description: ""
-group: learn-by-example
+group: example-catalog
redirect_from:
- /docs/learn-by-example/general/
toc: true
@@ -13,4 +13,3 @@ links not available in base documentation
- [How to run composition using cf-cli](doc:how-to-run-composition-using-cf-cli-1)
- [How to spin up image using cf-cli](doc:how-to-spin-up-image-using-cf-cli)
{% endcomment %}
-- [Selenium test]({{site.baseurl}}/docs/learn-by-example/general/selenium-test/)
diff --git a/_docs/example-catalog/ci-examples/get-short-sha-id-and-use-it-in-a-ci-process.md b/_docs/example-catalog/ci-examples/get-short-sha-id-and-use-it-in-a-ci-process.md
new file mode 100644
index 000000000..d8c1057be
--- /dev/null
+++ b/_docs/example-catalog/ci-examples/get-short-sha-id-and-use-it-in-a-ci-process.md
@@ -0,0 +1,78 @@
+---
+title: "Use Git Hash in CI"
+description: "Get short SHA ID and use it in a CI Process"
+group: example-catalog
+sub_group: ci-examples
+redirect_from:
+ - /docs/yaml-examples/examples/get-short-sha-id-and-use-it-in-a-ci-process/
+ - /docs/how-to-guides/
+ - /docs/how-get-first-8-digits-of-sha/
+toc: true
+old_url: /docs/how-get-first-8-digits-of-sha
+---
+
+## Get the short SHA ID
+Add the following variable to your script:
+
+{% highlight text %}
+{% raw %}
+${{CF_SHORT_REVISION}}
+{% endraw %}
+{% endhighlight %}
+
+
+## Use the SHA ID in a tag
+
+
+{% highlight text %}
+{% raw %}
+tag: ${{CF_SHORT_REVISION}}
+{% endraw %}
+{% endhighlight %}
+
+
+## YAML example
+
+{% highlight yaml %}
+{% raw %}
+step-name:
+ type: build
+ description: Free text description
+ working-directory: ${{clone-step-name}}
+ dockerfile: path/to/Dockerfile
+ image-name: owner/new-image-name
+ tag: ${{CF_SHORT_REVISION}}
+ build-arguments:
+ - key=value
+ fail-fast: false
+{% endraw %}
+{% endhighlight %}
+
+## Result in [hub.docker](https://hub.docker.com){:target="_blank"}
+
+{% include image.html
+lightbox="true"
+file="/images/examples/git/sha-id-docker-hub.png"
+url="/images/examples/git/sha-id-docker-hub.png"
+alt="SHA ID in Docker Hub"
+caption="SHA ID in Docker Hub"
+max-width="60%"
+%}
+
+## Result in Codefresh
+
+{% include image.html
+lightbox="true"
+file="/images/examples/git/sha-id-codefresh.png"
+url="/images/examples/git/sha-id-codefresh.png"
+caption="SHA ID in Codefresh"
+alt="SHA ID in Codefresh"
+max-width="60%"
+%}
+
+
+## Related articles
+[CI/CD pipeline examples]({{site.baseurl}}/docs/example-catalog/examples/#ci-examples)
+[Codefresh YAML for pipeline definitions]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/)
+[Creating pipelines]({{site.baseurl}}/docs/pipelines/pipelines/)
+[How Codefresh pipelines work]({{site.baseurl}}/docs/pipelines/introduction-to-codefresh-pipelines/)
\ No newline at end of file
diff --git a/_docs/example-catalog/ci-examples/git-checkout-custom.md b/_docs/example-catalog/ci-examples/git-checkout-custom.md
new file mode 100644
index 000000000..f611b32a5
--- /dev/null
+++ b/_docs/example-catalog/ci-examples/git-checkout-custom.md
@@ -0,0 +1,106 @@
+---
+title: "Using custom Git commands"
+description: "Manually clone Git repositories"
+group: example-catalog
+sub_group: ci-examples
+redirect_from:
+ - /docs/yaml-examples/examples/git-checkout-custom/
+ - /docs/git-clone-private-repository-using-freestyle-step/
+ - /docs/example-catalog/ci-examples/git-clone-private-repository-using-freestyle-step/
+toc: true
+---
+
+>Manually running Git commands is an advanced technique. For most use cases you should use the [native Git checkout]({{site.baseurl}}/docs/example-catalog/ci-examples/git-checkout/) offered by Codefresh.
+
+For complex cloning, you can still use custom clone commands in a freestyle step. In this case,
+you lose the native Codefresh integration such as Git authentication and automatic workdir setup. Use custom clone commands only as a last resort.
+
+
+## Cloning with the Git executable
+
+It is very easy to run custom Git commands in a [freestyle step]({{site.baseurl}}/docs/pipelines/steps/freestyle/). Pass any parameters to the Git clone step as you would pass them on your local workstation.
+
+{% highlight yaml %}
+{% raw %}
+version: '1.0'
+steps:
+ myCustomClone:
+ title: Performing swallow clone
+ image: alpine/git:latest
+ commands:
+ - rm -rf ruby-on-rails-sample-app
+ - git clone --depth 1 https://github.com/codefresh-contrib/ruby-on-rails-sample-app.git
+ PrintFileList:
+ title: 'Listing files'
+ image: alpine:latest
+ working_directory: './ruby-on-rails-sample-app'
+ commands:
+ - 'ls -l'
+{% endraw %}
+{% endhighlight %}
+
+Notice the `rm` command before the clone step. This makes sure that every time the pipeline runs, the `git clone` step is implemented in an empty directory. Otherwise the `git clone` command will fail (Git will refuse to clone on an existing directory).
+
+You can enter your own Git username/password or [reuse the credentials]({{site.baseurl}}/docs/pipelines/steps/git-clone/#reuse-a-git-token-from-codefresh-integrations) from the Codefresh integration.
+
+## Manually running Git commands
+
+Once you understand that you can manually run Git commands in Codefresh pipelines, it is easy to see that any Git workflow is possible.
+Here is an example where an application is packaged in a Docker container, after merging `master` to a specific branch.
+
+{% highlight yaml %}
+{% raw %}
+version: '1.0'
+steps:
+ myCustomClone:
+ title: Performing swallow clone
+ image: alpine/git:latest
+ commands:
+ - rm -rf example_nodejs_postgres
+ - git clone https://github.com/kostis-codefresh/example_nodejs_postgres
+ - cd example_nodejs_postgres
+ - git checkout experiment1
+ - git merge master
+ - git status
+ myDockerImage:
+ title: 'BuildingDockerImage'
+ type: build
+ dockerfile: Dockerfile
+ working_directory: './example_nodejs_postgres'
+ image_name: my-app-image
+ tag: from-master-branch
+{% endraw %}
+{% endhighlight %}
+
+If there are any errors with the merge, the pipeline fails automatically. Codefresh automatically stops any pipeline that shows an error in a step.
+
+## Other forms of cloning
+
+There is nothing special about running Git it in a freestyle step. In fact, you can check out code with any other command that you would run locally in your terminal.
+
+Here is an example with Golang.
+
+{% highlight yaml %}
+{% raw %}
+version: '1.0'
+steps:
+ myCustomClone:
+ title: Download example
+ image: golang:1.11-alpine
+ commands:
+ - apk add --no-cache git
+ - go get github.com/golang/example/hello
+{% endraw %}
+{% endhighlight %}
+
+If you run this pipeline you will see git used as part of the `go get` mechanism.
+
+For more examples, such as using SSH keys and working with Git submodules, see the [Git-clone]({{site.baseurl}}/docs/pipelines/steps/git-clone/) step.
+
+
+## Related articles
+[CI/CD pipeline examples]({{site.baseurl}}/docs/example-catalog/examples/#ci-examples)
+[Native Git checkout]({{site.baseurl}}/docs/example-catalog/ci-examples/git-checkout/)
+[Native Git integration]({{site.baseurl}}/docs/integrations/git-providers/)
+[Steps in pipelines]({{site.baseurl}}/docs/pipelines/steps/)
+
diff --git a/_docs/example-catalog/ci-examples/git-checkout.md b/_docs/example-catalog/ci-examples/git-checkout.md
new file mode 100644
index 000000000..e0336e0a1
--- /dev/null
+++ b/_docs/example-catalog/ci-examples/git-checkout.md
@@ -0,0 +1,204 @@
+---
+title: "Check out Git repositories"
+description: "Use the Codefresh native GIT integration"
+group: example-catalog
+sub_group: ci-examples
+redirect_from:
+ - /docs/yaml-examples/examples/git-checkout/
+toc: true
+---
+
+Codefresh has native support for Git repositories and Git triggers. First you need to set up a [Git integration]({{site.baseurl}}/docs/integrations/git-providers/) (your administrator might also have done this for you already).
+
+{% include image.html
+lightbox="true"
+file="/images/integrations/git/git-integrations.png"
+url="/images/integrations/git/git-integrations.png"
+alt="GIT integrations"
+caption="GIT integrations"
+max-width="70%"
+%}
+
+You can add a new integration for any cloud provider or even [on-premises]({{site.baseurl}}/docs/installation/behind-the-firewall/) ones. By default you will also have a provider set up if you used one for Codefresh signup (GitHub, GitLab or Bitbucket).
+
+For each Git Integration, make sure that you note down its name, as you will use in your pipeline inside a [git-clone]({{site.baseurl}}/docs/pipelines/steps/git-clone/) step.
+
+
+## Cloning a specific repository
+
+The simplest way to clone using your git provider is by specifying the exact repository details.
+Here is a pipeline that clones a git repository and creates a Docker image from a Dockerfile:
+
+
+`codefresh.yml`
+{% highlight yaml %}
+{% raw %}
+version: '1.0'
+steps:
+ main_clone:
+ title: 'Cloning main repository...'
+ type: git-clone
+ repo: kostis-codefresh/example_nodejs_postgres
+ revision: master
+ git: github-1
+ myDockerImage:
+ title: 'Building My Docker Image'
+ type: build
+ dockerfile: Dockerfile
+ image_name: my-app-image
+ tag: from-master-branch
+{% endraw %}
+{% endhighlight %}
+
+This syntax is very simple to use, but it has the disadvantage that ties your pipeline to a specific repository. This makes
+the pipeline impossible to re-use among different micro-services (that are built in a similar manner).
+
+## Cloning the triggered repository (recommended)
+
+The proper way to use git-clone steps is to make them trigger specific. Instead of hard-coding the git repository that is checked-out, it is best to check out the same one that [triggered the pipeline]({{site.baseurl}}/docs/pipelines/triggers/git-triggers/). This is what you want in most scenarios anyway.
+
+This can be achieved by using Codefresh [variables]({{site.baseurl}}/docs/pipelines/variables/) to refer to the trigger.
+Here is the same pipeline as before, written in a generic way:
+
+`codefresh.yml`
+{% highlight yaml %}
+{% raw %}
+version: '1.0'
+steps:
+ main_clone:
+ title: 'Cloning main repository...'
+ type: git-clone
+ repo: '${{CF_REPO_OWNER}}/${{CF_REPO_NAME}}'
+ revision: '${{CF_REVISION}}'
+ git: github-1
+ myDockerImage:
+ title: 'Building My Docker Image'
+ type: build
+ dockerfile: Dockerfile
+ image_name: my-app-image
+ tag: ${{CF_BRANCH_TAG_NORMALIZED}}
+{% endraw %}
+{% endhighlight %}
+
+The big advantage of this pipeline is that it can be reused for *ALL* your projects that follow the same pattern of having a Dockerfile in the root of the git repository.
+
+{% include image.html
+lightbox="true"
+file="/images/examples/checkout/add-new-microservice.png"
+url="/images/examples/checkout/add-new-microservice.png"
+alt="Reusing a pipeline between microservices"
+caption="Reusing a pipeline between microservices"
+max-width="50%"
+%}
+
+Thus you can have a single pipeline and when you want to enable it for a new micro-service you can simply add a new [Git trigger]({{site.baseurl}}/docs/pipelines/triggers/git-triggers/) for it.
+
+You still run the pipeline manually if you wish. In this case you will be asked which trigger you want to "simulate" so that the variable pipelines are correctly replaced by Codefresh.
+
+{% include image.html
+lightbox="true"
+file="/images/examples/checkout/simulate-trigger.png"
+url="/images/examples/checkout/simulate-trigger.png"
+alt="Simulating a GIT trigger"
+caption="Simulating a GIT trigger"
+max-width="50%"
+%}
+
+This is the recommended way of creating re-usable pipelines in Codefresh.
+
+## Cloning a repository with Codefresh Runner
+If you have the [Codefresh Runner]({{site.baseurl}}/docs/installation/codefresh-runner/) installed, you need to use
+the fully qualified path of the Git repository:
+
+`codefresh.yml`
+{% highlight yaml %}
+{% raw %}
+version: '1.0'
+steps:
+ main_clone:
+ title: 'Cloning main repository...'
+ type: git-clone
+ repo: https://github-internal.example.com/my-username/my-app
+ revision: '${{CF_REVISION}}'
+ git: my-internal-git-provider
+ PrintFileList:
+ title: 'Listing files'
+ image: alpine:latest
+ commands:
+ - 'ls -l'
+{% endraw %}
+{% endhighlight %}
+
+More details can be found in the [private Git instructions page]({{site.baseurl}}/docs/installation/behind-the-firewall/#checking-out-code-from-a-private-git-repository).
+
+
+## Working inside the cloned directory
+
+Normally each [pipeline step]({{site.baseurl}}/docs/pipelines/steps/) in Codefresh can be named as you want. Specifically, for the Git-clone step however the name `main_clone` is special.
+
+If you name your clone step as `main_clone`, Codefresh automatically changes the working directory for all the next (non Git-clone) pipeline steps, to be the same as the project that was just checked out. This only applies to [built-in]({{site.baseurl}}/docs/pipelines/steps/#built-in-steps) Codefresh steps and not [custom plugins]({{site.baseurl}}/docs/pipelines/steps/#creating-a-typed-codefresh-plugin).
+
+{% include
+image.html
+lightbox="true"
+file="/images/pipeline/introduction/checkout.png"
+url="/images/pipeline/introduction/checkout.png"
+alt="Checkout structure"
+caption="Checkout structure"
+max-width="50%"
+%}
+
+This is probably what you want anyway, so make sure that you name your Git-clone steps as `main_clone`. If you use any other name, then the working folder will be the parent of the checked-out project which is the [shared Codefresh volume]({{site.baseurl}}/docs/pipelines/introduction-to-codefresh-pipelines/#sharing-the-workspace-between-build-steps) at `/codefresh/volume`.
+
+If you have more then one clone step in a pipeline, it is recommended to define the working directory explicitly (see next example), instead
+of depending on the `main_clone` naming convention, which is best used in pipelines with a single clone step.
+
+## Cloning multiple repositories
+
+You can use as many clone steps as you want and at any position in the pipeline.
+
+Here is an example where two repositories are checked out and two docker images are then built.
+
+`codefresh.yml`
+{% highlight yaml %}
+{% raw %}
+version: '1.0'
+steps:
+ checkoutApp1:
+ title: 'Cloning first repository...'
+ type: git-clone
+ repo: kostis-codefresh/example_nodejs_postgres
+ revision: experiment1
+ git: github
+ myFirstDockerImage:
+ title: 'Building First Docker Image'
+ type: build
+ dockerfile: Dockerfile
+ image_name: my-nodejs-image
+ tag: from-develop-branch
+ working_directory: './example_nodejs_postgres'
+ checkoutApp2:
+ title: 'Cloning second repository...'
+ type: git-clone
+ repo: kostis-codefresh/trivial-go-web
+ revision: master
+ git: github
+ mySecondDockerImage:
+ title: 'Building Second Docker Image'
+ type: build
+ dockerfile: Dockerfile
+ working_directory: './trivial-go-web'
+ image_name: my-app-image
+ tag: from-master-branch
+{% endraw %}
+{% endhighlight %}
+
+Notice that in this case the git-clone steps are **not** named `main_clone` and therefore we specify exactly what is the working directory for each one.
+
+
+## Related articles
+[CI/CD pipeline examples]({{site.baseurl}}/docs/example-catalog/examples/#ci-examples)
+[Git integrations]({{site.baseurl}}/docs/integrations/git-providers/)
+[Custom git commands]({{site.baseurl}}/docs/example-catalog/ci-examples/git-checkout-custom/)
+[Steps in pipelines]({{site.baseurl}}/docs/pipelines/steps/)
+
diff --git a/_docs/example-catalog/ci-examples/golang-hello-world.md b/_docs/example-catalog/ci-examples/golang-hello-world.md
new file mode 100644
index 000000000..643ea4df3
--- /dev/null
+++ b/_docs/example-catalog/ci-examples/golang-hello-world.md
@@ -0,0 +1,270 @@
+---
+title: "Create a Docker image for GO"
+description: "Using Codefresh pipelines"
+group: example-catalog
+sub_group: ci-examples
+redirect_from:
+ - /docs/learn-by-example/golang/golang-hello-world/
+ - /docs/go/cf-example-golang-hello-world/
+toc: true
+---
+
+Codefresh can work with Go projects of any version using built-in modules or any other dependency mechanism.
+
+## The example golang project
+
+You can see the example project at [https://github.com/codefresh-contrib/golang-sample-app](https://github.com/codefresh-contrib/golang-sample-app){:target="\_blank"}. The repository contains a simple Golang web application including unit tests. There are 3 Dockerfiles available:
+
+* [Simple Dockerfile](https://github.com/codefresh-contrib/golang-sample-app/blob/master/Dockerfile){:target="\_blank"} (with old Go version that requires `GOPATH` building)
+* [Dockerfile with Go modules](https://github.com/codefresh-contrib/golang-sample-app/blob/master/Dockerfile.mod){:target="\_blank"} (optimized for Docker caching)
+* [Multi-stage Dockerfile](https://github.com/codefresh-contrib/golang-sample-app/blob/master/Dockerfile.multistage){:target="\_blank"} (with Go modules and unit tests)
+
+Let's see these workflows in order.
+
+## Simple Docker image pipeline
+
+The most [simple pipeline](https://github.com/codefresh-contrib/golang-sample-app/blob/master/codefresh.yml){:target="\_blank"} that you can create is just two steps:
+* A [clone step]({{site.baseurl}}/docs/pipelines/steps/git-clone/) to fetch the code
+* A [build step]({{site.baseurl}}/docs/pipelines/steps/build/) to create a Docker image
+
+ `codefresh.yml`
+{% highlight yaml %}
+{% raw %}
+version: '1.0'
+steps:
+ main_clone:
+ title: Cloning main repository...
+ type: git-clone
+ repo: 'codefresh-contrib/golang-sample-app'
+ revision: master
+ git: github
+ MyAppDockerImage:
+ title: Building Docker Image
+ type: build
+ image_name: my-golang-image
+ working_directory: ./
+ tag: full
+ dockerfile: Dockerfile
+{% endraw %}
+{% endhighlight %}
+
+Once you run this pipeline Codefresh will create a Docker image for the Golang application:
+
+{% include image.html
+lightbox="true"
+file="/images/examples/golang/golang-simple-pipeline.png"
+url="/images/examples/golang/golang-simple-pipeline.png"
+alt="Simple pipeline for Golang"
+caption="Simple pipeline for Golang"
+max-width="80%"
+%}
+
+The big advantage of this workflow is that the Dockerfile you use can define any Go version and dependency tool. As long as the Dockerfile is self-contained (i.e. it compiles GO on its own), the pipeline will work as expected.
+
+In the example application, the simple (unoptimized) Dockerfile has an old Go version that still requires `GOPATH` folders.
+
+`Dockerfile`
+{% highlight docker %}
+{% raw %}
+FROM golang:1.10
+
+# Set the Current Working Directory inside the container
+WORKDIR $GOPATH/src/github.com/codefresh-contrib/go-sample-app
+
+# Copy everything from the current directory to the PWD (Present Working Directory) inside the container
+COPY . .
+
+# Download all the dependencies
+RUN go get -d -v ./...
+
+# Install the package
+RUN go install -v ./...
+
+# This container exposes port 8080 to the outside world
+EXPOSE 8080
+
+# Run the executable
+CMD ["go-sample-app"]
+{% endraw %}
+{% endhighlight %}
+
+
+## Run unit tests as part of the pipeline
+
+If you want to run Go specific steps in your pipeline, you can use [freestyle]({{site.baseurl}}/docs/pipelines/steps/freestyle/) steps with any GO image that you want. If your GO application is using GO modules, this is even easier as you don't need to place the application into a specific GOPATH compliant directory first.
+
+This [pipeline](https://github.com/codefresh-contrib/golang-sample-app/blob/master/codefresh-gomod.yml){:target="\_blank"} is running unit tests as a separate step and then builds the docker image.
+
+ `codefresh.yml`
+{% highlight yaml %}
+{% raw %}
+version: '1.0'
+stages:
+ - checkout
+ - test
+ - build
+steps:
+ main_clone:
+ title: Cloning main repository...
+ type: git-clone
+ stage: checkout
+ repo: 'codefresh-contrib/golang-sample-app'
+ revision: master
+ git: github
+ MyUnitTests:
+ title: Unit test
+ stage: test
+ image: 'golang:1.12'
+ commands:
+ - go test -v
+ MyAppDockerImage:
+ title: Building Docker Image
+ type: build
+ stage: build
+ image_name: my-golang-image
+ working_directory: ./
+ tag: modules
+ dockerfile: Dockerfile.mod
+{% endraw %}
+{% endhighlight %}
+
+If the unit tests fail, then the docker image will never be created (Codefresh automatically stops a pipeline when there is an error).
+
+{% include image.html
+lightbox="true"
+file="/images/examples/golang/golang-ci-pipeline.png"
+url="/images/examples/golang/golang-ci-pipeline.png"
+alt="Golang pipeline with unit tests"
+caption="Golang pipeline with unit tests"
+max-width="80%"
+%}
+
+Notice that in this case we have added module support in the Go application. The new Dockerfile is the following:
+
+`Dockerfile`
+{% highlight docker %}
+{% raw %}
+FROM golang:1.12-alpine
+
+RUN apk add --no-cache git
+
+# Set the Current Working Directory inside the container
+WORKDIR /app/go-sample-app
+
+# We want to populate the module cache based on the go.{mod,sum} files.
+COPY go.mod .
+COPY go.sum .
+
+RUN go mod download
+
+COPY . .
+
+# Build the Go app
+RUN go build -o ./out/go-sample-app .
+
+
+# This container exposes port 8080 to the outside world
+EXPOSE 8080
+
+# Run the binary program produced by `go install`
+CMD ["./out/go-sample-app"]
+{% endraw %}
+{% endhighlight %}
+
+The Dockerfile will also automatically take advantage of the Codefresh distributed docker cache.
+
+
+
+## Create a multi-stage Docker image for GO
+
+Especially with Go applications, the recommended way to create Docker images is with [multi-stage builds](https://docs.docker.com/develop/develop-images/multistage-build/){:target="\_blank"}. This makes the resulting Docker image as compact as possible.
+
+You can also embed unit tests in the Docker creation process, which guarantee the correctness of image (integration tests are best kept in the pipeline).
+
+Here is the new Dockerfile:
+
+`Dockerfile`
+{% highlight docker %}
+{% raw %}
+FROM golang:1.12-alpine AS build_base
+
+RUN apk add --no-cache git
+
+# Set the Current Working Directory inside the container
+WORKDIR /tmp/go-sample-app
+
+# We want to populate the module cache based on the go.{mod,sum} files.
+COPY go.mod .
+COPY go.sum .
+
+RUN go mod download
+
+COPY . .
+
+# Unit tests
+RUN CGO_ENABLED=0 go test -v
+
+# Build the Go app
+RUN go build -o ./out/go-sample-app .
+
+# Start fresh from a smaller image
+FROM alpine:3.9
+RUN apk add ca-certificates
+
+COPY --from=build_base /tmp/go-sample-app/out/go-sample-app /app/go-sample-app
+
+# This container exposes port 8080 to the outside world
+EXPOSE 8080
+
+# Run the binary program produced by `go install`
+CMD ["/app/go-sample-app"]
+{% endraw %}
+{% endhighlight %}
+
+Codefresh has native support for multi-stage builds. The [pipeline](https://github.com/codefresh-contrib/golang-sample-app/blob/master/codefresh-multi-stage.yml){:target="\_blank"} is the same as the first one with just two steps.
+
+ `codefresh.yml`
+{% highlight yaml %}
+{% raw %}
+version: '1.0'
+steps:
+ main_clone:
+ title: Cloning main repository...
+ type: git-clone
+ repo: 'codefresh-contrib/golang-sample-app'
+ revision: master
+ git: github
+ MyAppDockerImage:
+ title: Building Docker Multi-stage Image
+ type: build
+ image_name: my-golang-image
+ working_directory: ./
+ tag: multi-stage
+ dockerfile: Dockerfile.multistage
+{% endraw %}
+{% endhighlight %}
+
+You should see a much smaller Docker image at the end.
+
+
+## Viewing Docker images
+
+If you look at your [Docker registry dashboard]({{site.baseurl}}/docs/docker-registries/working-with-docker-registries/#viewing-docker-images) created the advantages of the multi-stage build are very clear:
+
+{% include image.html
+lightbox="true"
+file="/images/examples/golang/golang-image-size.png"
+url="/images/examples/golang/golang-image-size.png"
+alt="Creating different Docker images"
+caption="Creating different Docker images"
+max-width="80%"
+%}
+
+We recommend using Go modules and multi-stage builds in your Go projects.
+
+## Related articles
+[Codefresh YAML for pipeline definitions]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/)
+[Steps in pipelines]({{site.baseurl}}/docs/pipelines/steps/)
+[Creating pipelines]({{site.baseurl}}/docs/pipelines/pipelines/)
+[How Codefresh pipelines work]({{site.baseurl}}/docs/pipelines/introduction-to-codefresh-pipelines/)
+
diff --git a/_docs/learn-by-example/golang.md b/_docs/example-catalog/ci-examples/golang.md
similarity index 89%
rename from _docs/learn-by-example/golang.md
rename to _docs/example-catalog/ci-examples/golang.md
index 71a0f869a..468e4eb87 100644
--- a/_docs/learn-by-example/golang.md
+++ b/_docs/example-catalog/ci-examples/golang.md
@@ -1,7 +1,8 @@
---
title: "Go"
description: "How to build Golang applications with Codefresh CI/CD pipelines"
-group: learn-by-example
+group: example-catalog
+sub_group: ci-examples
redirect_from:
- /docs/go/
- /docs/golang/
diff --git a/_docs/example-catalog/ci-examples/goreleaser.md b/_docs/example-catalog/ci-examples/goreleaser.md
new file mode 100644
index 000000000..892033765
--- /dev/null
+++ b/_docs/example-catalog/ci-examples/goreleaser.md
@@ -0,0 +1,120 @@
+---
+title: "Compile and release a Go application"
+description: "Using Codefresh pipelines"
+group: example-catalog
+sub_group: ci-examples
+redirect_from:
+ - /docs/learn-by-example/golang/goreleaser/
+toc: true
+---
+
+[Goreleaser](https://github.com/goreleaser/goreleaser){:target="\_blank"} is a helper utility that allows you to easily create the following for Go applications:
+
+* Binary packages for each OS/arch
+* Archives
+* GitHub releases
+* Docker images
+* Snap/RPM/deb/Homebrew
+
+
+Codefresh can also create Docker images on its own, but Goreleaser is still useful for the binary artifact creation capability.
+
+
+## Run Goreleaser with docker
+
+You can see the example project at [https://github.com/codefresh-contrib/goreleaser-sample-app](https://github.com/codefresh-contrib/goreleaser-sample-app){:target="\_blank"}. The repository contains a simple Golang web application with a [goreleaser configuration](https://github.com/codefresh-contrib/goreleaser-sample-app/blob/master/.goreleaser.yml){:target="\_blank"}.
+
+
+There is already a [Docker image for Goreleaser](https://hub.docker.com/r/goreleaser/goreleaser/){:target="\_blank"} so it is very easy to use it in Codefresh pipeline.
+In the most simple case you case run goreleaser in a [freestyle step]({{site.baseurl}}/docs/pipelines/steps/freestyle/).
+
+ `YAML`
+{% highlight yaml %}
+{% raw %}
+ ReleaseMyApp:
+ title: Creating packages
+ stage: release
+ image: 'goreleaser/goreleaser'
+ commands:
+ - goreleaser --snapshot --skip-publish --rm-dist
+{% endraw %}
+{% endhighlight %}
+
+More typically however you also need to provide a GitHub token so that GitHub releases are also available. There are two ways to do that.
+
+
+## Create a CI pipeline that compiles/releases Go
+
+In most cases you want to just reuse the Git integration already defined in Codefresh.
+This [pipeline](https://github.com/codefresh-contrib/goreleaser-sample-app/blob/master/codefresh.yml){:target="\_blank"} is using the GitHub token from [Git integration]({{site.baseurl}}/docs/integrations/git-providers/) in order to allow GitHub access.
+
+ `codefresh.yml`
+{% highlight yaml %}
+{% raw %}
+version: '1.0'
+stages:
+ - prepare
+ - build
+ - release
+steps:
+ main_clone:
+ title: 'Cloning main repository...'
+ type: git-clone
+ repo: '${{CF_REPO_OWNER}}/${{CF_REPO_NAME}}'
+ revision: '${{CF_REVISION}}'
+ stage: prepare
+ BuildMyApp:
+ title: Compiling go code
+ stage: build
+ image: 'golang:1.12'
+ commands:
+ - go build
+ GetGitToken:
+ title: Reading GitHub token
+ stage: release
+ image: codefresh/cli
+ commands:
+ - cf_export GITHUB_TOKEN=$(codefresh get context github-1 --decrypt -o yaml | yq -y .spec.data.auth.password)
+ ReleaseMyApp:
+ title: Creating packages
+ stage: release
+ image: 'goreleaser/goreleaser'
+ commands:
+ - goreleaser --rm-dist
+{% endraw %}
+{% endhighlight %}
+
+Note that GoReleaser [requires a GitHub API token](https://goreleaser.com/environment/){:target="\_blank"} (`GITHUB_TOKEN`) with the `repo` scope to deploy artifacts to GitHub.
+Here we use [cf_export]({{site.baseurl}}/docs/pipelines/variables/#exporting-environment-variables-from-a-freestyle-step) and the [codefresh CLI](https://codefresh-io.github.io/cli/){:target="\_blank"} in order to ask Codefresh about the existing token (that was used in git integrations). In your case you need to change `github-1` with the name of your [GitHub integration]({{site.baseurl}}/docs/integrations/git-providers/).
+
+It also possible to pass a GITHUB_TOKEN directly in the pipeline, if you don't want to re-use the existing one. This is an alternative way of allowing Goreleaser to create GitHub releases.
+
+{% include image.html
+lightbox="true"
+file="/images/examples/golang/github-token.png"
+url="/images/examples/golang/github-token.png"
+alt="Passing a specific github token in the pipeline"
+caption="Passing a specific github token in the pipeline"
+max-width="70%"
+%}
+
+You could also store the token in [shared configuration]({{site.baseurl}}/docs/pipelines/shared-configuration/).
+Regardless of the way you choose to pass the GitHub token, the final step is to make sure that your pipeline is only executed for tag events.
+
+
+{% include image.html
+lightbox="true"
+file="/images/examples/golang/tags-only-trigger.png"
+url="/images/examples/golang/tags-only-trigger.png"
+alt="Run pipeline only on tag creation"
+caption="Run pipeline only on tag creation"
+max-width="80%"
+%}
+
+This means that this pipeline will not run on normal commits. It is also possible to use [step conditionals]({{site.baseurl}}/docs/pipelines/conditional-execution-of-steps/) for more complex cases.
+
+## Related articles
+[Codefresh YAML for pipeline definitions]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/)
+[Steps in pipelines]({{site.baseurl}}/docs/pipelines/steps/)
+[Creating pipelines]({{site.baseurl}}/docs/pipelines/pipelines/)
+[How Codefresh pipelines work]({{site.baseurl}}/docs/pipelines/introduction-to-codefresh-pipelines/)
\ No newline at end of file
diff --git a/_docs/example-catalog/ci-examples/gradle.md b/_docs/example-catalog/ci-examples/gradle.md
new file mode 100644
index 000000000..602f1cca1
--- /dev/null
+++ b/_docs/example-catalog/ci-examples/gradle.md
@@ -0,0 +1,208 @@
+---
+title: "Java Example with Gradle and Docker"
+description: "Create Docker images for Spring/Gradle"
+excerpt: ""
+group: example-catalog
+sub_group: ci-examples
+redirect_from:
+ - /docs/learn-by-example/java/gradle/
+ - /docs/java/gradle/
+toc: true
+---
+
+Codefresh can work with Gradle builds in a similar manner as with [Maven builds]({{site.baseurl}}/docs/learn-by-example/java/spring-boot-2/){:target="\_blank"}.
+
+## The example Gradle project
+
+You can see the example project at [https://github.com/codefresh-contrib/gradle-sample-app](https://github.com/codefresh-contrib/gradle-sample-app){:target="\_blank"}. The repository contains a Spring Boot 2 project built with Gradle with the following tasks:
+
+* `gradle test` runs unit tests.
+* `gradle build` creates a self-contained jar file (using Spring boot).
+
+Once launched the application presents a simple message at localhost:8080 and also at the various `/actuator/health` endpoints.
+
+## Gradle and Docker (multi-stage builds)
+
+The easiest way to use Gradle is with [multi-stage builds](https://blog.docker.com/2017/07/multi-stage-builds/){:target="\_blank"}. With multi-stage builds a Docker build can use one base image for compilation/packaging/unit tests and a different one that will hold the runtime of the application. This makes the final image more secure and smaller in size (as it does not contain any development/debugging tools).
+
+In the case of Gradle, you can use a base image that has the full JDK and Gradle itself, while the final image has the JRE and nothing else.
+
+The example project is actually using multi-stage builds by default.
+
+Here is the multi-stage Dockerfile:
+
+ `Dockerfile`
+{% highlight docker %}
+{% raw %}
+FROM gradle:4.7.0-jdk8-alpine AS build
+COPY --chown=gradle:gradle . /home/gradle/src
+WORKDIR /home/gradle/src
+RUN gradle build --no-daemon
+
+FROM openjdk:8-jre-slim
+
+EXPOSE 8080
+
+RUN mkdir /app
+
+COPY --from=build /home/gradle/src/build/libs/*.jar /app/spring-boot-application.jar
+
+ENTRYPOINT ["java", "-XX:+UnlockExperimentalVMOptions", "-XX:+UseCGroupMemoryLimitForHeap", "-Djava.security.egd=file:/dev/./urandom","-jar","/app/spring-boot-application.jar"]
+{% endraw %}
+{% endhighlight %}
+
+This docker build does the following:
+
+1. Starts from the Gradle image
+1. Copies the Java source code inside the container
+1. Compiles the code and runs unit tests (with `Gradle build`)
+1. Discards the Gradle image with all the compiled classes/unit test results etc.
+1. Starts again from the JRE image and copies **only** the JAR file created before
+
+We start Gradle without the long-running daemon, as the deamon is best used during local development only and not in CI/CD pipelines.
+
+### Create a CI pipeline for Gradle (multi-stage Docker builds)
+
+Because in multi-stage builds Docker itself handles most of the build process, moving the project to Codefresh is straightforward. We just need [a single step](https://github.com/codefresh-contrib/gradle-sample-app/blob/master/codefresh.yml){:target="\_blank"} that creates the Docker image after checking out the code.
+
+ `codefresh.yml`
+{% highlight yaml %}
+{% raw %}
+version: '1.0'
+stages:
+ - prepare
+ - build
+steps:
+ main_clone:
+ title: Cloning main repository...
+ stage: prepare
+ type: git-clone
+ repo: 'codefresh-contrib/gradle-sample-app'
+ revision: master
+ git: github
+ BuildingDockerImage:
+ title: Building Docker Image
+ stage: build
+ type: build
+ image_name: gradle-sample-app
+ working_directory: ./
+ tag: 'multi-stage'
+ dockerfile: Dockerfile
+{% endraw %}
+{% endhighlight %}
+
+This will compile/test/package the Gradle application and create a Docker image.
+
+
+{% include image.html
+lightbox="true"
+file="/images/examples/java/gradle-multistage.png"
+url="/images/examples/java/gradle-multistage.png"
+alt="Gradle Multi-stage Docker build"
+caption="Gradle Multi-stage Docker build"
+max-width="80%"
+%}
+
+Codefresh is automatically caching
+Docker layers (it uses the Docker image of a previous build as a cache for the next) and therefore builds will become
+much faster after the first one finishes.
+
+
+## Packaging an existing Jar in a Docker image
+
+It also possible to have a simpler Dockerfile that only packages the final jar which was already created in the CI/CD pipeline (i.e. outside of Docker).
+
+A [simpler Dockerfile](https://github.com/codefresh-contrib/gradle-sample-app/blob/master/Dockerfile.only-package){:target="\_blank"} is also provided at the same repository. It uses the base JRE image and just copies the JAR file inside the container.
+
+ `Dockerfile.only-package`
+{% highlight docker %}
+{% raw %}
+FROM openjdk:8-jre-slim
+
+EXPOSE 8080
+
+RUN mkdir /app
+
+COPY build/libs/*.jar /app/spring-boot-application.jar
+
+ENTRYPOINT ["java", "-XX:+UnlockExperimentalVMOptions", "-XX:+UseCGroupMemoryLimitForHeap", "-Djava.security.egd=file:/dev/./urandom","-jar","/app/spring-boot-application.jar"]
+{% endraw %}
+{% endhighlight %}
+
+This means that _before_ building the Docker image, the compilation step (`gradle build`) is expected to be finished already. Therefore, in the `codefresh.yml` file we need at least two steps. The first one should prepare the JAR file and the second
+one should create the Docker image.
+
+### Create a CI pipeline for a Gradle JAR
+
+The repository also contains a premade [Codefresh YAML file](https://github.com/codefresh-contrib/gradle-sample-app/blob/master/codefresh-package-only.yml){:target="\_blank"} that creates a JAR file first and then packages it in a Docker image.
+
+Here are the full contents of the file.
+
+ `codefresh-package-only.yml`
+{% highlight yaml %}
+{% raw %}
+version: '1.0'
+stages:
+ - prepare
+ - test
+ - package
+ - build
+steps:
+ main_clone:
+ title: Cloning main repository...
+ stage: prepare
+ type: git-clone
+ repo: 'codefresh-contrib/gradle-sample-app'
+ revision: master
+ git: github
+ MyUnitTests:
+ title: Compile/Unit test
+ stage: test
+ image: gradle:4.7.0-jdk8-alpine
+ commands:
+ - gradle test --no-daemon --build-cache --gradle-user-home=/codefresh/volume/.gradle -Dmaven.repo.local=/codefresh/volume/m2
+ BuildMyJar:
+ title: Packaging Jar file
+ stage: package
+ image: gradle:4.7.0-jdk8-alpine
+ commands:
+ - gradle build --no-daemon --build-cache --gradle-user-home=/codefresh/volume/.gradle -Dmaven.repo.local=/codefresh/volume/m2
+ MyAppDockerImage:
+ title: Building Docker Image
+ type: build
+ stage: build
+ image_name: gradle-sample-app
+ working_directory: ./
+ tag: 'non-multi-stage'
+ dockerfile: Dockerfile.only-package
+{% endraw %}
+{% endhighlight %}
+
+The pipeline starts by checking out the code using a [git clone step]({{site.baseurl}}/docs/pipelines/steps/git-clone/). The next two steps are [freestyle]({{site.baseurl}}/docs/pipelines/steps/freestyle/), while the last one is a [build step]({{site.baseurl}}/docs/pipelines/steps/build/).
+
+{% include image.html
+lightbox="true"
+file="/images/examples/java/gradle-ci-pipeline.png"
+url="/images/examples/java/gradle-ci-pipeline.png"
+alt="Gradle pipeline"
+caption="Gradle pipeline"
+max-width="80%"
+%}
+
+After checking out the code we use the standard [Gradle Docker image](https://hub.docker.com/_/gradle/){:target="\_blank"} to run unit tests. We also pass parameters that disable the Gradle daemon, enable the build cache and also change the cache folder to reside in the Codefresh volume.
+
+### Using the Gradle cache in Codefresh
+
+Codefresh is smart enough that [caches automatically]({{site.baseurl}}/docs/pipelines/introduction-to-codefresh-pipelines/#how-caching-works-in-codefresh) for us the workspace of a build (`/codefresh/volume`). This works great for build tools that keep their cache in the project folder, but not for Maven/Gradle which keep their cache externally. By changing the location of the Gradle cache we make sure that Codefresh will cache automatically the Gradle libraries resulting in much faster builds. We also place in the shared volume the local maven repo so that all jars that are created by Gradle (i.e. with an `install` task) are also available to the next pipeline stage.
+
+The next step is similar to the previous one, but this time we actually build the JAR file. We define again a custom cache folder so when you run the build you will see that Gradle will automatically pick the cache from the previous step. All Codefresh steps in a pipeline [run on the same workspace]({{site.baseurl}}/docs/pipelines/introduction-to-codefresh-pipelines/#sharing-the-workspace-between-build-steps), so the build results from one step are visible to the next.
+
+The last step is a Docker build. We name our image **gradle-sample-app** and tag it with a string `non-multi-stage` but of course you can use any other tag name that you wish.
+Once the pipeline is finished you will see the Spring Boot 2 Docker image your [Docker image dashboard]({{site.baseurl}}/docs/docker-registries/working-with-docker-registries/#viewing-docker-images).
+
+## Related articles
+[Spring Maven example]({{site.baseurl}}/docs/example-catalog/ci-examples/spring-boot-2/)
+[Codefresh YAML for pipeline definitions]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/)
+[Steps in pipelines]({{site.baseurl}}/docs/pipelines/steps/)
+[Creating pipelines]({{site.baseurl}}/docs/pipelines/pipelines/)
+[How Codefresh pipelines work]({{site.baseurl}}/docs/pipelines/introduction-to-codefresh-pipelines/)
diff --git a/_docs/example-catalog/ci-examples/import-data-to-mongodb.md b/_docs/example-catalog/ci-examples/import-data-to-mongodb.md
new file mode 100644
index 000000000..5dff56089
--- /dev/null
+++ b/_docs/example-catalog/ci-examples/import-data-to-mongodb.md
@@ -0,0 +1,62 @@
+---
+
+title: "Import data to MongoDB"
+description: ""
+group: example-catalog
+sub_group: ci-examples
+redirect_from:
+ - /docs/yaml-examples/examples/integration-tests-with-mongo/
+ - /docs/import-data-to-mongodb-in-composition/
+ - /docs/on-demand-test-environment/example-compositions/import-data-to-mongodb/
+ - /docs/yaml-examples/examples/import-data-to-mongodb/
+toc: true
+---
+
+To import, restore, or for any operation before using MongoDB in your application, look at the following example.
+
+You just need to create Dockerfile for Mongo seed service and provide the command to prepare MongoDB. In this case, the command is `mongoimport`.
+
+ `Dockerfile mongo_seed`
+{% highlight docker %}
+FROM mongo
+COPY init.json /init.json
+CMD mongoimport --host mongodb --db exampleDb --collection contacts --type json --file /init.json --jsonArray
+{% endhighlight %}
+
+## Looking around
+In the root of this repository you'll find a file named `docker-compose.yml`.
+Let's quickly review the contents of this file:
+
+ `docker-compose.yml`
+{% highlight yaml %}
+{% raw %}
+version: '3'
+services:
+ mongodb:
+ image: mongo
+ command: mongod --smallfiles
+ ports:
+ - 27017
+
+ mongo_seed:
+ image: ${{mongo_seed}}
+ links:
+ - mongodb
+
+ client:
+ image: ${{build_prj}}
+ links:
+ - mongodb
+ ports:
+ - 9000
+ environment:
+ - MONGO_URI=mongodb:27017/exampleDb
+{% endraw %}
+{% endhighlight %}
+
+{{site.data.callout.callout_info}}
+You can add the following example to your GitHub or Bitbucket account, and build the [example](https://github.com/codefreshdemo/cf-example-manage-mongodb){:target="_blank"}.
+{{site.data.callout.end}}
+
+## Related articles
+[CI/CD pipeline examples]({{site.baseurl}}/docs/example-catalog/examples/#ci-examples)
\ No newline at end of file
diff --git a/_docs/example-catalog/ci-examples/integration-tests-with-mongo.md b/_docs/example-catalog/ci-examples/integration-tests-with-mongo.md
new file mode 100644
index 000000000..705e79305
--- /dev/null
+++ b/_docs/example-catalog/ci-examples/integration-tests-with-mongo.md
@@ -0,0 +1,102 @@
+---
+title: "Integration tests with Mongo"
+description: "Launching a MongoDB service container"
+group: example-catalog
+sub_group: ci-examples
+redirect_from:
+ - /docs/yaml-examples/examples/integration-tests-with-mongo/
+ - /docs/nodejsmongo/
+ - /docs/testing/unit-tests/unit-tests-with-mongo/
+toc: true
+---
+
+In this example, we will see a NodeJS project that uses MongoDB for data storage. For the integration test phase we will launch an instance of MongoDB in order to run a set of [Mocha tests](https://mochajs.org/){:target="\_blank"}.
+
+{% include image.html
+lightbox="true"
+file="/images/examples/integration-tests/mongodb-integration-tests.png"
+url="/images/examples/integration-tests/mongodb-integration-tests.png"
+alt="MongoDB integration tests with Codefresh"
+caption="MongoDB integration tests with Codefresh"
+max-width="90%"
+%}
+
+The Mocha tests are looking for a MongoDB connection at `mongo:27017`.
+
+## The example NodeJS project
+
+You can see the example project at [https://github.com/codefreshdemo/example_nodejs_mongo](https://github.com/codefreshdemo/example_nodejs_mongo){:target="\_blank"}. The repository contains the NodeJS source code and the Mocha tests.
+
+You can play with it locally by using Docker compose to launch both the application and the MongoDB datastore.
+
+## Create a pipeline with MongoDB integration tests
+
+Here is the whole pipeline:
+
+ `codefresh.yml`
+{% highlight yaml %}
+{% raw %}
+version: "1.0"
+stages:
+ - prepare
+ - build
+ - test
+steps:
+ main_clone:
+ type: "git-clone"
+ description: "Cloning main repository..."
+ repo: "codefreshdemo/example_nodejs_mongo"
+ revision: "master"
+ git: github
+ stage: prepare
+ build_app_image:
+ title: "Building Docker Image"
+ type: "build"
+ image_name: "node-mongo-app"
+ tag: "master"
+ dockerfile: "Dockerfile"
+ stage: build
+ run_integration_tests:
+ title: "Running integration tests"
+ stage: test
+ image: '${{build_app_image}}'
+ environment:
+ - MONGO_PORT=27017
+ commands:
+ # MongoDB is certainly up at this point
+ - cd /src
+ - npm test
+ services:
+ composition:
+ mongo:
+ image: mongo:latest
+ ports:
+ - 27017
+ readiness:
+ timeoutSeconds: 30
+ periodSeconds: 15
+ image: '${{build_app_image}}'
+ commands:
+ - "nslookup mongo"
+ - "nc -z mongo 27017"
+{% endraw %}
+{% endhighlight %}
+
+This pipeline does the following:
+
+1. Clones the source code through a [Git clone step]({{site.baseurl}}/docs/pipelines/steps/git-clone/).
+1. Builds a Docker image with the application source code as well as the Mocha tests through a [build step]({{site.baseurl}}/docs/pipelines/steps/build/).
+1. Runs Mocha tests while launching a [service container]({{site.baseurl}}/docs/pipelines/service-containers/) for an active MongoDB instance
+
+Notice that we also use the `readiness` property in the testing phase so that we can verify MongoDB is ready and listening, before running the tests.
+
+## Related articles
+[CI pipeline examples]({{site.baseurl}}/docs/example-catalog/examples/#ci-examples)
+[Integration test example]({{site.baseurl}}/docs/example-catalog/ci-examples/run-integration-tests/)
+[Integration tests with Postgres]({{site.baseurl}}/docs/example-catalog/ci-examples/integration-tests-with-postgres/)
+[Integration tests with MySQL]({{site.baseurl}}/docs/example-catalog/ci-examples/integration-tests-with-mysql/)
+[Integration tests with Redis]({{site.baseurl}}/docs/example-catalog/ci-examples/integration-tests-with-redis/)
+
+
+
+
diff --git a/_docs/example-catalog/ci-examples/integration-tests-with-mysql.md b/_docs/example-catalog/ci-examples/integration-tests-with-mysql.md
new file mode 100644
index 000000000..59e7866db
--- /dev/null
+++ b/_docs/example-catalog/ci-examples/integration-tests-with-mysql.md
@@ -0,0 +1,111 @@
+---
+title: "Integration tests with MySQL"
+description: "Launching a MySQL service container"
+group: example-catalog
+sub_group: ci-examples
+redirect_from:
+ - /docs/yaml-examples/examples/integration-tests-with-mysql/
+ - /docs/nodejsmysql/
+ - /docs/testing/unit-tests/unit-tests-with-mysql/
+ - /docs/setup-unit-tests/
+ - /docs/testing/unit-tests/unit-tests-with-composition/
+ - /docs/run-unit-tests-with-composition/
+ - /docs/unit-tests-with-database/
+ - /docs/testing/unit-tests/unit-tests-with-database/
+ - /docs/example-catalog/ci-examples/integration-tests-with-database/
+toc: true
+---
+
+In this example, we will see a NodeJS project that is using MySQL for data storage. For the integration test phase we will launch an instance of MySQL in order to run a simple integration test.
+
+{% include image.html
+lightbox="true"
+file="/images/examples/integration-tests/mysql-integration-tests.png"
+url="/images/examples/integration-tests/mysql-integration-tests.png"
+alt="MySQL integration tests with Codefresh"
+caption="MySQL integration tests with Codefresh"
+max-width="90%"
+%}
+
+The integration tests look for a MySQL connection at `test_mysql_db:3306`.
+
+## Example NodeJS project
+
+You can see the example project at [https://github.com/codefreshdemo/cf-example-unit-tests-with-composition](https://github.com/codefreshdemo/cf-example-unit-tests-with-composition){:target="\_blank"}. The repository contains the NodeJS source code and the simple integration test.
+
+You can play with it locally by using Docker compose to launch both the application and the MySQL Database.
+
+## Create a pipeline with MySQL integration tests
+
+Here is the whole pipeline:
+
+ `codefresh.yml`
+{% highlight yaml %}
+{% raw %}
+version: "1.0"
+stages:
+ - prepare
+ - build
+ - test
+steps:
+ main_clone:
+ type: "git-clone"
+ description: "Cloning main repository..."
+ repo: "codefreshdemo/cf-example-unit-tests-with-composition"
+ revision: "master"
+ git: github
+ stage: prepare
+ build_test_image:
+ title: "Building Test Docker Image"
+ type: "build"
+ image_name: "mysql-tests"
+ tag: "master"
+ dockerfile: "Dockerfile"
+ stage: build
+ run_integration_tests:
+ title: "Running integration tests"
+ stage: test
+ image: '${{build_test_image}}'
+ environment: &test_mysql_vars
+ - MYSQL_ROOT_PASSWORD=admin
+ - MYSQL_USER=my_user
+ - MYSQL_PASSWORD=admin
+ - MYSQL_DATABASE=nodejs
+ - MYSQL_HOST=test_mysql_db
+ commands:
+ # MySQL is certainly up at this point
+ - cd /usr/src/app
+ - npm test
+ services:
+ composition:
+ test_mysql_db:
+ image: mysql:5.7
+ ports:
+ - 3306
+ environment: *test_mysql_vars # Same MYSQL_HOST, MYSQL_USER etc.
+ readiness:
+ timeoutSeconds: 30
+ periodSeconds: 15
+ image: '${{build_test_image}}'
+ commands:
+ - "nslookup test_mysql_db"
+ - "nc -z test_mysql_db 3306"
+{% endraw %}
+{% endhighlight %}
+
+This pipeline does the following:
+
+1. Clones the source code through a [Git clone step]({{site.baseurl}}/docs/pipelines/steps/git-clone/).
+1. Builds a Docker image with the integration test through a [build step]({{site.baseurl}}/docs/pipelines/steps/build/).
+1. Runs the tests while launching a [service container]({{site.baseurl}}/docs/pipelines/service-containers/) for an active MySQL instance passing the required environment variables (that match what the test is expecting).
+
+Notice that both the DB as well as the tests share a set of variables (`MYSQL_PASSWORD`, `MYSQL_USER` etc.) and thus we use [YAML anchors]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/#using-yaml-anchors-to-avoid-repetition) to avoid duplication.
+
+Notice that we also use the `readiness` property in the testing phase so that we can verify MySQL is ready and listening, before running the tests.
+
+## Related articles
+[CI pipeline examples]({{site.baseurl}}/docs/example-catalog/examples/#ci-examples)
+[Integration test example]({{site.baseurl}}/docs/example-catalog/ci-examples/run-integration-tests/)
+[Integration tests with Postgres]({{site.baseurl}}/docs/example-catalog/ci-examples/integration-tests-with-postgres/)
+[Integration tests with Redis]({{site.baseurl}}/docs/example-catalog/ci-examples/integration-tests-with-redis/)
+[Integration tests with Mongo]({{site.baseurl}}/docs/example-catalog/ci-examples/integration-tests-with-mongo/)
diff --git a/_docs/example-catalog/ci-examples/integration-tests-with-postgres.md b/_docs/example-catalog/ci-examples/integration-tests-with-postgres.md
new file mode 100644
index 000000000..8e63fb97b
--- /dev/null
+++ b/_docs/example-catalog/ci-examples/integration-tests-with-postgres.md
@@ -0,0 +1,100 @@
+---
+title: "Integration tests with Postgres"
+description: "Launching a PostgreSQL service container"
+group: example-catalog
+sub_group: ci-examples
+redirect_from:
+ - /docs/yaml-examples/examples/integration-tests-with-postgres/
+ - /docs/unit-tests-with-postgres/
+ - /docs/testing/unit-tests/unit-tests-with-postgres/
+toc: true
+---
+
+In this example, we will see a NodeJS project that is using PostgreSQL for data storage. For the integration test phase we will launch an instance of PostgreSQL in order to run a simple integration test.
+
+{% include image.html
+lightbox="true"
+file="/images/examples/integration-tests/postgresql-integration-tests.png"
+url="/images/examples/integration-tests/postgresql-integration-tests.png"
+alt="PostgreSQL integration tests with Codefresh"
+caption="PostgreSQL integration tests with Codefresh"
+max-width="90%"
+%}
+
+The integration tests look for a PostgreSQL connection at `postgres:5432`.
+
+## Example NodeJS project
+
+You can see the example project at [https://github.com/codefreshdemo/example_nodejs_postgres](https://github.com/codefreshdemo/example_nodejs_postgres){:target="\_blank"}. The repository contains the NodeJS source code and the simple integration test.
+
+You can play with it locally by using Docker compose to launch both the application and the PostgreSQL Database.
+
+## Create a pipeline with PostgreSQL integration tests
+
+Here is the whole pipeline:
+
+ `codefresh.yml`
+{% highlight yaml %}
+{% raw %}
+version: "1.0"
+stages:
+ - prepare
+ - build
+ - test
+steps:
+ main_clone:
+ type: "git-clone"
+ description: "Cloning main repository..."
+ repo: "codefreshdemo/example_nodejs_postgres"
+ revision: "master"
+ git: github
+ stage: prepare
+ run_integration_tests:
+ title: "Running integration tests"
+ stage: test
+ image: node:6.9.1
+ environment: &test_postgresql_vars
+ - POSTGRES_USER=user
+ - POSTGRES_PASSWORD=admin
+ - POSTGRES_DB=todo
+ commands:
+ # PostgreSQL is certainly up at this point
+ - npm install -g gulp
+ - npm install
+ - npm test
+ services:
+ composition:
+ postgres:
+ image: postgres:11.5
+ ports:
+ - 5432
+ environment: *test_postgresql_vars # Same POSTGRES_USER, POSTGRES_PASSWORD etc.
+ readiness:
+ timeoutSeconds: 30
+ periodSeconds: 15
+ image: postgres:11.5
+ commands:
+ - "pg_isready -h postgres"
+
+{% endraw %}
+{% endhighlight %}
+
+This pipeline does the following:
+
+1. Clones the source code through a [Git clone step]({{site.baseurl}}/docs/pipelines/steps/git-clone/).
+1. Runs the tests while launching a [service container]({{site.baseurl}}/docs/pipelines/service-containers/) for an active PostgreSQL instance passing the required environment variables (that match what the test is expecting).
+
+Notice that both the DB as well as the tests share a set of variables (`POSTGRES_USER`, `POSTGRES_PASSWORD` etc.) and thus we use [YAML anchors]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/#using-yaml-anchors-to-avoid-repetition) to avoid duplication.
+
+Notice that we also use the `readiness` property in the testing phase so that we can verify PostgreSQL is ready and listening, before running the tests.
+
+
+## Related articles
+[CI pipeline examples]({{site.baseurl}}/docs/example-catalog/examples/#ci-examples)
+[Integration test example]({{site.baseurl}}/docs/example-catalog/ci-examples/run-integration-tests/)
+[Integration tests with MySQL]({{site.baseurl}}/docs/example-catalog/ci-examples/integration-tests-with-mysql/)
+[Integration tests with Redis]({{site.baseurl}}/docs/example-catalog/ci-examples/integration-tests-with-redis/)
+[Integration tests with Mongo]({{site.baseurl}}/docs/example-catalog/ci-examples/integration-tests-with-mongo/)
+[Preload a DB with test data]({{site.baseurl}}/docs/example-catalog/ci-examples/populate-a-database-with-existing-data/)
+
+
diff --git a/_docs/example-catalog/ci-examples/integration-tests-with-redis.md b/_docs/example-catalog/ci-examples/integration-tests-with-redis.md
new file mode 100644
index 000000000..6de5e9f7d
--- /dev/null
+++ b/_docs/example-catalog/ci-examples/integration-tests-with-redis.md
@@ -0,0 +1,130 @@
+---
+title: "Integration tests with Redis"
+description: "Launching a Redis service container"
+group: example-catalog
+sub_group: ci-examples
+redirect_from:
+ - /docs/yaml-examples/examples/integration-tests-with-redis/
+ - /docs/python-redis/
+ - /docs/testing/unit-tests/unit-tests-with-redis/
+toc: true
+---
+
+In this example, we will see a Python project that is using Redis for storing a web counter. For the integration test phase we will launch both the application and an instance of Redis in order to run a simple integration test.
+
+{% include image.html
+lightbox="true"
+file="/images/examples/integration-tests/redis-integration-tests.png"
+url="/images/examples/integration-tests/redis-integration-tests.png"
+alt="Redis integration tests with Codefresh"
+caption="Redis integration tests with Codefresh"
+max-width="90%"
+%}
+
+The application will be launched with a hostname `web` while Redis will be at `redis:6379`.
+
+## Example Python project
+
+You can see the example project at [https://github.com/codefreshdemo/example_python_redis](https://github.com/codefreshdemo/example_python_redis){:target="\_blank"}. The repository contains the Python source code and a test script.
+
+You can play with it locally by using Docker compose to launch both the application and the Redis datastore.
+
+## Create a pipeline with Redis integration tests
+
+Here is the whole pipeline:
+
+ `codefresh.yml`
+{% highlight yaml %}
+{% raw %}
+version: "1.0"
+stages:
+ - prepare
+ - build
+ - test
+steps:
+ main_clone:
+ type: "git-clone"
+ description: "Cloning main repository..."
+ repo: "codefreshdemo/example_python_redis"
+ revision: "master"
+ git: github
+ stage: prepare
+ build_app_image:
+ title: "Building Docker Image"
+ type: "build"
+ image_name: "python-redis-app"
+ tag: "latest"
+ dockerfile: "Dockerfile"
+ stage: build
+ build_test_image:
+ title: "Building Docker Test Image"
+ type: "build"
+ image_name: "python-redis-app-tests"
+ tag: "latest"
+ dockerfile: "Dockerfile.test"
+ stage: test
+ run_integration_tests:
+ title: "Running integration tests"
+ stage: test
+ image: '${{build_test_image}}'
+ commands:
+ # Redis and app are certainly up at this point
+ - sh ./test.sh
+ services:
+ composition:
+ redis:
+ image: redis:latest
+ ports:
+ - 6379
+ web:
+ image: '${{build_app_image}}'
+ ports:
+ - 80
+ readiness:
+ timeoutSeconds: 30
+ periodSeconds: 15
+ image: '${{build_test_image}}'
+ commands:
+ - "nslookup redis"
+ - "nslookup web"
+ - "nc -z redis 6379"
+ - "nc -z web 80"
+{% endraw %}
+{% endhighlight %}
+
+This pipeline does the following:
+
+1. Clones the source code through a [Git clone step]({{site.baseurl}}/docs/pipelines/steps/git-clone/).
+1. Builds a Docker image with the application itself through a [build step]({{site.baseurl}}/docs/pipelines/steps/build/).
+1. Builds a helper image that contains `nc` and `curl` that will be used for the integration tests.
+1. Runs the test script while launching two [service containers]({{site.baseurl}}/docs/pipelines/service-containers/) (one for the app and one for Redis).
+
+Notice that we also use the `readiness` property in the testing phase so that we can verify that both the application
+as well as Redis are up, before running the tests.
+
+## Integration test script
+
+The integration test is very simple. It just uses `curl` to hit the Python endpoint and `grep` to check for a well known string.
+
+ `test.sh`
+{% highlight sh %}
+#!bin/bash
+
+if curl web | grep -q 'Visits: '; then
+ echo "Tests passed!"
+ exit 0
+else
+ echo "Tests failed!"
+ exit 1
+fi
+{% endhighlight %}
+
+Notice that we use the helper image both for running the test (because of `curl`) and for testing the readiness (because of `nc`). In a more complex application these could be two completely different images.
+
+
+## Related articles
+[CI pipeline examples]({{site.baseurl}}/docs/example-catalog/examples/#ci-examples)
+[Integration test example]({{site.baseurl}}/docs/example-catalog/ci-examples/run-integration-tests/)
+[Integration tests with Postgres]({{site.baseurl}}/docs/example-catalog/ci-examples/integration-tests-with-postgres/)
+[Integration tests with MySQL]({{site.baseurl}}/docs/example-catalog/ci-examples/integration-tests-with-mysql/)
+[Integration tests with Mongo]({{site.baseurl}}/docs/example-catalog/ci-examples/integration-tests-with-mongo/)
diff --git a/_docs/example-catalog/ci-examples/launch-composition.md b/_docs/example-catalog/ci-examples/launch-composition.md
new file mode 100644
index 000000000..7f90d0f96
--- /dev/null
+++ b/_docs/example-catalog/ci-examples/launch-composition.md
@@ -0,0 +1,86 @@
+---
+title: "Launch Compositions"
+description: "Create a dynamic environment to preview your feature"
+group: example-catalog
+sub_group: ci-examples
+redirect_from:
+ - /docs/yaml-examples/examples/launch-composition/
+ - /docs/launch-composition-1/
+toc: true
+---
+Using this repository, we will help you get up to speed with basic functionality such as: building Docker images and launching compositions.
+This project uses `Node JS` to build an application which will eventually become a distributable Docker image.
+
+## Looking around
+
+In the root of this repository you'll find a file named `codefresh.yml`. This is our [pipeline definition]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/) and it describes the different steps that comprise our process. Let's quickly review the contents of this file:
+
+ `codefresh.yml`
+{% highlight yaml %}
+version: '1.0'
+stages:
+ - prepare
+ - package
+ - launch
+steps:
+ main_clone:
+ title: 'Cloning main repository...'
+ type: git-clone
+ repo: codefreshdemo/cf-example-launch-composition
+ revision: 'master'
+ git: github
+ stage: prepare
+ build_image:
+ title: Building Image
+ type: build
+ #Important: rename this image to to a valid repository in your registry. For example: myUserName/vote
+ image_name: example-launch-compose
+ #Dockerfile location should be relative to the working directory
+ dockerfile: Dockerfile
+ tag: master
+ stage: package
+ launch_composition:
+ title: Launch Composition
+ type: launch-composition
+ composition:
+ version: '2'
+ services:
+ app:
+ image: example-launch-compose:master
+ ports:
+ - 3000
+ environment_name: 'cf-example-launch-composition'
+ entry_point: app
+ fail_fast: false
+ stage: launch
+{% endhighlight %}
+
+The pipeline clones the source code, builds a docker image and then
+ [creates a preview environment]({{site.baseurl}}/docs/pipelines/steps/launch-composition/) with that image.
+
+
+>**Your environments are limited**
+ Be aware that the number of environments you can run is limited. When using the same environment, define that the old one would terminate before launching the new environment. That way you can control the number of environments running in your account.
+
+
+### Example
+
+Just head over to the example [**repository**](https://github.com/codefreshdemo/cf-example-launch-composition){:target=\_blank"} in GitHub and follow the instructions there.
+
+
+Here is the end result:
+
+{% include image.html
+lightbox="true"
+file="/images/examples/composition/launch-composition-example.png"
+url="/images/examples/composition/launch-composition-example.png"
+alt="Launch composition example"
+caption="Launch composition example"
+max-width="90%"
+%}
+
+## Related articles
+[CI pipeline examples]({{site.baseurl}}/docs/example-catalog/examples/#ci-examples)
+[Unit tests]({{site.baseurl}}/docs/example-catalog/ci-examples/run-integration-tests/)
+[Integration tests with MySQL]({{site.baseurl}}/docs/example-catalog/ci-examples/integration-tests-with-mysql/)
+[Preview environments]({{site.baseurl}}/docs/quick-start/ci-quick-start/on-demand-environments/)
\ No newline at end of file
diff --git a/_docs/example-catalog/ci-examples/launching-a-composition-and-defining-a-service-environment-variables-using-a-file.md b/_docs/example-catalog/ci-examples/launching-a-composition-and-defining-a-service-environment-variables-using-a-file.md
new file mode 100644
index 000000000..182ff29ed
--- /dev/null
+++ b/_docs/example-catalog/ci-examples/launching-a-composition-and-defining-a-service-environment-variables-using-a-file.md
@@ -0,0 +1,60 @@
+---
+title: "Use Docker compose"
+description: "Launch a composition and define a service environment variable using a file"
+group: example-catalog
+sub_group: ci-examples
+redirect_from:
+ - /docs/yaml-examples/examples/launching-a-composition-and-defining-a-service-environment-variables-using-a-file/
+ - /docs/launching-a-composition-and-passing-a-service-environment-variable-using-a-file/
+toc: true
+old_url: /docs/launching-a-composition-and-passing-a-service-environment-variable-using-a-file
+---
+At times when launching a composition, you need to pass many environment variables to a specific service.
+To do so, you can use `docker-compose 'env_file'` field on any service, and use files from the current working directory from which the composition is being launched.
+This works for both `composition` and `launch-composition` step types.
+
+>**Note**:
+ When launching a composition directly from the Compositions view, using `env_file` does not work as it is being launched in an empty working directory.
+ Consider moving the composition launch as part of a usual pipeline which will give you ability to use files from your cloned repository.
+
+
+## Examples
+Compositions are launched within a working directory, which is the cloned repository by default.
+This means that you can always reference an `env_file` just as would reference a `docker-compose` file.
+
+ `Inline Composition`
+{% highlight yaml %}
+{% raw %}
+version: '1.0'
+steps:
+
+ inline_composition:
+ title: Launch inline composition
+ type: launch-composition
+ environment_name: 'environment name'
+ composition:
+ version: '3'
+ services:
+ service:
+ image: alpine
+ env_file: ./env-file
+{% endraw %}
+{% endhighlight %}
+
+
+ `Composition from file`
+{% highlight yaml %}
+{% raw %}
+version: '1.0'
+steps:
+
+ composition_from_file:
+ title: Launch composition from file
+ type: launch-composition
+ composition: './docker-compose.yml'
+ environment_name: 'environment name'
+{% endraw %}
+{% endhighlight %}
+
+## Related articles
+[CI/CD pipeline examples]({{site.baseurl}}/docs/example-catalog/examples/#ci-examples)
\ No newline at end of file
diff --git a/_docs/example-catalog/ci-examples/lets-chat.md b/_docs/example-catalog/ci-examples/lets-chat.md
new file mode 100644
index 000000000..66c8ae8f3
--- /dev/null
+++ b/_docs/example-catalog/ci-examples/lets-chat.md
@@ -0,0 +1,123 @@
+---
+title: "Let's Chat example"
+description: "Create Docker images for Node/Express.js applications"
+group: example-catalog
+sub_group: ci-examples
+redirect_from:
+ - /docs/learn-by-example/nodejs/lets-chat/
+ - /docs/lets-chat/
+ - /docs/deploy-to-kubernetes/codefresh-kubernetes-integration-demochat-example/
+toc: true
+---
+
+Let’s Chat is self-hosted chat app for small to big teams.
+
+## The example Node.JS project
+
+You can see the example project at [https://github.com/codefreshdemo/demochat](https://github.com/codefreshdemo/demochat){:target="\_blank"}. The repository contains the source code of the project along with two Dockerfiles (one for unit tests) and various docker-compose configurations
+
+The project requires a Mongo Database to work and by default it uses port 5000 for its web interface.
+
+## Create a CI pipeline for Node.js
+
+Creating a CI/CD pipeline for NodeJS is very easy, because Codefresh has built-in steps for creating Docker images and running commands with containers.
+
+{% include image.html
+lightbox="true"
+file="/images/examples/nodejs/nodejs-pipeline.png"
+url="/images/examples/nodejs/nodejs-pipeline.png"
+alt="Building and testing a Node.js application"
+caption="Building and testing a Node.js application"
+max-width="100%"
+%}
+
+Here is the [full pipeline](https://github.com/codefreshdemo/demochat/blob/master/codefresh.yml){:target="\_blank"} that creates the Docker image after checking out the code.
+
+ `codefresh.yml`
+{% highlight yaml %}
+{% raw %}
+version: "1.0"
+stages:
+ - "clone"
+ - "unit"
+ - "build"
+ - "integration"
+
+steps:
+ clone:
+ title: "Cloning repository"
+ type: "git-clone"
+ repo: "codefreshdemo/demochat"
+ revision: "master"
+ stage: "clone"
+
+ build_dev_image:
+ title: "Building Dev image"
+ type: "build"
+ image_name: "codefreshdemo/demochat"
+ working_directory: "${{clone}}"
+ tag: "dev"
+ dockerfile: "Dockerfile.dev"
+ stage: "unit"
+
+ test:
+ title: "Running test"
+ type: "freestyle"
+ image: ${{build_dev_image}}
+ working_directory: /root/demochat
+ commands:
+ - 'npm run test'
+ stage: "unit"
+
+ build_image:
+ title: "Building App image"
+ type: "build"
+ image_name: "codefreshdemo/demochat"
+ working_directory: "${{clone}}"
+ tag: "dev"
+ dockerfile: "Dockerfile"
+ stage: "build"
+
+ integration_step:
+ type: composition
+ stage: 'integration'
+ composition:
+ version: '2'
+ services:
+ app:
+ image: ${{build_image}}
+ links:
+ - mongo
+ ports:
+ - 5000
+ mongo:
+ image: mongo
+ composition-candidates:
+ main:
+ image: nhoag/curl
+ command: bash -c "sleep 30 && curl http://app:5000/" | echo 'works'
+
+{% endraw %}
+{% endhighlight %}
+
+> Note that you should change `codefreshdemo` in the clone step with your own Github account if you fork the repository. Also in both build steps you should change `codefreshdemo/demochat` with your own image name that is compliant to your Dockerhub account or other connected registry.
+
+This pipeline has 4 [stages]({{site.baseurl}}/docs/pipelines/stages/) and performs the following:
+
+ 1. Clones the source code using the [git-clone]({{site.baseurl}}/docs/pipelines/steps/git-clone/) step
+ 1. Builds a Docker image for unit tests with the [build step]({{site.baseurl}}/docs/pipelines/steps/build/)
+ 1. Runs [unit tests]({{site.baseurl}}/docs/testing/unit-tests/) in the Docker image that was just created with a [freestyle step]({{site.baseurl}}/docs/pipelines/steps/freestyle/)
+ 1. Building a Docker image for the final application
+ 1. Runs [integration tests]({{site.baseurl}}/docs/testing/integration-tests/) using a [composition step]({{site.baseurl}}/docs/pipelines/steps/composition/)
+
+If you run the pipeline multiple times, you will also see the [Codefresh caching mechanisms]({{site.baseurl}}/docs/pipelines/pipeline-caching/) in action for faster build times.
+
+## Related articles
+[Voting app example]({{site.baseurl}}/docs/example-catalog/ci-examples/voting-app/)
+[Codefresh YAML for pipeline definitions]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/)
+[Steps in pipelines]({{site.baseurl}}/docs/pipelines/steps/)
+[Creating pipelines]({{site.baseurl}}/docs/pipelines/pipelines/)
+[How Codefresh pipelines work]({{site.baseurl}}/docs/pipelines/introduction-to-codefresh-pipelines/)
+
+
+
diff --git a/_docs/yaml-examples/examples/nodejs-angular2-mongodb.md b/_docs/example-catalog/ci-examples/nodejs-angular2-mongodb.md
similarity index 79%
rename from _docs/yaml-examples/examples/nodejs-angular2-mongodb.md
rename to _docs/example-catalog/ci-examples/nodejs-angular2-mongodb.md
index aa5b679a3..8199cac3b 100644
--- a/_docs/yaml-examples/examples/nodejs-angular2-mongodb.md
+++ b/_docs/example-catalog/ci-examples/nodejs-angular2-mongodb.md
@@ -1,11 +1,13 @@
---
title: "NodeJS + Angular2 + MongoDB"
description: ""
-group: yaml-examples
-sub_group: examples
+group: example-catalog
+sub_group: ci-examples
redirect_from:
+ - /docs/yaml-examples/examples/nodejs-angular2-mongodb/
- /docs/nodejs-angular2-mongodb/
- - /docs/on-demand-test-environment/example-compositions/nodejs-angular2-mongodb/
+ - /docs/on-demand-test-environment/example-compositions/nodejs-angular2-mongodb/
+ - /docs/learn-by-example/python/voting-app/
toc: true
---
This tutorial will walk you through the process of adding the following:
@@ -48,3 +50,5 @@ services:
Just head over to the example [__repository__](https://github.com/codefreshdemo/nodejs-angular2-mongo){:target="_blank"} in GitHub and follow the instructions there.
{{site.data.callout.end}}
+## Related articles
+[CD pipeline examples]({{site.baseurl}}/docs/example-catalog/examples/#cd-examples)
diff --git a/_docs/learn-by-example/nodejs.md b/_docs/example-catalog/ci-examples/nodejs.md
similarity index 91%
rename from _docs/learn-by-example/nodejs.md
rename to _docs/example-catalog/ci-examples/nodejs.md
index 0f5cc4fe5..4ed04ccde 100644
--- a/_docs/learn-by-example/nodejs.md
+++ b/_docs/example-catalog/ci-examples/nodejs.md
@@ -1,7 +1,8 @@
---
title: "Node.js"
description: ""
-group: learn-by-example
+group: example-catalog
+sub_group: ci-examples
redirect_from:
- /docs/nodejs/
toc: true
diff --git a/_docs/example-catalog/ci-examples/non-git-checkout.md b/_docs/example-catalog/ci-examples/non-git-checkout.md
new file mode 100644
index 000000000..f05956fc7
--- /dev/null
+++ b/_docs/example-catalog/ci-examples/non-git-checkout.md
@@ -0,0 +1,102 @@
+---
+title: "Checking out from other source control systems"
+description: "Work with non-git repositories"
+group: example-catalog
+sub_group: ci-examples
+redirect_from:
+ - /docs/yaml-examples/examples/non-git-checkout/
+toc: true
+---
+
+Codefresh has [native Git support]({{site.baseurl}}/docs/example-catalog/ci-examples/git-checkout/), but you can still use any other version control system such as SVN, CVS, hg, etc.
+
+The only requirement is that you find or create a Docker image that contains the client for that source control system and then use a
+[freestyle step]({{site.baseurl}}/docs/pipelines/steps/freestyle/) to run it.
+
+## Checking out Subversion code
+
+There is already a public [Docker image with the svn client](https://hub.docker.com/r/jgsqware/svn-client/){:target="\_blank"}, so it is very easy to run it in a Codefresh pipeline.
+
+{% highlight yaml %}
+{% raw %}
+version: '1.0'
+steps:
+ myCustomCheckout:
+ title: Performing SVN checkout
+ image: jgsqware/svn-client
+ commands:
+ - pwd
+ - rm -rf audacity-svn
+ - svn checkout https://svn.code.sf.net/p/audacity/svn/ audacity-svn
+ PrintFileList:
+ title: 'Listing files'
+ image: alpine:latest
+ commands:
+ - 'ls -l /codefresh/volume/'
+{% endraw %}
+{% endhighlight %}
+
+Notice the `rm` command before the clone step. This makes sure that every time the pipeline runs, the `svn checkout` step is implemented in an empty directory.
+
+
+
+## Checking out Mercurial or CVS Code
+
+It is very simple to use any other source control system in a Codefresh pipeline. The easiest way is to just call the respective executable. Here are two examples:
+
+{% highlight yaml %}
+{% raw %}
+version: '1.0'
+steps:
+ myHgStep:
+ title: Using HG
+ image: alpine:latest
+ commands:
+ - apk add --no-cache mercurial
+ - hg --version
+ - hg clone https://www.mercurial-scm.org/repo/hg mercurial-repo
+ myCvsStep:
+ title: Using CVS
+ image: alpine:latest
+ commands:
+ - apk add --no-cache cvs
+ - cvs --version
+ - cvs -d :pserver:anonymous@cvs.project-open.net:/home/cvsroot checkout -c
+{% endraw %}
+{% endhighlight %}
+
+A much faster way is to create your own Dockerfile that includes the client you need and then define that image directly in the freestyle step.
+
+
+## Checking out Perforce code
+
+Codefresh has created a [Perforce plugin](https://hub.docker.com/r/codefresh/cf-p4-plugin/tags){:target="\_blank"} which packs the p4 client into a Docker image to be used from Codefresh pipelines:
+
+{% highlight yaml %}
+{% raw %}
+version: '1.0'
+steps:
+ myCustomCheckout:
+ title: Performing Perforce checkout
+ image: codefresh/cf-p4-plugin:latest
+ commands:
+ - mkdir -p /codefresh/volume/p4repo/
+ - p4 client -o | grep -v '#' | sed '/Root:/c\Root:/codefresh/volume/p4repo/' | p4 client -i
+ - cd /codefresh/volume/p4repo/ && p4 rec
+ - 'ls -la'
+ environment:
+ - P4PORT=serveradress:serverport
+ - P4CLIENT=clientname
+ - P4USER=username
+ - P4PASSWD=password
+{% endraw %}
+{% endhighlight %}
+
+Define the environment variables in [Codefresh shared configuration]({{site.baseurl}}/docs/pipelines/configuration/shared-configuration/).
+
+
+## Related articles
+[CI/CD pipeline examples]({{site.baseurl}}/docs/example-catalog/examples/#ci-examples)
+[Native Git checkout]({{site.baseurl}}/docs/example-catalog/ci-examples/git-checkout/)
+[Running custom git commands]({{site.baseurl}}/docs/example-catalog/ci-examples/git-checkout-custom/)
+[Steps in pipelines]({{site.baseurl}}/docs/pipelines/steps/)
diff --git a/_docs/example-catalog/ci-examples/php.md b/_docs/example-catalog/ci-examples/php.md
new file mode 100644
index 000000000..2ed58114b
--- /dev/null
+++ b/_docs/example-catalog/ci-examples/php.md
@@ -0,0 +1,137 @@
+---
+title: "Create a Docker image for Php"
+description: "Using Codefresh pipelines"
+group: example-catalog
+sub_group: ci-examples
+redirect_from:
+ - /docs/learn-by-example/php/
+toc: true
+---
+
+Codefresh can work with Php projects using any of the popular frameworks (Laravel, Symphony, CakePHp etc.)
+
+## The example php project
+
+You can see the example project at [https://github.com/codefresh-contrib/php-composer-sample-app](https://github.com/codefresh-contrib/php-composer-sample-app){:target="\_blank"}. The repository contains a simple Php project that uses [composer](https://getcomposer.org/) as a package manager.
+
+The dockerfile uses [multi-stage builds](https://docs.docker.com/develop/develop-images/multistage-build/){:target="\_blank"} to minimize the size of the docker image.
+
+`Dockerfile`
+{% highlight docker %}
+{% raw %}
+FROM composer:1.9.3 as vendor
+
+WORKDIR /tmp/
+
+COPY composer.json composer.json
+COPY composer.lock composer.lock
+
+RUN composer install \
+ --ignore-platform-reqs \
+ --no-interaction \
+ --no-plugins \
+ --no-scripts \
+ --prefer-dist
+
+
+FROM php:7.2-apache-stretch
+
+COPY . /var/www/html
+COPY --from=vendor /tmp/vendor/ /var/www/html/vendor/
+{% endraw %}
+{% endhighlight %}
+
+
+## Create a Docker image for Php project
+
+An [example pipeline](https://github.com/codefresh-contrib/php-composer-sample-app/blob/master/codefresh.yml){:target="\_blank"} is also offered in the git repository.
+It contains just two [steps]({{site.baseurl}}/docs/pipelines/steps/):
+
+* A [clone step]({{site.baseurl}}/docs/pipelines/steps/git-clone/) to fetch the code
+* A [build step]({{site.baseurl}}/docs/pipelines/steps/build/) to create a Docker image
+
+ `codefresh.yml`
+{% highlight yaml %}
+{% raw %}
+version: '1.0'
+steps:
+ main_clone:
+ title: Cloning main repository...
+ type: git-clone
+ repo: 'codefresh-contrib/php-composer-sample-app'
+ revision: master
+ git: github
+ MyAppDockerImage:
+ title: Building Docker Image
+ type: build
+ image_name: my-php-image
+ working_directory: ./
+ tag: master
+ dockerfile: Dockerfile
+{% endraw %}
+{% endhighlight %}
+
+Once you run this pipeline Codefresh will create a Docker image for the Php application:
+
+{% include image.html
+lightbox="true"
+file="/images/examples/php/php-cicd-pipeline.png"
+url="/images/examples/php/php-cicd-pipeline.png"
+alt="Creating a docker image for php"
+caption="Creating a docker image for php"
+max-width="80%"
+%}
+
+Notice that all dependencies are downloaded when the dockerfile is created.
+
+
+
+
+## Launch Docker images
+
+Codefresh can also launch Docker images (using Docker swarm behind the scenes). With each Codefresh account you get access to a limited number of Docker environments that can host any Docker image or Docker compose file.
+
+First find your images in the [Docker image dashboard]({{site.baseurl}}/docs/docker-registries/working-with-docker-registries/#viewing-docker-images).
+
+{% include image.html
+lightbox="true"
+file="/images/examples/php/launch-docker-image.png"
+url="/images/examples/php/launch-docker-image.png"
+alt="Launching a Docker image"
+caption="Launching a Docker image"
+max-width="80%"
+%}
+
+Click on the launch button and a new pipeline will run for deployment:
+
+{% include image.html
+lightbox="true"
+file="/images/examples/php/test-environment-url.png"
+url="/images/examples/php/test-environment-url.png"
+alt="Getting the environment url"
+caption="Getting the environment url"
+max-width="80%"
+%}
+
+Notice that the pipeline logs show the dynamic URL of the application. Simply visit it with your browser
+and you will see the result.
+
+{% include image.html
+lightbox="true"
+file="/images/examples/php/test-environment.png"
+url="/images/examples/php/test-environment.png"
+alt="Application preview"
+caption="Application preview"
+max-width="80%"
+%}
+
+Notice that these environments are only for testing and previewing your application as it is developed. They are **NOT** for production purposes.
+
+
+
+## Related articles
+
+[Codefresh YAML for pipeline definitions]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/)
+[Steps in pipelines]({{site.baseurl}}/docs/pipelines/steps/)
+[Creating pipelines]({{site.baseurl}}/docs/pipelines/pipelines/)
+[How Codefresh pipelines work]({{site.baseurl}}/docs/pipelines/introduction-to-codefresh-pipelines/)
diff --git a/_docs/example-catalog/ci-examples/populate-a-database-with-existing-data.md b/_docs/example-catalog/ci-examples/populate-a-database-with-existing-data.md
new file mode 100644
index 000000000..04a202aea
--- /dev/null
+++ b/_docs/example-catalog/ci-examples/populate-a-database-with-existing-data.md
@@ -0,0 +1,154 @@
+---
+title: "Populate database with existing data"
+description: "Preload test data before integration tests"
+group: example-catalog
+sub_group: ci-examples
+redirect_from:
+ - /docs/yaml-examples/examples/populate-a-database-with-existing-data/
+ - /docs/populate-a-database-with-existing-data-copied/
+toc: true
+old_url: /docs/populate-a-database-with-existing-data-copied
+was_hidden: true
+---
+In another example, we saw how to run [integration tests with a database]({{site.baseurl}}/docs/example-catalog/ci-examples/integration-tests-with-postgres/) such as PostgreSQL. Sometimes however, the integration tests require the database to already have some test data beforehand. With Codefresh you can use the [setup block]({{site.baseurl}}/docs/pipelines/service-containers/#preloading-data-to-databases) in service containers to preload data to a database.
+
+
+{% include image.html
+lightbox="true"
+file="/images/examples/integration-tests/preload-data-to-db.png"
+url="/images/examples/integration-tests/preload-data-to-db.png"
+alt="Preloading test data to a DB"
+caption="Preloading test data to a DB"
+max-width="90%"
+%}
+
+In this pipeline the database is populated with data from an SQL file.
+
+## Example PostgreSQL project
+
+You can see the example project at [https://github.com/codefresh-contrib/preload-db-integration-tests](https://github.com/codefresh-contrib/preload-db-integration-tests){:target="\_blank"}. The repository contains a simple integration test and an SQL file that inserts test data.
+
+The SQL file creates a single table in the database:
+
+ `preload.sql`
+{% highlight sql %}
+{% raw %}
+CREATE TABLE link (
+ ID serial PRIMARY KEY,
+ url VARCHAR (255) NOT NULL,
+ name VARCHAR (255) NOT NULL,
+ description VARCHAR (255),
+ rel VARCHAR (50)
+);
+
+INSERT INTO link (url, name)
+VALUES
+ ('http://www.google.com','Google'),
+ ('http://www.azure.microsoft.com','Azure'),
+ ('http://www.codefresh.io','Codefresh');
+{% endraw %}
+{% endhighlight %}
+
+
+To work with the project locally, you need to have `docker`, `golang` and `postgres-client` installed on your workstation first.
+
+```
+$ docker run -p 5432:5432 postgres:11.5
+```
+
+Then open another terminal and load the test data:
+
+```
+$ psql -h localhost -U postgres < testdata/preload.sql
+```
+
+A Postgres instance is now running at `localhost:5432` and you can run the tests with:
+
+```
+$ go test -v
+```
+
+
+## Create a pipeline the preloads test data to PostgreSQL
+
+Here is the whole pipeline:
+
+ `codefresh.yml`
+{% highlight yaml %}
+{% raw %}
+version: "1.0"
+stages:
+- prepare
+- package
+- test
+steps:
+ main_clone:
+ type: "git-clone"
+ description: "Cloning main repository..."
+ repo: "codefresh-contrib/preload-db-integration-tests"
+ revision: "master"
+ title: "Checking out source code"
+ git: github
+ stage: prepare
+ package_my_app:
+ stage: package
+ image: 'golang:1.13'
+ title: "Compile code"
+ commands:
+ - 'go build'
+ run_my_db_tests:
+ stage: test
+ image: 'golang:1.13'
+ title: "Running integration tests"
+ commands:
+ - 'go test -v'
+ environment:
+ - POSTGRES_HOST=my_postgresql_db
+ services:
+ composition:
+ my_postgresql_db:
+ image: postgres:11.5
+ ports:
+ - 5432
+ readiness:
+ timeoutSeconds: 30
+ initialDelaySeconds: 10
+ periodSeconds: 15
+ image: 'postgres:11.5'
+ commands:
+ - "pg_isready -h my_postgresql_db -U postgres"
+ setup:
+ image: 'postgres:11.5'
+ commands:
+ - "psql -h my_postgresql_db -U postgres < /codefresh/volume/preload-db-integration-tests/testdata/preload.sql"
+{% endraw %}
+{% endhighlight %}
+
+This pipeline does the following:
+
+1. Clones the source code through a [Git clone step]({{site.baseurl}}/docs/pipelines/steps/git-clone/).
+1. Compiles the code that runs `go build` through a [freestyle step]({{site.baseurl}}/docs/pipelines/steps/freestyle/).
+1. Runs the tests while launching a [service container]({{site.baseurl}}/docs/pipelines/service-containers/) for an active PostgreSQL instance. Before tests are run, we launch another container with the `psql` executable to load database data.
+
+
+> In this simple example, we use `psql` to preload the database. In a production application you might also use dedicated db tools such as [liquibase](https://hub.docker.com/r/liquibase/liquibase){:target="\_blank"} or [flyway](https://hub.docker.com/r/flyway/flyway){:target="\_blank"} or other command line tools that communicate with your database.
+
+Notice that we also use the `readiness` property in the testing phase so that we can verify PostgreSQL is ready and listening, before running the tests. The exact order of events is:
+
+1. Codefresh launches `postgres:11.5` at port 5432.
+1. It then launches another container in the same network with `pg_isready` in order to wait for the DB to be up.
+1. Then it launches a third container with `psql` to preload data.
+1. Finally, it launches a container with `golang:1.13` to run the actual tests.
+
+All containers are discarded after the pipeline has finished.
+
+## Related articles
+[CI pipeline examples]({{site.baseurl}}/docs/example-catalog/examples/#ci-examples)
+[Integration test example]({{site.baseurl}}/docs/example-catalog/ci-examples/run-integration-tests/)
+[Integration tests with Postgres]({{site.baseurl}}/docs/example-catalog/ci-examples/integration-tests-with-postgres/)
+[Integration tests with MySQL]({{site.baseurl}}/docs/example-catalog/ci-examples/integration-tests-with-mysql/)
+[Integration tests with Mongo]({{site.baseurl}}/docs/example-catalog/ci-examples/integration-tests-with-mongo/)
+[Integration tests with Redis]({{site.baseurl}}/docs/example-catalog/ci-examples/integration-tests-with-redis/)
+
+
+
diff --git a/_docs/example-catalog/ci-examples/publish-jar.md b/_docs/example-catalog/ci-examples/publish-jar.md
new file mode 100644
index 000000000..c62c1bc1a
--- /dev/null
+++ b/_docs/example-catalog/ci-examples/publish-jar.md
@@ -0,0 +1,118 @@
+---
+title: "Publish Jar"
+description: "How to upload a JAR file to Nexus or artifactory"
+excerpt: ""
+group: example-catalog
+sub_group: ci-examples
+redirect_from:
+ - /docs/learn-by-example/java/publish-jar/
+toc: true
+---
+
+Even though Codefresh has great support for containers, it can still be used for traditional JAR uploads of libraries or applications that are not dockerized yet. In this example we will compile a JAR and upload it to Nexus. The process is the same for Artifactory or any other package manager.
+
+For a Java application with Docker, see the [Gradle]({{site.baseurl}}/docs/example-catalog/ci-examples/gradle/) or
+ [Maven example]({{site.baseurl}}/docs/example-catalog/ci-examples/spring-boot-2/).
+
+## The example Java library project
+
+You can see the example project at [https://github.com/codefresh-contrib/plain-jar-sample-lib](https://github.com/codefresh-contrib/plain-jar-sample-lib). The repository contains a simple Java library built with Maven with the following goals:
+
+* `mvn package` creates a jar file of the library. It also runs unit tests.
+* `mvn upload` uploads the jar to a package manager such as Nexus or Artifactory.
+
+We use Nexus for this example. To upload the Jar manually first edit the `pom.xml` with the URL of the package manager. The project also includes a [settings.xml](https://github.com/codefresh-contrib/plain-jar-sample-lib/blob/master/settings.xml) with parameterized credential.
+
+{% include image.html
+lightbox="true"
+file="/images/examples/java/nexus-browser.png"
+url="/images/examples/java/nexus-browser.png"
+alt="The Nexus package manager"
+caption="The Nexus package manager"
+max-width="80%"
+%}
+
+From your workstation you can upload the jar manually with:
+
+
+```
+mvn -s settings.xml -Dserver.password=my-nexus-user -Dserver.username=my-nexus-pass deploy
+```
+If you then visit Nexus you should see your JAR file in the snapshots repository.
+
+## Create a CI pipeline for publishing a JAR file
+
+[Create a new pipeline]({{site.baseurl}}/docs/pipelines/pipelines/) in Codefresh and define as parameters your Nexus credentials. You could also use [shared configuration]({{site.baseurl}}/docs/pipelines/shared-configuration/) or any other credential mechanism you already use in your other pipelines.
+
+{% include image.html
+lightbox="true"
+file="/images/examples/java/nexus-credentials.png"
+url="/images/examples/java/nexus-credentials.png"
+alt="Parameters for Nexus"
+caption="Parameters for Nexus"
+max-width="50%"
+%}
+
+Then copy/paste the [Codefresh YAML file](https://github.com/codefresh-contrib/plain-jar-sample-lib/blob/master/codefresh.yml) in the pipeline editor.
+Here are the full contents of the file:
+
+ `codefresh.yml`
+{% highlight yaml %}
+{% raw %}
+version: '1.0'
+steps:
+ main_clone:
+ title: Cloning main repository...
+ type: git-clone
+ repo: 'codefresh-contrib/plain-jar-sample-lib'
+ revision: master
+ git: github
+ publish_jar:
+ title: Upload to nexus
+ image: 'maven:3.5.2-jdk-8-alpine'
+ commands:
+ - mvn -Dmaven.repo.local=/codefresh/volume/m2_repository -s settings.xml -Dserver.password=${{NEXUS_PASS}} -Dserver.username=${{NEXUS_USER}} deploy
+{% endraw %}
+{% endhighlight %}
+
+The pipeline starts by checking out the code using a [git clone step]({{site.baseurl}}/docs/pipelines/steps/git-clone/). The next step is a [freestyle]({{site.baseurl}}/docs/pipelines/steps/freestyle/) one and packages the jar file. We also use the [Codefresh volume for caching]({{site.baseurl}}/docs/pipelines/pipeline-caching/#traditional-build-caching).
+
+You can define the version of Maven/JDK you want to use by picking the appropriate image from Dockerhub, or using any of your own images (even from [external registries]({{site.baseurl}}/docs/docker-registries/external-docker-registries/)).
+
+Note the use of the two user-defined environment variables passed to `server.password` and `server.username`. You will need to define those yourself. See the documentation on [User Procided Variables]({{site.baseurl}}/docs/pipelines/variables/#user-provided-variables).
+{% include image.html
+lightbox="true"
+file="/images/examples/java/publish-jar-pipeline.png"
+url="/images/examples/java/publish-jar-pipeline.png"
+alt="Publish JAR pipeline"
+caption="Publish JAR pipeline"
+max-width="100%"
+%}
+
+Once the pipeline has finished you should see the JAR file in the Nexus browser UI.
+
+{% include image.html
+lightbox="true"
+file="/images/examples/java/nexus-upload.png"
+url="/images/examples/java/nexus-upload.png"
+alt="Upload finished"
+caption="Upload finished"
+max-width="70%"
+%}
+
+You can use the same pipeline for Artifactory or any other compliant Java package registry.
+
+
+## Related articles
+[Gradle example]({{site.baseurl}}/docs/example-catalog/ci-examples/gradle/)
+[Spring boot example]({{site.baseurl}}/docs//example-catalog/ci-examples/spring-boot-2/)
+[Codefresh YAML for pipeline definitions]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/)
+[Steps in pipelines]({{site.baseurl}}/docs/pipelines/steps/)
+[Creating pipelines]({{site.baseurl}}/docs/pipelines/pipelines/)
+[How Codefresh pipelines work]({{site.baseurl}}/docs/pipelines/introduction-to-codefresh-pipelines/)
+
+
+
+
+
+
diff --git a/_docs/example-catalog/ci-examples/python.md b/_docs/example-catalog/ci-examples/python.md
new file mode 100644
index 000000000..249b701a5
--- /dev/null
+++ b/_docs/example-catalog/ci-examples/python.md
@@ -0,0 +1,11 @@
+---
+title: "Python"
+description: ""
+group: example-catalog
+redirect_from:
+ - /docs/python/
+toc: true
+---
+This section contains Codefresh examples based on Python.
+- [Voting app]({{ site.baseurl }}/docs/example-catalog/ci-examples/voting-app/)
+- [Django]({{ site.baseurl }}/docs/learn-by-example/python/django/)
diff --git a/_docs/learn-by-example/nodejs/react.md b/_docs/example-catalog/ci-examples/react.md
similarity index 75%
rename from _docs/learn-by-example/nodejs/react.md
rename to _docs/example-catalog/ci-examples/react.md
index e79b7a5bc..4da2f4a71 100644
--- a/_docs/learn-by-example/nodejs/react.md
+++ b/_docs/example-catalog/ci-examples/react.md
@@ -1,16 +1,18 @@
---
title: "React example with Yarn"
description: "Create Docker images for React applications"
-group: learn-by-example
+group: example-catalog
sub_group: nodejs
+redirect_from:
+ - /docs/learn-by-example/nodejs/react/
toc: true
---
-
+
Codefresh can work with React projects as with any [Node.js project]({{site.baseurl}}/docs/learn-by-example/nodejs/).
## The example React project
-You can see the example project at [https://github.com/codefresh-contrib/react-sample-app](https://github.com/codefresh-contrib/react-sample-app). The repository contains a React starter project with the following tasks:
+You can see the example project at [https://github.com/codefresh-contrib/react-sample-app](https://github.com/codefresh-contrib/react-sample-app){:target:"\_blank"}. The repository contains a React starter project with the following tasks:
* `yarn test` runs unit tests.
* `yarn start` to start the application locally.
@@ -20,7 +22,7 @@ Once launched the application presents a simple page at localhost:3000.
## React and Docker (multi-stage builds)
-The easiest way to build a React.JS application is with [multi-stage builds](https://blog.docker.com/2017/07/multi-stage-builds/). With multi-stage builds a Docker build can use one base image for packaging/unit tests and a different one that will hold the runtime of the application. This makes the final image more secure and smaller in size (as it does not contain any development/debugging tools).
+The easiest way to build a React.JS application is with [multi-stage builds](https://blog.docker.com/2017/07/multi-stage-builds/){:target:"\_blank"}. With multi-stage builds a Docker build can use one base image for packaging/unit tests and a different one that will hold the runtime of the application. This makes the final image more secure and smaller in size (as it does not contain any development/debugging tools).
In the case of React, you can use a base image that has Node and all testing utilities, while the final image has your server (e.g. nginx) with the static content and nothing else.
@@ -57,18 +59,18 @@ The resulting is very small, as it contains only packaged/minified files.
## Create a CI pipeline for React.js (Docker build)
-Creating a CI/CD pipeline for React is very easy, because Codefresh can run any [node image](https://hub.docker.com/_/node/) that you wish.
+Creating a CI/CD pipeline for React is very easy, because Codefresh can run any [node image](https://hub.docker.com/_/node/){:target:"\_blank"} that you wish.
{% include image.html
lightbox="true"
-file="/images/learn-by-example/nodejs/react-pipeline-docker.png"
-url="/images/learn-by-example/nodejs/react-pipeline-docker.png"
+file="/images/examples/nodejs/react-pipeline-docker.png"
+url="/images/examples/nodejs/react-pipeline-docker.png"
alt="Creating a Docker image for react.js"
caption="Creating a Docker image for react.js"
max-width="80%"
%}
-Here is the [full pipeline](https://github.com/codefresh-contrib/gradle-sample-app/blob/master/codefresh.yml) that creates the Docker image after checking out the code.
+Here is the [full pipeline](https://github.com/codefresh-contrib/gradle-sample-app/blob/master/codefresh.yml){:target:"\_blank"} that creates the Docker image after checking out the code.
`codefresh.yml`
{% highlight yaml %}
@@ -118,14 +120,14 @@ If your application is not dockerized yet, you can still create a pipeline that
{% include image.html
lightbox="true"
-file="/images/learn-by-example/nodejs/react-pipeline-build.png"
-url="/images/learn-by-example/nodejs/react-pipeline-build.png"
+file="/images/examples/nodejs/react-pipeline-build.png"
+url="/images/examples/nodejs/react-pipeline-build.png"
alt="Building a Reach.js application"
caption="Building a Reach.js application"
max-width="80%"
%}
-Here is the [full pipeline](https://github.com/codefresh-contrib/react-sample-app/blob/master/codefresh-only-build.yml) that creates a production deployment of all files.
+Here is the [full pipeline](https://github.com/codefresh-contrib/react-sample-app/blob/master/codefresh-only-build.yml){:target:"\_blank"} that creates a production deployment of all files.
`codefresh.yml`
{% highlight yaml %}
@@ -165,10 +167,8 @@ Notice that for demonstration purposes we uses node 11 for the tests, and node 8
Even when you don't create a Docker image, Codefresh still caches your workspace volume. This means that `node_modules` are downloaded only once. All subsequent builds will be much faster.
-## What to read next
-
-* [Node examples]({{site.baseurl}}/docs/learn-by-example/nodejs/)
-* [Codefresh YAML]({{site.baseurl}}/docs/codefresh-yaml/what-is-the-codefresh-yaml/)
-* [Pipeline steps]({{site.baseurl}}/docs/codefresh-yaml/steps/)
-* [Creating pipelines]({{site.baseurl}}/docs/configure-ci-cd-pipeline/pipelines/)
-* [How pipelines work]({{site.baseurl}}/docs/configure-ci-cd-pipeline/introduction-to-codefresh-pipelines/)
+## Related articles
+[Codefresh YAML for pipeline definitions]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/)
+[Steps in pipelines]({{site.baseurl}}/docs/pipelines/steps/)
+[Creating pipelines]({{site.baseurl}}/docs/pipelines/pipelines/)
+[How Codefresh pipelines work]({{site.baseurl}}/docs/pipelines/introduction-to-codefresh-pipelines/)
\ No newline at end of file
diff --git a/_docs/example-catalog/ci-examples/ruby.md b/_docs/example-catalog/ci-examples/ruby.md
new file mode 100644
index 000000000..c1304915c
--- /dev/null
+++ b/_docs/example-catalog/ci-examples/ruby.md
@@ -0,0 +1,185 @@
+---
+title: "Ruby"
+description: "How to build a Ruby On Rails project in Codefresh"
+group: example-catalog
+sub_group: ci-examples
+redirect_from:
+ - /docs/learn-by-example/ruby/
+toc: true
+---
+Ruby on Rails is a very popular development framework that combines ease of use and a great amount of programming languages. In Codefresh, ROR projects behave like any other web application. You can easily build them, run [integration tests]({{site.baseurl}}/docs/testing/integration-tests/) and launch them on [demo environments]({{site.baseurl}}/docs/getting-started/on-demand-environments/).
+
+The example application is located at [https://github.com/codefresh-contrib/ruby-on-rails-sample-app](https://github.com/codefresh-contrib/ruby-on-rails-sample-app){:target:"\_blank"}.
+
+
+
+## Dockerize your Ruby on Rails project
+
+The first step should be to write a [Dockerfile](https://github.com/codefresh-contrib/ruby-on-rails-sample-app/blob/master/Dockerfile){:target:"\_blank"} for your Rails project. As an example we will use the following:
+
+
+
+`Dockerfile`
+{% highlight docker %}
+FROM ruby:2.3.1-slim
+
+RUN apt-get update && \
+ apt-get install -y build-essential libcurl4-openssl-dev libxml2-dev libsqlite3-dev libpq-dev nodejs postgresql-client sqlite3 --no-install-recommends && \
+ apt-get clean && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*
+
+# throw errors if Gemfile has been modified since Gemfile.lock
+RUN bundle config --global frozen 1
+
+ENV APP_PATH /usr/src/app
+
+RUN mkdir -p $APP_PATH
+
+COPY Gemfile $APP_PATH
+COPY Gemfile.lock $APP_PATH
+
+WORKDIR $APP_PATH
+
+RUN bundle install
+
+COPY . $APP_PATH
+
+ENV RAILS_ENV development
+
+RUN bin/rake db:migrate
+
+RUN bin/rake assets:precompile
+
+EXPOSE 3000
+
+CMD ["bundle", "exec", "rails", "server", "-b", "0.0.0.0"]
+
+{% endhighlight %}
+
+Notice the order of commands and especially the fact that we copy the `Gemfile` on its own first, so that we take advantage of the Docker layer caching.
+
+>Codefresh also supports multi-stage docker builds. You can use one parent docker image for preparing your gem modules and another one for actually deployment the application.
+
+Once you have a Dockerfile, [creating a pipeline in Codefresh]({{site.baseurl}}/docs/pipelines/pipelines/) is very easy either from the GUI or with the yaml syntax.
+
+## Simple pipeline with Docker image and unit tests
+
+A very simple pipeline is one that has only two steps:
+
+1. Build the docker image
+1. Run the tests inside the docker image that was just build
+
+Here is the example [codefresh.yml](https://github.com/codefresh-contrib/ruby-on-rails-sample-app/blob/master/codefresh.yml){:target:"\_blank"} file.
+
+
+`codefresh.yml`
+{% highlight yaml %}
+{% raw %}
+version: '1.0'
+steps:
+ main_clone:
+ title: Cloning main repository...
+ type: git-clone
+ repo: 'codefresh-contrib/ruby-on-rails-sample-app'
+ revision: master
+ git: github
+ BuildingDockerImage:
+ title: Building Docker Image
+ type: build
+ image_name: ruby-on-rails-sample-app
+ working_directory: ./
+ tag: '${{CF_BRANCH_TAG_NORMALIZED}}'
+ dockerfile: Dockerfile
+ RunningUnitTests:
+ title: Running Unit Tests
+ image: '${{BuildingDockerImage}}'
+ commands:
+ - rails db:migrate
+ - rails test
+{% endraw %}
+{% endhighlight %}
+
+The first step is a [build step]({{site.baseurl}}/docs/pipelines/steps/build/) named `BuildingDockerImage`. It reads the Dockerfile and creates a Docker image out of it. The second step is a [freestyle step]({{site.baseurl}}/docs/pipelines/steps/freestyle/) called `RunningUnitTests`. It uses the image mentioned in the first step and executes custom commands inside it.
+
+
+## Inspecting your Docker image
+
+You can see all your latest [Docker artifacts]({{site.baseurl}}/docs/ci-cd-guides/working-with-docker-registries/#viewing-docker-images) by selecting *Images* from the left sidebar.
+
+
+{% include image.html
+lightbox="true"
+file="/images/examples/ruby/images.png"
+url="/images/examples/ruby/images.png"
+alt="Codefresh built-in Registry"
+caption="Codefresh built-in Registry"
+max-width="80%"
+%}
+
+You can click on the image and get extra details. One of the tabs contains a visual explanation of the layers contained in the image. This view can be helpful when you are trying to make your Docker images smaller (which is a recommended practice)
+
+{% include image.html
+lightbox="true"
+file="/images/examples/ruby/layers.png"
+url="/images/examples/ruby/layers.png"
+alt="Ruby On Rails image filesystem layers"
+caption="Ruby On Rails Image filesystem layers"
+max-width="70%"
+%}
+
+In Codefresh you can also use any other [external registry]({{site.baseurl}}/docs/docker-registries/external-docker-registries/) such as Dockerhub, Azure, Google etc.
+
+
+## Previewing the Ruby on Rails application in a Demo environment
+
+Codefresh has the unique capability of launching Docker images within its infrastructure for a quick demonstration (e.g. to customers and colleagues).
+
+In the example Rails repository, the default development "environment" is self-contained (it uses sqlite for a database). This makes it very easy to preview.
+
+Launch the environment by clicking at the rocket icon in the images view.
+
+{% include image.html
+lightbox="true"
+file="/images/examples/ruby/launch.png"
+url="/images/examples/ruby/launch.png"
+alt="Launching a demo environment"
+caption="Launching a demo environment"
+max-width="50%"
+%}
+
+A new build will start. Once it is complete your new environment will be created. You can inspect it by clicking in the *Compositions* menu on the left sidebar and then clicking *Running Compositions*.
+
+{% include image.html
+lightbox="true"
+file="/images/examples/ruby/environment.png"
+url="/images/examples/ruby/environment.png"
+alt="Inspecting a demo environment"
+caption="Inspecting a demo environment"
+max-width="70%"
+%}
+
+Click the *Open App* icon on the right and your browser will open a new tab with the environment.
+
+{% include image.html
+lightbox="true"
+file="/images/examples/ruby/preview.png"
+url="/images/examples/ruby/preview.png"
+alt="Previewing a demo environment"
+caption="Previewing a demo environment"
+max-width="50%"
+%}
+
+
+You can share this link with other people in your team.
+
+>Demo environments are not intended for production purposes. Use them only for quick feedback. They also shutdown automatically after a period of inactivity.
+
+
+
+## Related articles
+[Introduction to Pipelines]({{site.baseurl}}/docs/pipelines/introduction-to-codefresh-pipelines/)
+[Codefresh YAML for pipeline definitions]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/)
+[On demand environments]({{site.baseurl}}/docs/getting-started/on-demand-environments/)
+[Integration tests]({{site.baseurl}}/docs/testing/integration-tests/)
+
+
+
diff --git a/_docs/example-catalog/ci-examples/run-integration-tests.md b/_docs/example-catalog/ci-examples/run-integration-tests.md
new file mode 100644
index 000000000..256a7c1b5
--- /dev/null
+++ b/_docs/example-catalog/ci-examples/run-integration-tests.md
@@ -0,0 +1,103 @@
+---
+title: "Run integration tests"
+description: "Launch separate App and test containers"
+group: example-catalog
+sub_group: ci-examples
+redirect_from:
+ - /docs/yaml-examples/examples/run-integration-tests/
+ - /docs/run-integration-tests/
+ - /docs/learn-by-example/general/selenium-test/
+toc: true
+---
+In this example, we will see a Java/Tomcat project using JUnit for unit tests and Spock for integration tests. For the integration test phase, we will launch both the application and the tests in order to run the integration tests against a real web instance (without mocking).
+
+{% include image.html
+lightbox="true"
+file="/images/examples/integration-tests/integration-tests.png"
+url="/images/examples/integration-tests/integration-tests.png"
+alt="Integration tests with Codefresh"
+caption="Integration tests with Codefresh"
+max-width="90%"
+%}
+
+The integration tests will look at the application instance at `app:8080`.
+
+## Example Java/Tomcat/Spring project
+
+You can see the example project at [https://github.com/codefreshdemo/cf-example-integration-tests](https://github.com/codefreshdemo/cf-example-integration-tests){:target="\_blank"}. The repository contains the Java source code and some integration tests.
+
+You can play with it locally by using Docker compose to launch both the application and the tests.
+
+## Create a pipeline with separate integration tests
+
+Here is the whole pipeline:
+
+ `codefresh.yml`
+{% highlight yaml %}
+{% raw %}
+version: "1.0"
+stages:
+ - prepare
+ - build
+ - test
+steps:
+ main_clone:
+ type: "git-clone"
+ description: "Cloning main repository..."
+ repo: "codefreshdemo/cf-example-integration-tests"
+ revision: "master"
+ git: github
+ stage: prepare
+ build_app_image:
+ title: "Building Docker Image"
+ type: "build"
+ image_name: "my-spring-app"
+ tag: "master"
+ dockerfile: "Dockerfile"
+ stage: build
+ build_test_image:
+ title: "Building Docker Test Image"
+ type: "build"
+ image_name: "my-junit-spock-tests"
+ tag: "master"
+ dockerfile: "Dockerfile.testing"
+ stage: test
+ run_integration_tests:
+ title: "Running integration tests"
+ stage: test
+ image: '${{build_test_image}}'
+ commands:
+ # Tomcat is certainly up at this point
+ - mvn verify -Dserver.host=app
+ services:
+ composition:
+ app:
+ image: '${{build_app_image}}'
+ ports:
+ - 8080
+ readiness:
+ timeoutSeconds: 30
+ periodSeconds: 15
+ image: byrnedo/alpine-curl
+ commands:
+ - "curl http://app:8080/wizard/"
+
+{% endraw %}
+{% endhighlight %}
+
+This pipeline does the following:
+
+1. Clones the source code through a [Git clone step]({{site.baseurl}}/docs/pipelines/steps/git-clone/).
+1. Builds a Docker image with only Tomcat and the application WAR through a [build step]({{site.baseurl}}/docs/pipelines/steps/build/).
+1. Builds a helper image that contains the source code and Maven to run integration tests.
+1. Runs the `mvn verify` command in the helper image while launching a [service container]({{site.baseurl}}/docs/pipelines/service-containers/) with the Tomcat/Java image.
+
+Notice that we also use the `readiness` property in the testing phase to verify that the application
+is actually up, before running the tests.
+
+## Related articles
+[CI pipeline examples]({{site.baseurl}}/docs/example-catalog/examples/#ci-examples)
+[Integration tests with Postgres]({{site.baseurl}}/docs/example-catalog/ci-examples/integration-tests-with-postgres/)
+[Integration tests with MySQL]({{site.baseurl}}/docs/example-catalog/ci-examples/integration-tests-with-mysql/)
+[Integration tests with Mongo]({{site.baseurl}}/docs/example-catalog/ci-examples/integration-tests-with-mongo/)
+[Integration tests with Redis]({{site.baseurl}}/docs/example-catalog/ci-examples/integration-tests-with-redis/)
\ No newline at end of file
diff --git a/_docs/example-catalog/ci-examples/run-unit-tests.md b/_docs/example-catalog/ci-examples/run-unit-tests.md
new file mode 100644
index 000000000..9dde03a78
--- /dev/null
+++ b/_docs/example-catalog/ci-examples/run-unit-tests.md
@@ -0,0 +1,107 @@
+---
+title: "Run unit tests"
+description: "Running unit tests in Codefresh pipelines"
+group: example-catalog
+sub_group: ci-examples
+redirect_from:
+ - /docs/yaml-examples/examples/run-unit-tests/
+ - /docs/run-unit-tests/
+toc: true
+---
+
+As explained in [unit tests]({{site.baseurl}}/docs/testing/unit-tests/), Codefresh supports several ways of running unit tests. The most common scenarios use an existing Docker Hub image (common with compiled languages such as Java and Go), or the application image itself (common with languages such as JavaScript/Python/Ruby/PHP).
+
+In this example, we will see both ways using two different applications in a single pipeline.
+
+{% include image.html
+lightbox="true"
+file="/images/examples/unit-tests/unit-tests-pipeline.png"
+url="/images/examples/unit-tests/unit-tests-pipeline.png"
+alt="Unit tests with Codefresh"
+caption="Unit tests with Codefresh"
+max-width="90%"
+%}
+
+In the first case, we run unit tests *before* creating the application docker image. In the second case, we run the unit tests
+*inside* the application Docker image.
+
+## Example Python/Go project
+
+You can see the example project at [https://github.com/codefreshdemo/cf-example-unit-test](https://github.com/codefreshdemo/cf-example-unit-test){:target="\_blank"}. The repository contains two applications (Python and Go) with their respective unit tests.
+
+You can play with it locally by using Docker commands to package the applications.
+
+## Create a pipeline with unit tests
+
+Here is the whole pipeline:
+
+ `codefresh.yml`
+{% highlight yaml %}
+{% raw %}
+version: '1.0'
+stages:
+ - prepare
+ - 'Microservice A'
+ - 'Microservice B'
+steps:
+ main_clone:
+ title: Cloning main repository...
+ type: git-clone
+ repo: 'codefreshdemo/cf-example-unit-test'
+ revision: 'master'
+ git: github
+ stage: prepare
+ run_my_tests_before_build:
+ title: Running Unit tests directly
+ stage: 'Microservice A'
+ image: golang:1.12
+ working_directory: './golang-app-A'
+ commands:
+ - go test -v
+ build_after_my_tests:
+ title: Building Go Docker Image
+ type: build
+ stage: 'Microservice A'
+ image_name: my-go-image
+ working_directory: './golang-app-A'
+ tag: 'master'
+ dockerfile: Dockerfile
+ build_before_my_tests:
+ title: Building Python Docker Image
+ type: build
+ stage: 'Microservice B'
+ image_name: my-python-image
+ working_directory: './python-app-B'
+ tag: 'master'
+ dockerfile: Dockerfile
+ run_my_tests_inside_image:
+ title: Running Unit tests inside App image
+ stage: 'Microservice B'
+ image: ${{build_before_my_tests}}
+ working_directory: '/app'
+ commands:
+ - python setup.py test
+{% endraw %}
+{% endhighlight %}
+
+This pipeline does the following:
+
+1. Clones the source code through a [Git clone step]({{site.baseurl}}/docs/pipelines/steps/git-clone/).
+1. Runs unit test for the GO application using the Dockerhub image `golang:1.12`.
+1. Builds the Docker image for the Go application through a [build step]({{site.baseurl}}/docs/pipelines/steps/build/).
+1. Builds the Docker image for the Python application.
+1. Runs unit tests for the Python application using as runtime context the application image that was just created.
+
+
+In the second case, the tests run in the context of `build_before_my_tests` which is the name of the step that creates the Docker image for Python. Read more about [context variables]({{site.baseurl}}/docs/pipelines/variables/#context-related-variables).
+
+We generally recommend the first approach, so that your production Docker image does not contain any unit testing libraries or frameworks, but there is no right or wrong choice regarding the way you run unit tests.
+
+## Related articles
+[CI pipeline examples]({{site.baseurl}}/docs/example-catalog/examples/#ci-examples)
+[Unit tests]({{site.baseurl}}/docs/testing/unit-tests/)
+[Integration test example]({{site.baseurl}}/docs/example-catalog/ci-examples/run-integration-tests/)
+[Service containers in pipelines]({{site.baseurl}}/docs/pipelines/service-containers/)
+[Steps in pipelines]({{site.baseurl}}/docs/pipelines/steps/)
+
+
diff --git a/_docs/example-catalog/ci-examples/rust.md b/_docs/example-catalog/ci-examples/rust.md
new file mode 100644
index 000000000..053ea596a
--- /dev/null
+++ b/_docs/example-catalog/ci-examples/rust.md
@@ -0,0 +1,86 @@
+---
+title: "Compile and test a Rust application"
+description: "Using Codefresh pipelines"
+group: example-catalog
+sub_group: ci-examples
+redirect_from:
+ - /docs/learn-by-example/rust/
+toc: true
+---
+
+Codefresh can work with any Rust application very easily as both `rustc` and `cargo` are already offered in Dockerhub.
+
+## The example Rust project
+
+You can see the example project at [https://github.com/codefresh-contrib/rust-sample-app](https://github.com/codefresh-contrib/rust-sample-app){:target="\_blank"}. The repository contains a Rust starter project with a dummy unit test.
+
+* `cargo build` compiles the code.
+* `cargo test` runs unit tests
+* `cargo clean` removes artifacts and binaries.
+
+
+## Create a CI pipeline for Rust applications
+
+Creating a CI/CD pipeline for Rust is very easy, because Codefresh can run any [Rust image](https://hub.docker.com/_/rust){:target="\_blank"} that you wish. Rust docker images already contain the `cargo` package manager.
+
+{% include image.html
+lightbox="true"
+file="/images/examples/rust/rust-pipeline.png"
+url="/images/examples/rust/rust-pipeline.png"
+alt="Compiling a Rust application in a pipeline"
+caption="Compiling a Rust application in a pipeline"
+max-width="80%"
+%}
+
+Here is the [full pipeline](https://github.com/codefresh-contrib/rust-sample-app/blob/master/codefresh.yml){:target="\_blank"} that compiles the application after checking out the code.
+
+ `codefresh.yml`
+{% highlight yaml %}
+{% raw %}
+version: "1.0"
+stages:
+ - "clone"
+ - "build"
+ - "test"
+steps:
+ clone:
+ title: "Cloning repository"
+ type: "git-clone"
+ repo: "codefresh-contrib/rust-sample-app"
+ revision: "master"
+ stage: "clone"
+ compile:
+ title: "Building Code"
+ type: "freestyle"
+ image: "rust:1.44-stretch"
+ working_directory: "${{clone}}"
+ environment:
+ - CARGO_HOME=/codefresh/volume/cargo
+ commands:
+ - "cargo build"
+ stage: "build"
+ test:
+ title: "Running tests"
+ type: "freestyle"
+ image: "rust:1.44-stretch"
+ working_directory: "${{clone}}"
+ environment:
+ - CARGO_HOME=/codefresh/volume/cargo
+ commands:
+ - "cargo test"
+ stage: "test"
+
+{% endraw %}
+{% endhighlight %}
+
+This pipeline clones the source code, compiles the code and runs unit tests. In all cases we use the public Docker image of Rust that also contains `cargo`.
+
+We also pass the `CARGO_HOME` environment variable to place the Cargo cache on the [shared Codefresh volume]({{site.baseurl}}/docs/pipelines/introduction-to-codefresh-pipelines/#sharing-the-workspace-between-build-steps). See the [Caching documentation]({{site.baseurl}}/docs/pipelines/pipeline-caching/#traditional-build-caching) for more details.
+
+
+
+## Related articles
+[Codefresh YAML for pipeline definitions]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/)
+[Steps in pipelines]({{site.baseurl}}/docs/pipelines/steps/)
+[Creating pipelines]({{site.baseurl}}/docs/pipelines/pipelines/)
+[How Codefresh pipelines work]({{site.baseurl}}/docs/pipelines/introduction-to-codefresh-pipelines/)
\ No newline at end of file
diff --git a/_docs/learn-by-example/scala/scala-hello-world.md b/_docs/example-catalog/ci-examples/scala-hello-world.md
similarity index 77%
rename from _docs/learn-by-example/scala/scala-hello-world.md
rename to _docs/example-catalog/ci-examples/scala-hello-world.md
index 629da23d8..8055ff6d6 100644
--- a/_docs/learn-by-example/scala/scala-hello-world.md
+++ b/_docs/example-catalog/ci-examples/scala-hello-world.md
@@ -2,9 +2,10 @@
title: "Scala: Hello World"
description: "Use Scala and Codefresh to clone, package, and build a Docker image"
excerpt: ""
-group: learn-by-example
-sub_group: scala
+group: example-catalog
+sub_group: ci-examples
redirect_from:
+ - /docs/learn-by-example/scala/scala-hello-world/
- /docs/scala-hello-world/
toc: true
---
@@ -21,7 +22,7 @@ We’ll help you get up to speed with basic functionality such as: compiling, bu
This project uses `Scala` to build an application which will eventually become a distributable Docker image.
-You can find the example application on [GitHub](https://github.com/codefresh-contrib/scala-hello-world-app).
+You can find the example application on [GitHub](https://github.com/codefresh-contrib/scala-hello-world-app){:target="\_blank"}.
There are two pipeline examples provided in this tutorial:
@@ -100,9 +101,9 @@ steps:
The above pipeline does the following:
-1. A [git-clone]({{site.baseurl}}/docs/codefresh-yaml/steps/git-clone/) step that clones the main repository
-2. A [freestyle step]({{site.baseurl}}/docs/codefresh-yaml/steps/freestyle/) that uses an SBT image that packages the application (note how `sbt.ivy.home` is set to an arbitrarily named directory that is part of the codefresh volume). This ensures we cache dependencies to [speed up builds]({{site.baseurl}}/docs/learn-by-example/java/spring-boot-2/#caching-the-maven-dependencies), similar to Maven.
-3. The last step, `build_image`, is a [build step]({{site.baseurl}}/docs/codefresh-yaml/steps/build/) that builds a Docker image using the Dockerfile provided in the repository.
+1. A [git-clone]({{site.baseurl}}/docs/pipelines/steps/git-clone/) step that clones the main repository
+2. A [freestyle step]({{site.baseurl}}/docs/pipelines/steps/freestyle/) that uses an SBT image that packages the application (note how `sbt.ivy.home` is set to an arbitrarily named directory that is part of the codefresh volume). This ensures we cache dependencies to [speed up builds]({{site.baseurl}}/docs/example-catalog/ci-examples/spring-boot-2/#caching-the-maven-dependencies), similar to Maven.
+3. The last step, `build_image`, is a [build step]({{site.baseurl}}/docs/pipelines/steps/build/) that builds a Docker image using the Dockerfile provided in the repository.
## Example Pipeline #2: Multi-stage Docker Build
@@ -174,12 +175,11 @@ steps:
{% endraw %}
{% endhighlight %}
-1. A [git-clone]({{site.baseurl}}/docs/codefresh-yaml/steps/git-clone/) step that clones the main repository
-2. A [build step]({{site.baseurl}}/docs/codefresh-yaml/steps/freestyle/) that builds our code into a Docker image using the Dockerfile present in the repository
+1. A [git-clone]({{site.baseurl}}/docs/pipelines/steps/git-clone/) step that clones the main repository
+2. A [build step]({{site.baseurl}}/docs/pipelines/steps/freestyle/) that builds our code into a Docker image using the Dockerfile present in the repository
-## What to Read Next
+## Related articles
+[Codefresh YAML for pipeline definitions]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/)
+[Freestyle Step]({{site.baseurl}}/docs/pipelines/steps/freestyle/)
-- [Codefresh YAML]({{site.baseurl}}/docs/codefresh-yaml/what-is-the-codefresh-yaml/)
-- [Git-clone Step]({{site.baseurl}}/docs/codefresh-yaml/steps/git-clone/)
-- [Freestyle Step]({{site.baseurl}}/docs/codefresh-yaml/steps/freestyle/)
diff --git a/_docs/learn-by-example/scala.md b/_docs/example-catalog/ci-examples/scala.md
similarity index 90%
rename from _docs/learn-by-example/scala.md
rename to _docs/example-catalog/ci-examples/scala.md
index 5a0991f48..7415259d2 100644
--- a/_docs/learn-by-example/scala.md
+++ b/_docs/example-catalog/ci-examples/scala.md
@@ -1,7 +1,7 @@
---
title: "Scala"
description: ""
-group: learn-by-example
+group: example-catalog
redirect_from:
- /docs/scala/
toc: true
diff --git a/_docs/example-catalog/ci-examples/sending-the-notification-to-jira.md b/_docs/example-catalog/ci-examples/sending-the-notification-to-jira.md
new file mode 100644
index 000000000..13f852c56
--- /dev/null
+++ b/_docs/example-catalog/ci-examples/sending-the-notification-to-jira.md
@@ -0,0 +1,90 @@
+---
+title: "Send notification to Jira"
+description: ""
+group: example-catalog
+sub_group: ci-examples
+redirect_from:
+ - /docs/yaml-examples/examples/sending-the-notification-to-jira/
+toc: true
+---
+
+The plugin marketplace offers several freestyle steps for your Codefresh pipeline.
+
+One of those steps is the [Jira Issue Manager](https://codefresh.io/steps/step/jira-issue-manager){:target="\_blank"}.
+
+## Prerequisites
+* [Codefresh pipeline]({{site.baseurl}}/docs/quick-start/ci-quick-start/create-ci-pipeline/)
+* [Jira account](https://www.atlassian.com/software/jira){:target="\_blank"}
+
+## Example
+This documentation uses the following [example](https://github.com/codefresh-contrib/jira-demo-app){:target="\_blank"}. You can either use the example provided to try out the Jira integration or follow along with your own application.
+
+1. You need an issue in your Jira account that you want to link to your Codefresh pipeline. If you do not have one yet, please create an issue. (Note that the project type and who is creating the issue etc. does not matter.) Alternatively, you can also create an issue first with the Jira step. However, this is not explained in this example.
+
+2. Next, add the following step to your Codefresh pipeline. In case you are using the example, the [codefresh.yml](https://github.com/codefresh-contrib/jira-demo-app/blob/master/codefresh.yml){:target="\_blank"} file is already added.
+
+{% highlight yaml %}
+ JiraCommentCreate:
+ title: "Add Jira Comment"
+ type: "jira-issue-manager"
+ stage: "deploy"
+ arguments:
+ JIRA_BASE_URL: '${{JIRA_BASE_URL}}'
+ JIRA_USERNAME: '${{JIRA_USERNAME}}'
+ JIRA_API_KEY: '${{JIRA_API_KEY}}'
+ JIRA_ISSUE_SOURCE_FIELD: '${{JIRA_ISSUE_SOURCE_FIELD}}'
+ ACTION: "comment_create"
+ COMMENT_BODY: "Build number ${{CF_BUILD_URL}} finished in Codefresh"
+{% endhighlight yaml %}
+
+Let's look in detail at this step.
+- Everything up to the arguments is similar to other Codefresh steps.
+
+These arguments are required to use the step:
+- `JIRA_BASE_URL`: This is the url of your organisation e.g. 'https://company-name.atlassian.net'
+- `JIRA_USERNAME`: This is usually the e-mail that you are logged in with at Jira
+- `JIRA_API_KEY`: Note that you will have to create this key. The official [Atlassian documentation](https://confluence.atlassian.com/cloud/api-tokens-938839638.html){:target="\_blank"} details how it can be created.
+
+Then we added these arguments for our specific step:
+- `JIRA_ISSUE_SOURCE_FIELD`: This is the tag that identifies your issue, for example, `MKTG-102`
+- Within the comment, we use a [Codefresh native variable]({{site.baseurl}}/docs/pipelines/variables/) `CF_BUILD_URL`, which references your pipeline build and allows you to search for your pipeline.
+
+All variables use the Codefresh-specific variable notation ${% raw %}`{{MY_VARIABLE_EXAMPLE}}`{% endraw %}`.
+
+Since it is a new stage in your Codefresh pipeline, you want to add it at the top to your stages, e.g.:
+
+{% highlight yaml %}
+ stages:
+ - "clone"
+ - "build"
+ - "JiraCommentCreate"
+{% endhighlight yaml %}
+
+Note that you can [provide the variables]({{site.baseurl}}/docs/pipelines/configuration/shared-configuration/) needed for the Jira step directly in the shared configuration. The benefits are:
+* You do not have to post sensitive information, such as the API key, directly in the codefresh.yml.
+* If you use the same step across multiple pipelines, you don't have to copy-paste the same variables.
+
+Once you run the pipeline, you should be able to see the following output or similar:
+
+{% include image.html
+lightbox="true"
+file="/images/integrations/jira/codefreshpipeline.png"
+url="/images/integrations/jira/codefreshpipeline.png"
+alt="Pipeline with Jira integration"
+max-width="80%"
+%}
+
+And the comment, including the URL to the pipeline, should be added to your Jira issue:
+
+{% include image.html
+lightbox="true"
+file="/images/integrations/jira/jira-comment.png"
+url="/images/integrations/jira/jira-comment.png"
+alt="Comment in Jira"
+max-width="80%"
+%}
+
+## Related articles
+[CI pipeline examples]({{site.baseurl}}/docs/example-catalog/#ci-examples)
+[Send notifications to Slack]({{site.baseurl}}/docs/example-catalog/ci-examples/sending-the-notification-to-slack/)
+[Create a pipeline]({{site.baseurl}}/docs/pipelines/pipelines/)
diff --git a/_docs/example-catalog/ci-examples/sending-the-notification-to-slack.md b/_docs/example-catalog/ci-examples/sending-the-notification-to-slack.md
new file mode 100644
index 000000000..1c86c1413
--- /dev/null
+++ b/_docs/example-catalog/ci-examples/sending-the-notification-to-slack.md
@@ -0,0 +1,43 @@
+---
+title: "Send notification to Slack"
+description: "Connect your Codefresh pipelines to Slack"
+group: example-catalog
+sub_group: ci-examples
+redirect_from:
+ - /docs/yaml-examples/examples/sending-the-notification-to-slack/
+ - /docs/sending-the-notification-to-slack/
+toc: true
+---
+
+There are many ways to integrate Slack with Codefresh:
+
+1. Use the [global slack integration]({{site.baseurl}}/docs/integrations/notifications/slack-intergration/)
+1. Use individual pipeline plugins such [slack-message-sender](https://codefresh.io/steps/step/slack-message-sender){:target="\_blank"} and [slack-notifier](https://codefresh.io/steps/step/slack-notifier){:target="\_blank"}
+1. Use simple POST requests with Curl, as explained in this article
+
+## Custom webhook to Slack
+
+Use a container image with a [freestyle step]({{site.baseurl}}/docs/pipelines/steps/freestyle/) such as `byrnedo/alpine-curl` to send a notification to a Slack channel.
+
+{:start="1"}
+1. Get the {% raw %}```${{SLACK_WEB_URL}}```{% endraw %} and put it in the Environment Variables or use [shared configuration]({{site.baseurl}}/docs/pipelines/configuration/shared-configuration/).
+
+ > To integrate with Slack, see [https://api.slack.com/incoming-webhooks](https://api.slack.com/incoming-webhooks){:target="_blank"}.
+
+{:start="2"}
+2. Add the following step to your `codefresh.yml`:
+
+ `slack step`
+{% highlight yaml %}
+slack_notify:
+ image: byrnedo/alpine-curl # curlimages/curl, or any other curl image
+ commands:
+ - curl -X POST --data-urlencode 'payload={"text":"Test slack integration via yaml"}' {% raw %}${{SLACK_WEB_URL}}{% endraw %}
+{% endhighlight %}
+
+
+## Related articles
+[CI pipeline examples]({{site.baseurl}}/docs/example-catalog/examples/#ci-examples)
+[Advanced workflows]({{site.baseurl}}/docs/pipelines/advanced-workflows/)
+[Hooks in pipelines]({{site.baseurl}}/docs/pipelines/hooks/)
+
diff --git a/_docs/example-catalog/ci-examples/shared-volumes-between-builds.md b/_docs/example-catalog/ci-examples/shared-volumes-between-builds.md
new file mode 100644
index 000000000..062cf5b2b
--- /dev/null
+++ b/_docs/example-catalog/ci-examples/shared-volumes-between-builds.md
@@ -0,0 +1,115 @@
+---
+title: "Share data between pipeline steps"
+description: "How to cache folders between steps and builds"
+group: example-catalog
+sub_group: ci-examples
+redirect_from:
+ - /docs/yaml-examples/examples/shared-volumes-between-builds/
+ - /docs/shared-volumes-between-builds/
+toc: true
+---
+
+Codefresh creates a [shared volume]({{site.baseurl}}/docs/pipelines/introduction-to-codefresh-pipelines/#sharing-the-workspace-between-build-steps) in each pipeline that is automatically shared with all freestyle steps.
+
+{% include
+image.html
+lightbox="true"
+file="/images/pipeline/introduction/codefresh-volume.png"
+url="/images/pipeline/introduction/codefresh-volume.png"
+alt="Codefresh volume"
+caption="All steps share the same volume"
+max-width="90%"
+%}
+
+This volume exists at `/codefresh/volume` by default. Simply copy files there to have them available to all Codefresh steps (as well as subsequent builds of the same pipeline).
+
+>The [Git clone step]({{site.baseurl}}/docs/pipelines/steps/git-clone/) deletes any files **not** specified in `.gitignore`. To cache a folder that exists in your project directory (such as `node_modules`), you must also add it to `.gitignore`
+
+## Using the shared volume
+
+You can see the example project at [https://github.com/codefreshdemo/cf-example-shared-volumes-between-builds](https://github.com/codefreshdemo/cf-example-shared-volumes-between-builds){:target="\_blank"}. The repository contains a simple application, a Dockerfile, and an example pipeline that saves/reads a dummy file to the Codefresh volume.
+
+
+Here is the whole pipeline:
+
+ `codefresh.yml`
+{% highlight yaml %}
+{% raw %}
+version: "1.0"
+stages:
+ - "clone"
+ - "build"
+ - "shared-volume"
+
+steps:
+ clone:
+ title: "Cloning repository"
+ type: "git-clone"
+ repo: "codefreshdemo/cf-example-shared-volumes-between-builds"
+ revision: "master"
+ stage: "clone"
+
+ build_image:
+ title: "Building image"
+ type: "build"
+ image_name: "sample-app"
+ working_directory: "${{clone}}"
+ tag: "demo"
+ dockerfile: "Dockerfile"
+ stage: "build"
+
+ copy_to_shared_volume:
+ title: "Copy file to shared volume"
+ type: "freestyle"
+ image: alpine:3.9
+ working_directory: "${{clone}}"
+ commands:
+ - ls -l /codefresh/volume/
+ - cp ./artifact/artifact.example /codefresh/volume/artifact.example
+ stage: "shared-volume"
+
+ list_shared_volume:
+ title: "List shared volume files"
+ type: "freestyle"
+ image: alpine:3.9
+ working_directory: "${{clone}}"
+ commands:
+ - pwd
+ - ls -l /codefresh/volume
+ stage: "shared-volume"
+{% endraw %}
+{% endhighlight %}
+
+This pipeline does the following:
+
+1. Clones the source code through a [Git clone step]({{site.baseurl}}/docs/pipelines/steps/git-clone/).
+1. Builds a docker image through a [build step]({{site.baseurl}}/docs/pipelines/steps/build/).
+1. Copies the file `artifact.example` to the volume through a [freestyle step]({{site.baseurl}}/docs/pipelines/steps/freestyle/).
+1. Reads the contents of the volume through a different freestyle step.
+
+If you run the pipeline, you will see the file contents in the fourth step:
+
+{% include
+image.html
+lightbox="true"
+file="/images/examples/shared-workspace/volume-list.png"
+url="/images/examples/shared-workspace/volume-list.png"
+alt="Listing volume contents"
+caption="Listing volume contents"
+max-width="80%"
+%}
+
+
+If you run the pipeline a second time, you will see the dummy file in all steps, as the volume is automatically cached for subsequent builds as well.
+
+
+## Caching build dependencies and Docker layers
+
+Read more about caching build dependencies in [caching in pipelines]({{site.baseurl}}/docs/pipelines/pipeline-caching/), and in this [blog post](https://codefresh.io/blog/caching-build-dependencies-codefresh-volumes/){:target="\_blank"}.
+
+
+
+## Related articles
+[CI/CD pipeline examples]({{site.baseurl}}/docs/example-catalog/examples/#ci-examples)
+[How Codefresh pipelines work]({{site.baseurl}}/docs/pipelines/introduction-to-codefresh-pipelines/)
+[Codefresh YAML for pipeline definitions]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/)
diff --git a/_docs/example-catalog/ci-examples/shared-volumes-of-service-from-composition-step-for-other-yml-steps.md b/_docs/example-catalog/ci-examples/shared-volumes-of-service-from-composition-step-for-other-yml-steps.md
new file mode 100644
index 000000000..29362db5b
--- /dev/null
+++ b/_docs/example-catalog/ci-examples/shared-volumes-of-service-from-composition-step-for-other-yml-steps.md
@@ -0,0 +1,46 @@
+---
+title: "Share service volumes in composition steps"
+description: "How to share data in compositions"
+group: example-catalog
+sub_group: ci-examples
+redirect_from:
+ - /docs/yaml-examples/examples/shared-volumes-of-service-from-composition-step-for-other-yml-steps/
+ - /docs/shared-volumes-of-service-from-composition-step-for-other-yml-steps/
+toc: true
+---
+Using this repository, we'll help you get up to speed with basic functionality such as building Docker images and using the shared volumes.
+
+This project uses Node Js to build an application which will eventually become a distributable Docker image.
+To share volumes of service in composition step for other yml steps you can use the variable {% raw %}```${{CF_VOLUME_NAME}}```{% endraw %}. It will refer to the volume that was generated for the specific flow. Can be used in conjunction with a composition to provide access to your cloned repository.
+
+>Read more about caching build dependencies our [blog](https://codefresh.io/blog/caching-build-dependencies-codefresh-volumes/){:target="_blank"}.
+
+## Looking around
+In the root of this repository you'll find a file named `codefresh.yml`, this is our build descriptor that describes the different steps that comprise our process. Let's quickly review the contents of this file:
+
+ `codefresh.yml`
+{% highlight yaml %}
+step_file_generation:
+ type: composition
+ composition:
+ version: '2'
+ services:
+ service1:
+ volumes:
+ - {% raw %}${{CF_VOLUME_NAME}}{% endraw %}:/codefresh/volume
+ image: {% raw %}${{build_step}}{% endraw %}
+ command: bash -c "echo hello > /codefresh/volume/myfile.txt"
+ composition_candidates:
+ test:
+ image: {% raw %}${{build_step}}{% endraw %}
+ command: echo hello
+{% endhighlight %}
+
+>Example
+ Just head over to the example [**repository**](https://github.com/codefreshdemo/cf-example-shared-volumes-composition-step){:target="_blank"} in GitHub, and follow the instructions there.
+
+The way the volume is shared between builds is that upon build completion we create an image of the volume state to be used in the next builds. If you run 2 builds in parallel from the same pipeline and at the same time, each will use the same last volume image, but it’ll run separately on both. The volume image you’ll get upon completion is the state of the build that finished last.
+
+
+## Related articles
+[CI pipeline examples]({{site.baseurl}}/docs/example-catalog/#ci-examples)
diff --git a/_docs/example-catalog/ci-examples/spring-boot-2.md b/_docs/example-catalog/ci-examples/spring-boot-2.md
new file mode 100644
index 000000000..a0a7f56e8
--- /dev/null
+++ b/_docs/example-catalog/ci-examples/spring-boot-2.md
@@ -0,0 +1,253 @@
+---
+title: "Spring Boot 2/Maven"
+description: "Create Docker images for Spring/Maven"
+excerpt: ""
+group: example-catalog
+sub_group: ci-examples
+redirect_from:
+ - /docs/learn-by-example/java/spring-boot-2/
+ - /docs/spring-boot-2/
+ - /docs/java/spring-boot-2/
+toc: true
+---
+
+Spring Boot is quickly becoming a very popular choice for building Java back-end applications. Compared to traditional application servers,it is a bit different since it includes a servlet container in the final JAR file allowing
+for self-contained Java Archives (JAR files).
+
+Codefresh can easily handle Spring Boot applications that are dockerized either in the traditional way or using multi-stage builds.
+
+## The example Java project
+
+You can see the example project at [https://github.com/codefresh-contrib/spring-boot-2-sample-app](https://github.com/codefresh-contrib/spring-boot-2-sample-app){:target="\_blank"}. The repository contains a Spring Boot 2 project built with Maven with the following goals:
+
+* `mvn package` creates a jar file that can be run on its own (exposes port 8080). It also runs unit tests.
+* `mvn verify` runs integration tests as well. The application is launched locally as part of the Maven lifecycle.
+
+Once launched the application presents a simple message at localhost:8080 and also at the various `/actuator/health` endpoints. You can use the standard `spring-boot:run` command to run it locally (without Docker).
+
+## Spring Boot 2 and Docker (package only)
+
+A Dockerfile is also provided at the same repository. It uses the base JRE image and just copies the JAR file inside the container.
+
+ `Dockerfile.only-package`
+{% highlight docker %}
+{% raw %}
+FROM java:8-jre-alpine
+
+EXPOSE 8080
+
+RUN mkdir /app
+COPY target/*.jar /app/spring-boot-application.jar
+
+ENTRYPOINT ["java","-Djava.security.egd=file:/dev/./urandom","-jar","/app/spring-boot-application.jar"]
+
+HEALTHCHECK --interval=1m --timeout=3s CMD wget -q -T 3 -s http://localhost:8080/actuator/health/ || exit 1
+
+{% endraw %}
+{% endhighlight %}
+
+This means that _before_ building the Docker image, the compilation step (`mvn package`) is expected to be finished already. Therefore, in the `codefresh.yml` file we need at least two steps. The first one should prepare the JAR file and the second
+one should create the Docker image.
+
+### Create a CI pipeline for Spring
+
+The repository also contains a premade [Codefresh YAML file]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/) that you can use as a starting point in your own Spring Boot 2 projects.
+
+Here are the full contents of the file.
+
+ `codefresh-package-only.yml`
+{% highlight yaml %}
+{% raw %}
+version: '1.0'
+stages:
+ - prepare
+ - test
+ - build
+ - 'integration test'
+steps:
+ main_clone:
+ title: Cloning main repository...
+ stage: prepare
+ type: git-clone
+ repo: 'codefresh-contrib/spring-boot-2-sample-app'
+ revision: master
+ git: github
+ run_unit_tests:
+ title: Compile/Unit test
+ stage: test
+ image: 'maven:3.5.2-jdk-8-alpine'
+ commands:
+ - mvn -Dmaven.repo.local=/codefresh/volume/m2_repository package
+ build_app_image:
+ title: Building Docker Image
+ type: build
+ stage: build
+ image_name: spring-boot-2-sample-app
+ working_directory: ./
+ tag: 'non-multi-stage'
+ dockerfile: Dockerfile.only-package
+ run_integration_tests:
+ title: Integration test
+ stage: 'integration test'
+ image: maven:3.5.2-jdk-8-alpine
+ commands:
+ - mvn -Dmaven.repo.local=/codefresh/volume/m2_repository verify -Dserver.host=http://my-spring-app
+ services:
+ composition:
+ my-spring-app:
+ image: '${{build_app_image}}'
+ ports:
+ - 8080
+ readiness:
+ timeoutSeconds: 30
+ periodSeconds: 15
+ image: byrnedo/alpine-curl
+ commands:
+ - "curl http://my-spring-app:8080/"
+{% endraw %}
+{% endhighlight %}
+
+The pipeline starts by checking out the code using a [git clone step]({{site.baseurl}}/docs/pipelines/steps/git-clone/). The next step is a [freestyle]({{site.baseurl}}/docs/pipelines/steps/freestyle/) one and packages the jar file. Next we have a [build step]({{site.baseurl}}/docs/pipelines/steps/build/) that creates the docker image. Finally we have another freestyle
+step that uses [service containers]({{site.baseurl}}/docs/pipelines/service-containers/) to run integration tests.
+
+{% include image.html
+lightbox="true"
+file="/images/examples/java/spring-boot-steps.png"
+url="/images/examples/java/spring-boot-steps.png"
+alt="Spring boot pipeline"
+caption="Spring boot pipeline"
+max-width="80%"
+%}
+
+After checking out the code we use the standard [Maven Docker image](https://hub.docker.com/_/maven/){:target="\_blank"} to compile the Spring Boot source code and create a JAR file. We also pass a parameter that changes the Maven cache location folder. The reason for this parameter is that the default Maven location is `/root/.m2` which is defined as a volume (and thus discarded after each build).
+
+### Caching the Maven dependencies
+
+Codefresh is smart enough that [caches automatically]({{site.baseurl}}/docs/pipelines/pipeline-caching/) for us the workspace of a build (`/codefresh/volume`). This works great for build tools that keep their cache in the project folder, but not for Maven/Gradle which keep their cache externally. By changing the location of the Maven repo on the project folder (the `m2_repository` name is arbitrary) we make sure that Codefresh will cache automatically the Maven libraries resulting in much faster builds.
+
+The next step is a Docker build. We name our image **spring-boot-2-sample-app** and tag it with a string `non-multi-stage` but of course you can use any other tag name that you wish.
+
+{% include image.html
+lightbox="true"
+file="/images/examples/java/spring-boot-docker-image.png"
+url="/images/examples/java/spring-boot-docker-image.png"
+alt="Spring Boot Docker image"
+caption="Spring Boot Docker image"
+max-width="80%"
+%}
+
+Once the pipeline is finished you will see the Spring Boot 2 Docker image your [Docker image dashboard]({{site.baseurl}}/docs/docker-registries/working-with-docker-registries/#viewing-docker-images).
+
+The last step is similar to the unit tests, but this time we run integration tests. We define again a custom cache folder so when you run the build you will see that Maven will automatically pick the cache from the previous step. All Codefresh steps in a pipeline [run on the same workspace]({{site.baseurl}}/docs/pipelines/introduction-to-codefresh-pipelines/#sharing-the-workspace-between-build-steps), so the build results from one step are visible to the next.
+
+>Notice that because the [Maven lifecycle](https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html){:target="\_blank"} also executes the previous steps in a build, the `mvn verify` command essentially will run `mvn package` as well. In theory we could just have the _Integration_ step in this pipeline on its own. That step would build the code, run unit and integration tests all in one stage. For demonstration purposes however, we include two steps so that you can see the correct usage of Maven cache.
+
+
+## Spring Boot 2 and Docker (multi-stage builds)
+
+Docker added [multi-stage builds](https://blog.docker.com/2017/07/multi-stage-builds/){:target="\_blank"} at version 17.05. With multi-stage builds a Docker build can use one base image for compilation/packaging/unit tests and a different one that will hold the runtime of the application. This makes the final image more secure and smaller in size (as it does not contain any development/debugging tools).
+
+In the case of Java, multistage builds allow for the compilation itself to happen during the build process, even though the final Docker image will not contain a full JDK.
+
+
+Here is the multi-stage build definition:
+
+ `Dockerfile`
+{% highlight docker %}
+{% raw %}
+FROM maven:3.5.2-jdk-8-alpine AS MAVEN_TOOL_CHAIN
+COPY pom.xml /tmp/
+RUN mvn -B dependency:go-offline -f /tmp/pom.xml -s /usr/share/maven/ref/settings-docker.xml
+COPY src /tmp/src/
+WORKDIR /tmp/
+RUN mvn -B -s /usr/share/maven/ref/settings-docker.xml package
+
+FROM java:8-jre-alpine
+
+EXPOSE 8080
+
+RUN mkdir /app
+COPY --from=MAVEN_TOOL_CHAIN /tmp/target/*.jar /app/spring-boot-application.jar
+
+ENTRYPOINT ["java","-Djava.security.egd=file:/dev/./urandom","-jar","/app/spring-boot-application.jar"]
+
+{% endraw %}
+{% endhighlight %}
+
+This docker build does the following:
+
+1. Starts from the standard Maven Docker image
+1. Copies only the `pom.xml` file inside the container
+1. Runs a mvn command to download all dependencies found in the `pom.xml`
+1. Copies the rest of the source code in the container
+1. Compiles the code and runs unit tests (with `mvn package`)
+1. Discards the Maven image with all the compiled classes/unit test results etc
+1. Starts again from the JRE image and copies **only** the JAR file created before
+
+The order of the steps is tuned so that it takes advantage of the layer caching built-in to Docker.
+If you change something in the source code Docker already has a layer with Maven dependencies so they
+will not be re-downloaded again. Only if you change the `pom.xml` file itself, Docker will start again from the lowest layer.
+
+Again, we define a custom location for the Maven cache (using the `settings-docker.xml` file). This way the Maven dependencies are placed inside the container and they will be cached automatically with the respective layer (Read more about this technique [at the official documentation](https://github.com/carlossg/docker-maven#packaging-a-local-repository-with-the-image){:target="\_blank"}.
+
+### Create a CI pipeline for Spring (multi-stage Docker builds)
+
+Because in multi-stage builds Docker itself handles most of the build process, moving the project to Codefresh is straightforward. We just need [a single step](https://github.com/codefresh-contrib/spring-boot-2-sample-app/blob/master/codefresh.yml){:target="\_blank"} that creates the Docker image after checking out the code. The integration test step is the same as before.
+
+ `codefresh.yml`
+{% highlight yaml %}
+{% raw %}
+version: '1.0'
+stages:
+ - prepare
+ - test
+ - build
+ - 'integration test'
+steps:
+ main_clone:
+ title: Cloning main repository...
+ stage: prepare
+ type: git-clone
+ repo: 'codefresh-contrib/spring-boot-2-sample-app'
+ revision: master
+ git: github
+ build_app_image:
+ title: Building Docker Image
+ type: build
+ stage: build
+ image_name: spring-boot-2-sample-app
+ working_directory: ./
+ tag: 'multi-stage'
+ dockerfile: Dockerfile
+ run_integration_tests:
+ title: Integration test
+ stage: 'integration test'
+ image: maven:3.5.2-jdk-8-alpine
+ commands:
+ - mvn -Dmaven.repo.local=/codefresh/volume/m2_repository verify -Dserver.host=http://my-spring-app
+ services:
+ composition:
+ my-spring-app:
+ image: '${{build_app_image}}'
+ ports:
+ - 8080
+ readiness:
+ timeoutSeconds: 30
+ periodSeconds: 15
+ image: byrnedo/alpine-curl
+ commands:
+ - "curl http://my-spring-app:8080/"
+{% endraw %}
+{% endhighlight %}
+
+This will compile/test/package the Spring Boot application and create a Docker image. Codefresh is automatically caching
+Docker layers (it uses the Docker image of a previous build as a cache for the next) and therefore builds will become
+much faster after the first one finishes.
+
+
+## Related articles
+[Gradle example]({{site.baseurl}}/docs/example-catalog/ci-examples/gradle/)
+[Codefresh YAML for pipeline definitions]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/)
+[Steps in pipelines]({{site.baseurl}}/docs/pipelines/steps/)
+[Creating pipelines]({{site.baseurl}}/docs/pipelines/pipelines/)
+[How Codefresh pipelines work]({{site.baseurl}}/docs/pipelines/introduction-to-codefresh-pipelines/)
diff --git a/_docs/example-catalog/ci-examples/uploading-or-downloading-from-gs.md b/_docs/example-catalog/ci-examples/uploading-or-downloading-from-gs.md
new file mode 100644
index 000000000..f2c046d92
--- /dev/null
+++ b/_docs/example-catalog/ci-examples/uploading-or-downloading-from-gs.md
@@ -0,0 +1,154 @@
+---
+title: "Upload/download files to/from Google Storage"
+description: "Upload and download a JAR from Google Storage from within a pipeline"
+group: example-catalog
+sub_group: ci-examples
+redirect_from:
+ - /docs/yaml-examples/examples/uploading-or-downloading-from-gs/
+toc: true
+---
+
+## Prerequisites
+
+- A [Codefresh account]({{site.baseurl}}/docs/administration/account-user-management/create-codefresh-account/)
+- A [Google Storage Bucket](https://cloud.google.com/storage/docs/creating-buckets){:target="\_blank"} with public read access
+- A private key [downloaded](https://cloud.google.com/storage/docs/authentication#gsutilauth){:target="\_blank"} for the existing service account associated with your bucket (for this example, we base64 encoded the key for ease of use in a pipeline variable using `base64 key_file.json > key_file.b64`)
+
+## Example Project
+
+The example project is at [GitHub](https://github.com/codefresh-contrib/gcloud-storage-sample-app.git){:target="\_blank"}. The application is a simple Scala Hello World application contained in a jar, with a dependency on a scala-library jar which we will download from the bucket and package into a Docker image.
+
+Our project contains two pipelines, one to upload the dependency JAR _to_ our bucket, and the other to download the JAR _from_ the bucket.
+
+## Create the first pipeline
+
+The first pipeline contains one stage/step, to upload the JAR to the Google Storage Bucket.
+
+{% include image.html
+lightbox="true"
+file="/images/examples/gs/gs-upload-pipeline.png"
+url="/images/examples/gs/gs-upload-pipeline.png"
+alt="Codefresh UI Pipeline View"
+caption="Codefresh UI Pipeline View"
+max-width="90%"
+%}
+
+You need to define a pipeline variable, KEY_FILE, in the pipeline settings:
+
+{% include image.html
+lightbox="true"
+file="/images/examples/gs/gs-pipeline-vars.png"
+url="/images/examples/gs/gs-pipeline-vars.png"
+alt="Codefresh UI Pipeline Variables"
+caption="Codefresh UI Pipeline Variables"
+max-width="60%"
+%}
+
+Here is the first pipeline:
+
+`codefresh-upload.yml`
+{% highlight yaml %}
+{% raw %}
+version: "1.0"
+
+stages:
+ - "upload"
+
+steps:
+ upload:
+ title: "Uploading library jar to GS..."
+ type: "freestyle"
+ stage: "upload"
+ arguments:
+ image: "google/cloud-sdk:slim"
+ commands:
+ - echo $KEY_FILE | base64 --decode > key_file.json
+ - gcloud auth activate-service-account --key-file=key_file.json
+ - curl https://repo1.maven.org/maven2/org/scala-lang/scala-library/2.12.2/scala-library-2.12.2.jar | gsutil cp - gs://anna-demo-bucket/scala-library-2.12.2.jar
+{% endraw %}
+{% endhighlight %}
+
+This pipeline:
+
+1. Uploads a JAR from Maven into our Google Storage bucket through a [freestyle step]({{site.baseurl}}/docs/pipelines/steps/freestyle/).
+
+## Create the second pipeline
+
+Our second pipeline has four stages:
+
+- A stage for cloning the repository
+- A stage for downloading the jar from the bucket
+- A stage for building the image
+- A stage for pushing the image to the repository
+
+{% include image.html
+lightbox="true"
+file="/images/examples/gs/gs-download-pipeline.png"
+url="/images/examples/gs/gs-download-pipeline.png"
+alt="Codefresh UI Pipeline View"
+caption="Codefresh UI Pipeline View"
+max-width="90%"
+%}
+
+Here is the YAML for the second pipeline:
+
+`codefresh-download.yml`
+{% highlight yaml %}
+{% raw %}
+version: "1.0"
+
+stages:
+ - "clone"
+ - "download"
+ - "build"
+ - "push"
+
+steps:
+ clone:
+ title: "Cloning main repository..."
+ type: "git-clone"
+ stage: "clone"
+ arguments:
+ repo: "codefresh-contrib/gcloud-storage-sample-app"
+ git: "github"
+ revision: "master"
+ download:
+ title: "Downloading dependency lib from GS..."
+ type: "freestyle"
+ stage: "download"
+ working_directory: ${{clone}}
+ arguments:
+ image: "google/cloud-sdk:slim"
+ commands:
+ - gsutil cp gs://anna-demo-bucket/scala-library-2.12.2.jar .
+ build:
+ title: "Building docker image..."
+ type: "build"
+ stage: "build"
+ working_directory: ${{clone}}
+ arguments:
+ image_name: "annabaker/gcloud-storage-sample-app"
+ tag: "master"
+ push_to_my_registry:
+ stage: "push"
+ type: "push"
+ title: "Pushing to external registry..."
+ arguments:
+ candidate: ${{build}}
+ tag: '1.0.0'
+ registry: "dockerhub"
+{% endraw %}
+{% endhighlight %}
+
+This pipeline does the following:
+
+1. Clones the source code through a [Git clone step]({{site.baseurl}}/docs/pipelines/steps/git-clone/).
+2. Downloads the dependency JAR from our publicly-accessible Google Storage bucket through a [freestyle step]({{site.baseurl}}/docs/pipelines/steps/freestyle/).
+3. Builds a docker image through a [build step]({{site.baseurl}}/docs/pipelines/steps/build/).
+4. Pushes the Docker image to the DockerHub registry you have integrated with Codefresh through a [push step]({{site.baseurl}}/docs/pipelines/steps/push/).
+
+## Related articles
+[CI/CD pipeline examples]({{site.baseurl}}/docs/example-catalog/examples/#ci-examples)
+[Codefresh YAML for pipeline definitions]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/)
+
+
diff --git a/_docs/example-catalog/ci-examples/vault-secrets-in-the-pipeline.md b/_docs/example-catalog/ci-examples/vault-secrets-in-the-pipeline.md
new file mode 100644
index 000000000..fa252ad32
--- /dev/null
+++ b/_docs/example-catalog/ci-examples/vault-secrets-in-the-pipeline.md
@@ -0,0 +1,118 @@
+---
+title: "Vault secrets in pipelines"
+description: "Access and refer to Vault secrets in pipelines"
+group: example-catalog
+sub_group: ci-examples
+redirect_from:
+ - /docs/yaml-examples/examples/vault-secrets-in-the-pipeline/
+toc: true
+---
+
+Codefresh offers a Vault plugin you may use from the [Step Marketplace](https://codefresh.io/steps/step/vault){:target="\_blank"}. The plugin imports key-value pairs from the Vault server, and exports them into the pipeline.
+
+## Prerequisites
+
+- A [Codefresh account]({{site.baseurl}}/docs/administration/account-user-management/create-codefresh-account/)
+- An existing Vault server [already setup](https://learn.hashicorp.com/vault/getting-started/install){:target="\_blank"}
+- A secret stored in said Vault server with a key of `password`
+- A Vault [authorization token](https://learn.hashicorp.com/vault/getting-started/authentication#tokens){:target="\_blank"}
+
+## Example Java application
+
+You can find the example project on [GitHub](https://github.com/codefresh-contrib/vault-sample-app){:target="\_blank"}.
+
+The example application retrieves the system variable `password` from the pipeline, and uses it to authenticate to a Redis database, but you are free to use any type of database of your choosing.
+
+```java
+ String password = System.getenv("password");
+ String host = System.getProperty("server.host");
+
+ RedisClient redisClient = new RedisClient(
+ RedisURI.create("redis://" + password + "@" + host + ":6379"));
+ RedisConnection connection = redisClient.connect();
+```
+
+Also in the example application is a simple unit test that ensures we are able to read and write data to the database.
+
+You cannot run the application locally, as it needs to run in the pipeline in order to use our environment variables to connect.
+
+## Create the pipeline
+
+The following pipeline contains three steps: a vault step, a [git-clone]({{site.baseurl}}/docs/pipelines/steps/git-clone/) step, and a [freestyle step]({{site.baseurl}}/docs/pipelines/steps/freestyle/).
+
+{% include image.html
+lightbox="true"
+file="/images/examples/secrets/vault-pipeline.png"
+url="/images/examples/secrets/vault-pipeline.png"
+alt="Vault pipeline"
+caption="Vault Pipeline"
+max-width="100%"
+%}
+
+You should be able to copy and paste this YAML into the in-line editor in the Codefresh UI. It will automatically clone the project for you.
+
+Note that you need to change the `VAULT_ADDR`, `VAULT_AUTH`, and `VAULT_AUTH_TOKEN` arguments within the first step to your respective values.
+
+`codefresh.yml`
+```yaml
+version: "1.0"
+stages:
+ - "vault"
+ - "clone"
+ - "package"
+steps:
+ vault:
+ title: Importing vault values...
+ stage: "vault"
+ type: vault
+ arguments:
+ VAULT_ADDR: 'http://:'
+ VAULT_PATH: 'path/to/secret'
+ VAULT_AUTH_TOKEN: ''
+ clone:
+ title: Cloning main repository...
+ type: git-clone
+ arguments:
+ repo: 'codefresh-contrib/vault-sample-app'
+ git: github
+ stage: clone
+ package_jar:
+ title: Packaging jar and running unit tests...
+ stage: package
+ working_directory: ${{clone}}
+ arguments:
+ image: maven:3.5.2-jdk-8-alpine
+ commands:
+ - mvn -Dmaven.repo.local=/codefresh/volume/m2_repository -Dserver.host=my-redis-db-host clean package
+ services:
+ composition:
+ my-redis-db-host:
+ image: 'redis:4-alpine'
+ command: 'redis-server --requirepass $password'
+ ports:
+ - 6379
+```
+
+The pipeline does the following:
+
+1. Imports the key-value pairs from the Vault server and exports them into the pipeline under `/meta/env_vars_to_export`.
+2. Clones the main repository (note the special use of naming the step `main_clone`). This ensures that all subsequent commands are run [inside the project that was checked out]({{site.baseurl}}/docs/pipelines/steps/git-clone/#basic-clone-step-project-based-pipeline).
+3. The `package_jar`, does a few special things to take note of:
+ - Spins up a [Service Container]({{site.baseurl}}/docs/pipelines/service-containers/) running Redis on port 6379 , and sets the password to the database using our exported environment variable
+ - Sets `maven.repo.local` to cache Maven dependencies into the local codefresh volume to [speed up builds]({{site.baseurl}}/docs/example-catalog/ci-examples/spring-boot-2/#caching-the-maven-dependencies)
+ - Runs unit tests and packages the jar. Note how you can directly refer to the service container's name (`my-redis-db-host`) when we set `server.host`
+
+You will see that the variable was correctly exported to the pipeline by running a simple `echo` command:
+ {% include image.html
+ lightbox="true"
+ file="/images/examples/secrets/vault-pipeline2.png"
+ url="/images/examples/secrets/vault-pipeline2.png"
+ alt="Vault pipeline variable"
+ caption="Vault pipeline variable"
+ max-width="100%"
+ %}
+
+## Related articles
+[CI pipeline examples]({{site.baseurl}}/docs/example-catalog/#ci-examples)
+[Steps in pipelines]({{site.baseurl}}/docs/pipelines/steps/)
+
diff --git a/_docs/example-catalog/ci-examples/voting-app.md b/_docs/example-catalog/ci-examples/voting-app.md
new file mode 100644
index 000000000..c7329dfa1
--- /dev/null
+++ b/_docs/example-catalog/ci-examples/voting-app.md
@@ -0,0 +1,94 @@
+---
+title: "Voting app"
+description: ""
+excerpt: ""
+group: example-catalog
+sub_group: ci-examples
+redirect_from:
+ - /docs/learn-by-example/nodejs/voting-app/
+ - /docs/voting-app-1/
+ - /docs/python/voting-app/
+toc: true
+---
+This voting application is a demo with which you can build an advanced composition that uses `Python, Redis, Postgres, Node.js, and .Net`.
+
+## Looking around
+In the root of this repository you'll find a file named codefresh.yml, this is our build descriptor and it describes the different steps that comprise our process. Let's quickly review the contents of this file:
+
+ `codefresh.yml`
+{% highlight yaml %}
+{% raw %}
+version: '1.0'
+steps:
+ unit-tests:
+ image: codefresh/buildpacks:nodejs-5
+ working-directory : ${{initial-clone}}
+ commands:
+ - echo Installing npm modules silent
+ - npm install
+ - gulp test
+ - echo $(date)
+
+ build-step:
+ #title: Build My Image #Display name for the step
+ type: build
+ image-name: containers101/cf-example-result
+ tag: ${{CF_BRANCH}}
+ build_arguments:
+ - OPTION_A=${{OPTION_A}}
+ - OPTION_B=${{OPTION_B}}
+
+ push-to-registry:
+ type: push
+ #candidate: the image from the build step
+ candidate: ${{build-step}}
+ tag: ${{CF_BRANCH}}
+
+ integration-tests-step:
+ type: composition
+ #location of the compostion on the filesystem of the cloned image
+ composition: './cf-compositions/voting-app-full.yml'
+ #run integration only when pushing to master
+ when:
+ branch:
+ only:
+ - master #can also be regex
+ composition-candidates:
+ #this will be the image that we will test
+ integ-test:
+ image: containers101/cf-example-tests:master
+ command: ./tests.sh
+ composition-variables:
+ - VOTING_OPTION_A=${{OPTION_A}}
+ - VOTING_OPTION_B=${{OPTION_B}}
+
+ launch-composition:
+ type: launch-composition
+ environment-name: 'Test composition after build'
+ composition: './cf-compositions/voting-app-full.yml'
+ composition-variables:
+ - VOTING_OPTION_A=${{OPTION_A}}
+ - VOTING_OPTION_B=${{OPTION_B}}
+
+ deploy to ecs:
+ image: codefresh/cf-deploy-ecs
+ commands:
+ - cfecs-update --image-name containers101/cf-example-result --image-tag ${{CF_BRANCH}} eu-west-1 vote-app result
+ environment:
+ - AWS_ACCESS_KEY_ID=${{AWS_ACCESS_KEY_ID}}
+ - AWS_SECRET_ACCESS_KEY=${{AWS_SECRET_ACCESS_KEY}}
+ when:
+ condition:
+ all:
+ pushCommit: 'includes(lower("${{CF_COMMIT_MESSAGE}}"), "[deploy]") == true'
+{% endraw %}
+{% endhighlight %}
+
+{{site.data.callout.callout_info}}
+##### Example
+
+Just head over to the example [__repository__](https://github.com/containers101/cf-example-result){:target="_blank"} in GitHub and follow the instructions there.
+{{site.data.callout.end}}
+
+## Related articles
+[CI/CD pipeline examples]({{site.baseurl}}/docs/example-catalog/ci-examples/)
diff --git a/_docs/example-catalog/gitops-examples.md b/_docs/example-catalog/gitops-examples.md
new file mode 100644
index 000000000..ba1c727d1
--- /dev/null
+++ b/_docs/example-catalog/gitops-examples.md
@@ -0,0 +1,9 @@
+---
+title: "GitOps examples"
+description: "A collection of examples for GitOps deployments"
+group: example-catalog
+sub_group: gitops-examples
+toc: true
+---
+
+TBD
\ No newline at end of file
diff --git a/_docs/getting-started/cd-codefresh.md b/_docs/getting-started/cd-codefresh.md
new file mode 100644
index 000000000..b765696eb
--- /dev/null
+++ b/_docs/getting-started/cd-codefresh.md
@@ -0,0 +1,129 @@
+---
+title: "Codefresh for CD"
+description: "Continuous deployment (CD) with Codefresh pipelines"
+group: getting-started
+toc: true
+---
+
+Codefresh is a Continuous Integration/Delivery (CI/CD) solution. This article reviews main concepts around CD, and how Codefresh supports and implements them.
+
+For a review of CI concepts, see [Codefresh for CI]({{site.baseurl}}/docs/getting-started/ci-codefresh/).
+
+
+
+
+
+## Connecting to Kubernetes
+Connecting your Kubernetes cluster to the CI/CD platform is the first step in continuous deployment. Codefresh integrates with any known cluster provider for Kubernetes through a few simple steps. Connect your Google, Azure, or Amazon Kubernetes cluster to Codefresh through simple integration steps. If your Kubernetes cluster is not in our list of cluster providers, you can manually enter your cluster settings and add it as a generic Kubernetes cluster.
+
+See [Connecting a Kubernetes cluster]({{site.baseurl}}/docs/integrations/kubernetes/#connect-a-kubernetes-cluster).
+
+## Deploying to Kubernetes
+Codefresh offers a variety of options for you to choose from when deploying to Kubernetes.
+Deploy to Kubernetes from the Codefresh UI, or programmatically through dedicated steps in pipelines, avoiding the need for `kubectl` commands.
+
+**On-demand deployment**
+For quick and easy deployment, you can deploy on-demand from the Codefresh UI.
+
+**Dedicated steps in pipelines**
+For more flexibility, we have dedicated steps for pipelines: the `deploy`step, and the more advanced `cf-deploy-kubernetes`step which enables simple templating on Kubernetes manifests.
+
+Codefresh pipelines also support Kustomize and Helm for deployments through `freestyle` steps.
+
+Finally, if you are familiar with and still want to work with `kubectl`, run your own custom `kubectl` commands in a freestyle step. Read more in [kubectl](#kubectl).
+
+See [Deployment options for Kubernetes]({{site.baseurl}}/docs/deployments/kubernetes/).
+
+## kubectl
+`kubectl` is the command line interface for managing Kubernetes clusters. Running custom `kubectl` commands in a freestyle step gives maximum flexibility with cluster deployments.
+
+Codefresh automatically sets up your config context with your connected clusters. The config context is the value of the `$CF_KUBECONFIG_PATH` variable, which expands to `/codefresh/volume/sensitive/.kube/config` within the shared step volume.
+
+Codefresh has a public Docker image for kubectl at [Docker Hub](https://hub.docker.com/r/codefresh/kubectl/tags){:target="\_blank"} that you can use.
+
+Because Codefresh automatically sets up your `kubeconfig` files with the information from your cluster integrations, you can modify the current config context and run any `kubectl` command you want applied to that context. For example, leverage the parallel capability of Codefresh pipelines to create two Docker images and deploy them to two different clusters with custom `kubectl` commands.
+
+See [Running custom kubectl commands]({{site.baseurl}}/docs/deployments/kubernetes/custom-kubectl-commands/).
+
+## Helm deployments
+Codefresh supplies a built-in Helm repository with every Codefresh account. And supports, besides public HTTP repositories, several private, authenticated Helm repositories.
+
+**Connect to Helm repositories**
+In addition to the official Helm repositories which are displayed in the Helm charts, Codefresh allows you to connect with any external Helm repository through simple integrations. You can then inject the Helm repository context into your pipelines by selecting the repository name.
+
+**Build Helm charts**
+Install Helm charts from Helm repositories, or build a new one.
+
+
+As with steps for Kubernetes deployments, Codefresh has a dedicated step for Helm deployments. The Helm step easily integrates Helm in Codefresh pipelines, and can authenticate, configure, and execute Helm commands.
+
+The Helm step can operate in one of three modes covering most scenarios:
+* Install the chart into a Kubernetes cluster. This is the default mode if not explicitly set.
+* Package the chart and push it to the defined repository.
+* Set up authentication and add the repo to Helm. This is useful if you want to write your own Helm commands using the freestyle step’s commands property, but you still want the step to handle authentication.
+
+**Deploy Helm charts**
+Deploy the Helm chart to a Kubernetes cluster, Helm repo, or both.
+
+See [Using Helm in Codefresh pipelines]({{site.baseurl}}/docs/deployments/helm//using-helm-in-codefresh-pipeline/), [Using managed Helm repos]({{site.baseurl}}/docs/deployments/helm//managed-helm-repository/), and Helm [charts and repositories]({{site.baseurl}}/docs/deployments/helm/helm-charts-and-repositories/).
+
+## Dashboards
+Dashboards are key to providing the right information at the right time. Codefresh makes it easy to both access and visualize critical information for any resource, at any stage and level, and for anyone, from managers to DevOps engineers.
+
+Our operational dashboards expose the most critical application and environmental information to developers for troubleshooting without needing assistance from the DevOps teams. Our analytics dashboards expose key statistics and metrics around builds and deployments for product owners and management alike.
+
+
+You can customize all dashboards to display just the information most relevant to your business issues.
+
+**Kubernetes**
+The Kubernetes (Kubernetes Services) dashboard displays the clusters in your environments, their state, and actions if you have the required access privileges.
+
+This dashboard is a centralized location from which to view, add, modify, and remove Kubernetes services. You can deploy services with images from the Codefresh registry or from external Docker registries.
+See [Accessing the Kubernetes dashboard]({{site.baseurl}}/docs/deployments/kubernetes/manage-kubernetes/#accessing-the-kubernetes-dashboard).
+
+**Helm dashboards**
+For Helm, we have a Helm Board, and a Helm Releases dashboard.
+
+* Helm Boards
+ The Helm Board is a special environment board that tracks applications as they move within your infrastructure. For example, between Dev, QA and Prod environments.
+ Here you can see the lifecycle of the application, and at the same time, use it as a tool to shift Helm releases between environments.
+
+ You can create as many Helm Boards as you want, and customize the Helm Boards with the columns to display, each column being a Helm-enabled Kubernetes cluster.
+ See [Using the Helm Board]({{site.baseurl}}/docs/deployments/helm/helm-environment-promotion/#using-the-helm-environment-board).
+
+* Helm Releases
+ The Helm Releases dashboard provides a unique view into your production Kubernetes cluster, and options to manage deployed releases. See the current status of your cluster, including the currently deployed releases, their previous revisions with change tracking. If needed, you can even roll back to a previous release.
+ See [View Helm releases and release information]({{site.baseurl}}/docs/deployments/helm/helm-releases-management/#view-helm-releases-and-release-information).
+
+
+**Environment dashboard**
+
+The Kubernetes dashboard shows cluster status and focuses more on the service aspects such as pods and Docker images. The Helm Board offers an application-level view of your cluster, as it applies to Helm deployments.
+
+To bridge this gap, Codefresh also offers an Environment dashboard that combines information for both Kubernetes and Helm releases. You can see cluster status in the context of the pipeline builds that run on and affect the cluster. The Environment dashboard links between the status of the cluster and the status of the builds.
+
+See [Environment dashboard]({{site.baseurl}}/docs/deployments/kubernetes/environment-dashboard/).
+
+**GitOps Overview dashboard**
+The GitOps Overview dashboard presents system-wide highlights in real-time for GitOps deployments, 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.
+See [DORA metrics]({{site.baseurl}}/docs/dashboards/dora-metrics/).
+
+**DORA metrics**
+The DORA (DevOps Research and Assessment) metrics dashboard pulls out critical metrics for our GitOps deployments. The metrics include deployment frequency, lead time for changes, mean time to recovery, and change failure rate. The metric graphs show performance by default for the last 90 days, with the option to select daily/weekly/monthly granularity views.
+See [DORA metrics]({{site.baseurl}}/docs/dashboards/home-dashboard/).
+
+
+## Related articles
+[Codefresh for CI]({{site.baseurl}}/docs/getting-started/ci-codefresh/)
+[Codefresh for GitOps]({{site.baseurl}}/docs/getting-started/gitops-codefresh/)
+[Concepts in Codefresh]({{site.baseurl}}/docs/getting-started/concepts/)
\ No newline at end of file
diff --git a/_docs/getting-started/ci-codefresh.md b/_docs/getting-started/ci-codefresh.md
new file mode 100644
index 000000000..066a64b58
--- /dev/null
+++ b/_docs/getting-started/ci-codefresh.md
@@ -0,0 +1,138 @@
+---
+title: "Codefresh for CI"
+description: "See what Codefresh offers for Continuous integration (CI) with pipelines"
+group: getting-started
+toc: true
+---
+
+Codefresh is a Continuous Integration/Delivery solution. This article reviews main concepts around CI, and how Codefresh supports and implements them.
+
+For a review of CD concepts, see [Codefresh for CD]({{site.baseurl}}/docs/getting-started/cd-codefresh/).
+
+
+
+## Code compilation
+
+The basic function of a CI system is to compile/package source code. Codefresh is language-agnostic as far as programming languages are concerned. Codefresh works equally well with compiled languages (Java, Go, C/C++), as well as interpreted languages (Python, PHP, Ruby).
+
+The only requirement is that you either use an existing Docker image as a step in your pipeline or create your own with the exact versions of tools that you need.
+
+You can find several Docker images for all popular programming languages or you can create your own if you use an exotic programming language.
+
+## Docker images
+
+Building a Docker image from the source code is probably the most common and basic requirement for a CI pipeline. In Codefresh, you can build, push, and promote Docker images, using declarative YAML and credentials that are defined once and stored centrally for reuse.
+
+**Build and push image**
+Building a Dockerfile in a pipeline works in the same way as building the Dockerfile locally on your workstation. The `build` step in Codefresh enables you to build a Docker image in a completely declarative manner, and to automatically push it to your default Docker registry without any additional configuration.
+
+See:
+[Build and push Docker images]({{site.baseurl}}/docs/example-catalog/ci-examples/build-and-push-an-image/)
+
+
+**View image**
+The Images dashboard displays images from all registries connected to Codefresh. Every image is enriched with Git branch, Git hash and commit message, and other tags defined for the image.
+
+See:
+[Viewing Docker images]({{site.baseurl}}/docs/ci-cd-guides/working-with-docker-registries/#viewing-docker-images)
+
+
+
+**Promote image**
+Promote images either from the Codefresh UI, or automatically from pipelines by specifying an existing image in the pipeline step. Promote an image by copying it from one registry to another.
+
+See:
+[Promoting Docker images]({{site.baseurl}}/docs/ci-cd-guides/working-with-docker-registries/#viewing-docker-images)
+
+
+
+
+## Unit testing
+Codefresh supports all testing frameworks, including mock-frameworks, for all popular programming languages. Easily run unit tests on the source code of the application for every commit or pull request (PR) through our `freestyle` pipeline step.
+
+Run any type of unit tests in Codefresh pipelines, from smoke tests in a dockerfile, to tests with external or application images for simple applications, and on a special testing image for complex applications.
+Create test reports and view them whenever you need.
+
+See:
+[Run unit tests example]({{site.baseurl}}/docs/example-catalog/ci-examples/run-unit-tests/)
+
+
+## Integration testing
+Compared to unit tests that run on the source code, integration tests run on the application itself. You need to either launch the application itself, or one or more external services such as a database.
+
+In Codefresh, you can launch these sidecar containers within the pipeline through compositions and service containers.
+
+
+See [Run integration tests example]({{site.baseurl}}/docs/example-catalog/ci-examples/run-integration-tests/).
+
+## Code quality/coverage
+Good quality code is central to any CI platform or tool. Codefresh integrates with the top code quality platforms/tools in the market to track code coverage, inspect code quality, and generate code-coverage analysis reports.
+
+Implement code quality coverage in Codefresh pipelines through these steps:
+* Set up integrations with the platforms/tools (Coverall, SonarQube, Codecov, for example).
+* Copy and paste the ready-to-use step for your platform/tool into your pipeline from our [Plug-ins library](https://codefresh.io/steps/){:target="\_blank"}.
+* Reference them by name in the pipeline step, and view the updated reports in the respective UIs.
+
+See [Code coverage examples]({{site.baseurl}}/docs/example-catalog/examples/#code-coverage-examples).
+
+## Linting/validating
+
+Linting and validation tools which perform static analysis on source code or other resources are also integral parts of pipelines. Codefresh pipelines can use any linter tool that is bundled with a Docker image.
+
+Codefresh can also validate files that are not source-code, such as markup-language files (XML/YAML/JSON), and infrastructure files (Terraform, or Kubernetes resource files).
+
+As most static analysis tools are CLI-based, they can be easily used in a Codefresh pipeline.
+
+## Security scanning
+Security scans are critical to deploying quality code. Codefresh allows you to also control when to implement the security scan, and then view the scan results in the Codefresh UI, without having to go to the security platform.
+
+**Security scan platforms**
+Codefresh can integrate with any security scanning platform that scans source code or Docker images for vulnerabilities. We already have ready-to-use Docker images for several security platforms such as Anchore, Aqua Security, Clair, Twistlock and WhiteSource. For the full list, visit our [Plug-ins library](https://codefresh.io/steps/){:target="\_blank"}.
+
+**Scan at any point**
+The security scan is implemented through a `freestyle` step, inserted anywhere in the pipeline. The fact that you can insert the step anywhere in the pipeline allows you to control when the scan is executed, for example, before the source code is packaged in a container, or before the container is stored in a registry or deployed to production, or any combination of the two.
+
+**View scan results**
+As with any scan, the final step is viewing the scan results. Attaching analysis reports to the pipeline build makes the scan results available in Codefresh release dashboards.
+
+**Security annotations**
+Correlate the Docker images in Codefresh with the results of the security scanning platform by adding annotations for custom metadata. For example, you can add annotations such as the number of issues or the URL of the full report.
+
+See:
+[Security scanning tests]({{site.baseurl}}/docs/testing/security-scanning/)
+[Test reporting modes]({{site.baseurl}}/docs/testing/test-reports/)
+[Metadata in Docker images]({{site.baseurl}}/docs/pipelines//docker-image-metadata/)
+
+
+## Notifications
+Codefresh supports status and event notifications, through email, Slack, and Jira.
+
+**Pipeline build notifications**
+Every user can configure email notifications for pipeline builds, successful or failed builds. See [Email notifications for pipeline builds]({{site.baseurl}}/docs/administration/user-self-management/user-settings/#email-notifications-for-pipeline-builds).
+
+**Slack notifications**
+Codefresh offers different levels of notifications for Slack. At the global level, Slack notifications are sent for all pipelines launched automatically through Git triggers.
+Our plugins enable granular notifications for specific pipelines.
+
+See [Slack notifications in Codefresh]({{site.baseurl}}/docs/integrations/notifications/slack-intergration/), and [examples for Slack notification]({{site.baseurl}}/docs/example-catalog/ci-examples/sending-the-notification-to-slack/).
+
+**Jira notifications**
+Codefresh integrates with Jira in several ways:
+The standard integration provides the highest visibility into your GitOps deployments. Referencing the integration in your pipeline pulls in all the Jira information and enriches the image with the issue-tracking information.
+
+Our versatile [Jira Issue Manager](https://codefresh.io/steps/step/jira-issue-manager){:target="\_blank"} step can be used to create Jira issues, comment on existing Jira issues, change the status of an issue, and even add a description to your issue.
+
+
+See [Jira notifications in Codefresh]({{site.baseurl}}/docs/integrations/notifications/jira-integration/) and [examples for Jira notification]({{site.baseurl}}/docs/example-catalog/ci-examples/sending-the-notification-to-jira/).
+
+
+## Related articles
+[Codefresh for CD]({{site.baseurl}}/docs/getting-started/cd-codefresh/)
+[Codefresh for GitOps]({{site.baseurl}}/docs/getting-started/gitops-codefresh/)
+[Concepts in Codefresh]({{site.baseurl}}/docs/getting-started/concepts/)
+
+
+
+
+
+
diff --git a/_docs/getting-started/concepts.md b/_docs/getting-started/concepts.md
new file mode 100644
index 000000000..7da292d30
--- /dev/null
+++ b/_docs/getting-started/concepts.md
@@ -0,0 +1,125 @@
+---
+title: "Concepts in Codefresh"
+description: "Understand terminology and nuances in Codefresh"
+group: getting-started
+redirect_from:
+ - /docs/getting-started/faq/
+toc: true
+---
+
+Familiarize yourself with the main concepts in Codefresh (listed in alphabetical order).
+
+## Applications
+An application is a deployment to a Kubernetes or any Kubernetes-compatible cluster or clusters.
+Codefresh supports two types of applications:
+* Containerized applications packaged as Docker images or
+* Argo CD applications
+
+**Containerized applications**
+Containerized applications are compiled, packaged, and deployed through Codefresh pipelines. Codefresh has native support for Docker artifacts, and also supports non-Dockerized applications that don’t use a Dockerfile for the actual build.
+
+Deploy an application directly to Kubernetes through the Codefresh UI, or use Helm as a package manager to deploy to Kubernetes, again from Codefresh.
+Codefresh offers several levels of visibility into your deployments :
+* The Kubernetes dashboard displays the status of pods and Docker images.
+* The Helm dashboard displays the applications deployed to the cluster through Helm packages.
+* The Environment dashboard displays both Helm and Kubernetes releases, the status of the cluster, and most importantly that of the builds that affect it.
+
+See:
+Quick starts for [Kubernetes]({{site.baseurl}}/docs/quick-start/ci-quick-start/deploy-to-kubernetes/) and [Helm]({{site.baseurl}}/docs/quick-start/ci-quick-start/deploy-with-helm/) deployments
+[Deployment options for Kubernetes]({{site.baseurl}}/docs/deployments/kubernetes/)
+[Using Helm in Codefresh pipelines]({{site.baseurl}}/docs/deployments/helm/using-helm-in-codefresh-pipeline/)
+
+
+**Argo CD applications**
+Argo CD applications conform to Argo CD's application definition CRD (Custom Resource Definition). Argo CD supports several types of Kubernetes manifests, including Jsonnet, Kustomize applications, Helm charts, and YAML/json files, and supports webhook notifications from Git.
+
+Create Argo CD applications that are fully GitOps-compliant in Codefresh. Identify and fix errors before commit with our built-in validations. The application manifest is generated, committed to Git, and synced to your cluster.
+See:
+[Creating]({{site.baseurl}}/docs/deployments/gitops/create-application/) and [Managing]({{site.baseurl}}/docs/deployments/gitops/manage-application/) GitOps applications
+
+
+Just as with Dockerized applications, you get full visibility into the applications and their deployment through the global Analytics, DORA metrics, and the Application dashboards. The Applications dashboard shows the current state of all the resources in the application, including information for each resource, and possible actions.
+See:
+[Monitoring applications]({{site.baseurl}}/docs/deployments/gitops/applications-dashboard/)
+
+
+## Pipeline
+The pipeline is the central component in Codefresh that implements CI/CD processes. Everything for CI/CD in Codefresh starts and ends with pipelines.
+
+Codefresh pipelines can do only CI, only CD, both CI and CD, or run any custom action, such as unit and integration tests.
+A CI pipeline can compile and package code, build and push Docker images. A CD pipeline can deploy applications/artifacts to VMs, Kubernetes clusters, FTP sites, S3 buckets, and more. And a CI/CD pipeline can combine code compilation, integration, and deployment for full CI/CD.
+
+Codefresh offers a rich set of capabilities to easily create and maintain pipelines such as ready-to-use steps for common tasks, system and user-defined variables, shared configurations for resuse, and more.
+
+See:
+[Introduction to Codefresh pipelines]({{site.baseurl}}/docs/pipelines/introduction-to-codefresh-pipelines/)
+[Pipeline definitions YAML]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/)
+[Creating pipelines]({{site.baseurl}}/docs/pipelines/pipelines/)
+
+## Project
+A project is a top-level entity in Codefresh for grouping related pipelines. Projects can group pipelines according to any criteria that is relevant to your enterprise. The criteria can be logical and based on teams, departments, or location for example, or functional, and based on microservices in applications.
+Projects centralize viewing and configuration settings for the pipelines that belong to them:
+* Selecting a pipeline shows the other pipelines in the same project
+* Access control and user-defined variables for the project are inherited by all the pipelines assigned to the project
+
+There are no limits to the number of projects you can create in your account. You can also create standalone pipelines and assign them later to a project, or detach a pipeline assigned to a project.
+
+See [Projects in pipelines]({{site.baseurl}}/docs/pipelines/pipelines/#pipeline-concepts).
+
+## Runner
+The Runner is the hybrid installation option for pipelines in your Codefresh account. The Runner is installed as a Kubernetes native application on any Kubernetes-compliant cluster. It allows you to run pipelines on your own Kubernetes cluster, including private clusters behind company firewalls.
+
+Codefresh Runner gives you:
+* Access to secure services (such as Git repositories or databases) that are behind the firewall and normally not accessible to the public cloud.
+* The ability to use special resources in your Codefresh pipeline that are unique to your application, GPU nodes or other special hardware only present in your data center.
+* Complete control over the build environment in addition to resources for pipelines.
+
+Every Runner installation creates a runtime environment in your account. Assign the Runner to any pipeline to automatically run the pipeline in your own cluster. External integrations (such as Docker registry or Helm repositories) are also available to the Runner making pipelines exactly the same regardless of their runtime environment.
+
+You can have multiple Runner installations in the same Codefresh account. A Runner can also manage multiple remote clusters in your account.
+
+See [Codefresh Runner installation]({{site.baseurl}}/docs/installation/codefresh-runner) and [Runner installation behind firewalls]({{site.baseurl}}/docs/installation/behind-the-firewall)
+
+## Runtime
+A Runtime in Codefresh is a GitOps installation in your Codefresh account, in either a Hosted or Hybrid installation environment. Hosted Runtimes are installed on a Codefresh cluster and managed by Codefresh. Hybrid Runtimes are installed on customer clusters, and managed by the customers.
+You can install a single Hosted runtime, and multiple Hybrid Runtines in a Codefresh account.
+
+
+
+A single Runtime can connect to and manage multiple remote clusters.
+
+
+See:
+[GitOps runtime architecture]({{site.baseurl}}/docs/installation/runtime-architecture/#gitops-architecture)
+[Hybrid GitOps Runtime installation]({{site.baseurl}}/docs/installation/gitops/hybrid-gitops)
+[Hosted GitOps Runtime installation]({{site.baseurl}}/docs/installation/gitops/hosted-runtime)
+
+
+## Triggers
+Triggers are events that launch pipelines and Argo Workflows in Codefresh.
+
+Codefresh pipelines offer a rich set of triggers. You have triggers based on code-repository events triggers (Git triggers), triggers based on events in external systems (Docker Hub, Azure, Quay, and more), and triggers based on scheduled jobs (Cron).
+See:
+[Triggers in Codefresh pipelines]({{site.baseurl}}/docs/pipelines/triggers/)
+
+For Argo Workflows in Codefresh, triggers are managed by Argo Events. You can define the event-source and the Sensor that determines if and when to trigger the event. Codefresh supports Git and Cron events for Argo Workflows.
+
+To enable Argo Workflows in Codefresh, contact support.
+
+See:
+[Trigger conditions for events]({{site.baseurl}}/docs/workflows/create-pipeline/#configure-trigger-conditions-for-events)
+
+
+
+## Argo Workflows
+
+A workflow is a type of Kubernetes resource that lets you define and run automated workflows, and stores their state.
+Argo Workflows is an open source workflow engine that orchestrates parallel tasks on Kubernetes, implemented as a set of Kubernetes custom resource definitions (CRDs).
+
+Argo Workflows is part of the Argo project, which provides Kubernetes-native software delivery tools including Argo CD, Argo Events and Argo Rollouts.
+
+
+## Related articles
+[Codefresh for CI]({{site.baseurl}}/docs/getting-started/ci-codefresh/)
+[Codefresh for CD]({{site.baseurl}}/docs/getting-started/cd-codefresh/)
+[Codefresh for GitOps]({{site.baseurl}}/docs/getting-started/gitops-codefresh/)
diff --git a/_docs/getting-started/create-a-basic-pipeline.md b/_docs/getting-started/create-a-basic-pipeline.md
deleted file mode 100644
index 9f01b721a..000000000
--- a/_docs/getting-started/create-a-basic-pipeline.md
+++ /dev/null
@@ -1,527 +0,0 @@
----
-title: "Getting Started - Create a Basic Pipeline"
-description: "Continuous Integration with Codefresh"
-excerpt: ""
-group: getting-started
-redirect_from:
- - /docs/getting-started-create-a-basic-pipeline/
- - /docs/build-your-image/
-toc: true
----
-
-In this tutorial we will setup a [Continuous Integration](https://en.wikipedia.org/wiki/Continuous_integration) pipeline
-within Codefresh using an example application. You will learn:
-
-* How to connect your Git repository
-* How to connect your Docker registry
-* How to build a Docker image from the source code
-* How to push a Docker image to your registry
-* How to run unit tests for your application
-* How to publish your image to Dockerhub
-
-Codefresh is the fastest way to get from your source code to a Docker image. Codefresh allows you
-to create a Docker image from its friendly UI without any local Docker installation (Docker building as a service).
-
-You can store the resulting image on a public or private Docker registry that your organization already uses, or any other Docker registry
-service that you connect to your Codefresh account.
-
-Codefresh also has built-in support for [unit]({{site.baseurl}}/docs/testing/unit-tests/) and [integration testing]({{site.baseurl}}/docs/testing/integration-tests/) allowing you to only push Docker images that pass your testing suite. Finally, you can [add annotations]({{site.baseurl}}/docs/docker-registries/metadata-annotations/) to your Docker images to better track your releases (e.g. you can mark a Docker image with an annotation that shows a successful unit test run).
-
-You can use either the sample application we provide here to follow along or create your own Docker based
-example if you prefer (don't forget to write unit tests).
-
-## Prerequisites for this tutorial
-
-For this tutorial you will need:
-
- * A free [GitHub account](https://github.com/join)
- * A free [Codefresh account]({{site.baseurl}}/docs/getting-started/create-a-codefresh-account/)
- * An account to a Docker registry service (e.g. [GitHub](https://github.com/features/packages) )
- * The source code of the sample application
- * (Optional) an account to Dockerhub if you also want to make your image public
-
- We also assume that you are familiar with Docker and the build/run workflow it supports. Your applications should already come with their own Dockerfiles. If not, then read the [official documentation first](https://docs.docker.com/get-started/).
-
- Apart from Dockerhub, you can use the registry that comes with your cloud account ([Amazon](https://aws.amazon.com/ecr/), [Azure](https://azure.microsoft.com/en-us/services/container-registry/), [Google](https://cloud.google.com/container-registry)) or you can use any other compliant service such as [Quay](https://quay.io/), [Treescale](https://treescale.com/), [Canister.io](https://canister.io/) etc. GitHub also offers [a container registry](https://github.com/features/packages) with each account.
-
- The sample application can be found at [https://github.com/codefresh-contrib/python-flask-sample-app](https://github.com/codefresh-contrib/python-flask-sample-app). To bring the source
- code to your own account you need to "fork" the repository by clicking the respective button at the top right part of the page.
-
-
- {% include
-image.html
-lightbox="true"
-file="/images/getting-started/quick-start-ci/fork-example-project.png"
-url="/images/getting-started/quick-start-ci/fork-example-project.png"
-alt="Forking the example project"
-caption="Forking the example project (click image to enlarge)"
-max-width="80%"
-%}
-
-After some brief time, the repository should appear in your own GitHub account.
-Now you are ready to start building code with Codefresh!
-
-
-> Codefresh supports GitLab, Bitbucket and Azure GIT repositories apart from GitHub. The
-same principles presented in this tutorial apply for all Git providers.
-
-
-## Continuous Integration with Codefresh
-
-First, let's look at an overview of the process that we will create:
-
- {% include
-image.html
-lightbox="true"
-file="/images/getting-started/quick-start-ci/pipeline-overview.jpg"
-url="/images/getting-started/quick-start-ci/pipeline-overview.jpg"
-alt="Pipeline Overview"
-caption="Pipeline Overview"
-max-width="100%"
-%}
-
-The diagram above shows a full Continuous Integration pipeline for the sample application. Starting from left to right the critical path is:
-
-1. Codefresh connects to GitHub and checks out the source code of the application.
-1. Codefresh uses the Dockerfile of the application to create a Docker image.
-1. Unit tests are run in the same Docker image to verify the correctness of the code
-1. The Docker image is stored in your private Registry
-1. The Docker image is also pushed to Dockerhub (optional).
-
-
-The sample application that we are using is a [Python/Flask](https://www.palletsprojects.com/p/flask/) project with the following key points
-
- * It already has its own [Dockerfile](https://github.com/codefresh-contrib/python-flask-sample-app/blob/master/Dockerfile) in the root of the repository.
- * It has unit tests.
-
-## Creating a Docker Image
-
-We will start by focusing on the first part of the pipeline overview, the creation of a Docker images.
-
-{% include
-image.html
-lightbox="true"
-file="/images/getting-started/quick-start-ci/docker-build-steps.jpg"
-url="/images/getting-started/quick-start-ci/docker-build-steps.jpg"
-alt="Preparing a Docker image"
-caption="Preparing a Docker image"
-max-width="60%"
-%}
-
-Docker images play a central role in Codefresh pipelines. They are the basic building blocks that serve as the link
-between what your source code is producing and what gets deployed. If your own application is not "dockerized" yet, you
-need to create a Dockerfile for it first, before moving it into the Codefresh infrastructure.
-
-Because all Codefresh capabilities are based on Docker images, Docker is also serving as an abstraction layer over any the implementation language of your source code. Codefresh can work with projects written in Ruby, Python, Java, Node or any other programming language as long as they produce a Docker image. Docker images are a first class citizen in Codefresh pipelines and not just an afterthought.
-
-The example application already comes with its own Dockerfile, making the creation of a Codefresh pipeline very easy.
-Let's start by going into the [Codefresh dashboard](https://g.codefresh.io/projects/) (after [creating your account]({{site.baseurl}}/docs/getting-started/create-a-codefresh-account/)).
-
-### Connecting your Docker registry to Codefresh
-
-Before we create the pipeline you need to connect at least one Docker registry in your Codefresh account. The pipeline will use this registry to store the Docker image of the application.
-
-Go to your [Registry Configuration screen](https://g.codefresh.io/account-admin/account-conf/integration/registry) and connect your Docker registry. Codefresh supports [all popular Docker registries]({{site.baseurl}}/docs/integrations/docker-registries/) as well as any service that follows the registry specification. If you don't already have a registry we recommend you start with the [GitHub Registry]({{site.baseurl}}/docs/integrations/docker-registries/github-container-registry/).
-
-
-{% include
-image.html
-lightbox="true"
-file="/images/getting-started/quick-start-ci/external-registries.png"
-url="/images/getting-started/quick-start-ci/external-registries.png"
-alt="Connecting a Docker registry to Codefresh"
-caption="Connecting a Docker registry to Codefresh"
-max-width="60%"
-%}
-
-If you connect multiple Docker registries make sure that you select one as the "default". This will be used automatically by the pipeline as you will see later in the build stage.
-
-
-### Creating a new project
-
-With the Docker registry connected, we can now start our pipeline.
-
-Codefresh pipelines are grouped under [projects]({{site.baseurl}}/docs/configure-ci-cd-pipeline/pipelines/#pipeline-concepts). Project names can be anything you want with the most common example being the name of an application where all pipelines in the project are packaging/deploying the different microservices. You can think of projects as "folders/directories" for your pipelines.
-
-Make sure that you have selected *Projects* from the left sidebar. Then click on the *New project* button on the top right corner to get started.
-
-Enter a name for your project (e.g. `my-first-project`) and choose a sample icon that you like. You can also optionally add tags that will be used for [access control]({{site.baseurl}}/docs/enterprise/access-control/) (most useful in a organization). For now leave the tags empty.
-
-Click the *Create* button once you are done.
-You now have a new project and can start adding pipelines in it.
-
-### Creating a new pipeline
-
-Click the *New pipeline* button in order to create a pipeline.
-Enter any name (e.g. `basic-build`).
-
-{% include
-image.html
-lightbox="true"
-file="/images/getting-started/quick-start-ci/create-pipeline.png"
-url="/images/getting-started/quick-start-ci/create-pipeline.png"
-alt="Create a new pipeline"
-caption="Create a new pipeline (click image to enlarge)"
-max-width="50%"
-%}
-
-Find your repository from the list and select it. Make sure that the option *Add Git commit trigger* is selected. This way your pipeline will be automatically launched when a commit happens on this repository.
-
-Click the *Create* button. Your pipeline was created and you should now see the pipeline editor. Here you can describe what the pipeline will do using [Codefresh YAML]({{site.baseurl}}/docs/codefresh-yaml/what-is-the-codefresh-yaml/).
-
-### Build the docker image
-
-Codefresh has already created a sample pipeline which we will not use for this tutorial.
-
-You will create a very simple pipeline that checks out the source code and builds a docker image.
-Delete the existing contents on the editor and paste the following:
-
-`codefresh.yml`
-{% highlight yaml %}
-{% raw %}
-version: '1.0'
-stages:
- - checkout
- - package
-steps:
- main_clone:
- title: Cloning main repository...
- type: git-clone
- repo: '${{CF_REPO_OWNER}}/${{CF_REPO_NAME}}'
- revision: '${{CF_REVISION}}'
- stage: checkout
- MyAppDockerImage:
- title: Building Docker Image
- type: build
- stage: package
- image_name: my-app-image
- working_directory: ./
- tag: v1.0.0
- dockerfile: Dockerfile
-{% endraw %}
-{% endhighlight %}
-
-This pipeline contains just two steps.
-
-* A [`git-clone`]({{site.baseurl}}/docs/codefresh-yaml/steps/git-clone/) step for checking out the code
-* A [`build`]({{site.baseurl}}/docs/codefresh-yaml/steps/build/) step for building the docker image **AND** pushing it to the connected Docker registry.
-
-The clone step is also using some [built-in pipeline variables]({{site.baseurl}}/docs/codefresh-yaml/variables/). They instruct the pipeline to checkout the exact code that is described from the commit of the trigger. Don't worry if the exact details are not clear to you yet.
-
-The build step uses a [Dockerfile](https://github.com/codefresh-contrib/python-flask-sample-app/blob/master/Dockerfile) that is located at the root folder of the project and creates a Docker image with tag `v1.0.0`.
-
-Click the *Save* button to apply your changes. Then click the *Run* button to start your pipeline.
-On the dialog that will appear leave the default selections.
-
-
-### Starting the first build
-
-Once the build is started Codefresh will navigate you to the build progress of the sample application.
-
-{% include
-image.html
-lightbox="true"
-file="/images/getting-started/quick-start-ci/building.png"
-url="/images/getting-started/quick-start-ci/building.png"
-alt="Monitoring the build"
-caption="Monitoring the build (click image to enlarge)"
-max-width="50%"
-%}
-
-The build output is split into sections. Expand the section *Building Docker Image* and look at the logs.
-After a while the build should finish with success. All previous runs are in the [Builds page](https://g.codefresh.io/builds) from now on.
-
-{% include
-image.html
-lightbox="true"
-file="/images/getting-started/quick-start-ci/finished-build.png"
-url="/images/getting-started/quick-start-ci/finished-build.png"
-alt="Build details"
-caption="Build details (click image to enlarge)"
-max-width="80%"
-%}
-
-## Running unit tests automatically
-
-Like any well-disciplined project, the sample application comes with its associated unit tests. Running unit tests
-as part of the build process can validate that the Docker image is indeed correct and satisfies the requested functionality.
-This is the next step in the build process described at the beginning of this tutorial.
-
-{% include
-image.html
-lightbox="true"
-file="/images/getting-started/quick-start-ci/unit-test-stage.jpg"
-url="/images/getting-started/quick-start-ci/unit-test-stage.jpg"
-alt="Unit tests workflow"
-caption="Unit tests workflow (click image to enlarge)"
-max-width="80%"
-%}
-
-
-
-We need to add the tests in the build process. To do this we will get back to the pipeline settings of the application. Click on the name of the pipeline you created in the build log screen so you can edit the yaml file.
-
-The sample application already has unit tests that can be executed with:
-
-```
-pip install pytest && pytest
-```
-
-Edit the pipeline as below:
-
-`codefresh.yml`
-{% highlight yaml %}
-{% raw %}
-version: '1.0'
-stages:
- - checkout
- - package
- - test
-steps:
- main_clone:
- title: Cloning main repository...
- type: git-clone
- repo: '${{CF_REPO_OWNER}}/${{CF_REPO_NAME}}'
- revision: '${{CF_REVISION}}'
- stage: checkout
- MyAppDockerImage:
- title: Building Docker Image
- type: build
- stage: package
- image_name: my-app-image #Change to your image name
- working_directory: ./
- tag: v1.0.1
- dockerfile: Dockerfile
- MyUnitTests:
- title: Running Unit tests
- image: '${{MyAppDockerImage}}'
- stage: test
- commands:
- - pip install pytest
- - pytest
-{% endraw %}
-{% endhighlight %}
-
-Here we have added a new [freestyle step]({{site.baseurl}}/docs/codefresh-yaml/steps/freestyle/) in its own [stage]({{site.baseurl}}/docs/codefresh-yaml/stages/) that runs unit tests. Freestyle steps are running custom commands inside docker containers and in this case we run the python command [inside the docker image]({{site.baseurl}}/docs/codefresh-yaml/variables/#context-related-variables) that was just created from the previous step (mentioned by the `image` property)
-
-Notice that Codefresh also has the capability to run [integration tests]({{site.baseurl}}/docs/codefresh-yaml/steps/composition/) and get [test results]({{site.baseurl}}/docs/testing/test-reports/) as well. Therefore, regardless of the type of tests you employ, Codefresh can accommodate your testing process in a fully automated manner as part of the main build.
-
-This time the build results will contain a new section labeled *Running unit tests*. It will contain the
-test output of the application.
-
-{% include
-image.html
-lightbox="true"
-file="/images/getting-started/quick-start-ci/unit-test-result.png"
-url="/images/getting-started/quick-start-ci/unit-test-result.png"
-alt="Unit tests results"
-caption="Unit tests results (click image to enlarge)"
-max-width="60%"
-%}
-
-This concludes the basic build for the example application. Codefresh offers several more capabilities
-than the ones shown here. You can read more about pipelines in the [YAML documentation]({{site.baseurl}}/docs/codefresh-yaml/what-is-the-codefresh-yaml/).
-
-
-## Storing Docker images in Codefresh
-
-If you have been following along so far, you might already be wondering what happens with the resulting Docker image of each build. The Codefresh build logs show that a Docker image is created after each successful build. Where does this image go?
-
-Codefresh has the unique feature where the build step automatically pushes the image to your default Docker registry! All the images that we have created so far, are stored in the registry you connected in the previous section.
-
-{% include
-image.html
-lightbox="true"
-file="/images/getting-started/quick-start-ci/docker-store-stage.jpg"
-url="/images/getting-started/quick-start-ci/docker-store-stage.jpg"
-alt="Automatic storage of Docker images"
-caption="Automatic storage of Docker images"
-max-width="80%"
-%}
-
-If you only use a single registry your pipeline is now complete.
-
-You can inspect all your images from your previous builds by clicking on *Images* on the left panel. A list of Docker images will appear sorted starting from the most recent. This dashboard is getting live information from your connected Docker registry.
-
-{% include
-image.html
-lightbox="true"
-file="/images/getting-started/quick-start-ci/docker-images.png"
-url="/images/getting-started/quick-start-ci/docker-images.png"
-alt="Recent Docker images"
-caption="Recent Docker images (click image to enlarge)"
-max-width="100%"
-%}
-
-Among the information shown, you can clearly see:
-
-* What is the Git Branch that created this image
-* What is the Git Hash that contained the last commit
-
-This information can help you to easily correlate the changes that exist in each Docker images, which is very important knowledge when it comes to deployments (explained in detail in the next tutorial).
-
-If you click on a Docker image you will get many more details about it including a timeline of the labels for this Docker image. You also have the ability to enter custom comments that describe any event that you consider important. Codefresh
-really shines when it comes to annotating your Docker images with metadata. For more details read the section [Annotations]({{site.baseurl}}/docs/docker-registries/metadata-annotations/).
-
-{% include
-image.html
-lightbox="true"
-file="/images/getting-started/quick-start-ci/docker-timeline.png"
-url="/images/getting-started/quick-start-ci/docker-timeline.png"
-alt="Docker Image timeline"
-caption="Docker Image timeline (click image to enlarge)"
-max-width="50%"
-%}
-
-Codefresh also includes a graphical display of all the layers contained in the Docker image. This can help you identify big layers in your build process and hopefully give you some pointers on how to reduce the size of your deployment binaries.
-
-{% include
-image.html
-lightbox="true"
-file="/images/getting-started/quick-start-ci/docker-layers.png"
-url="/images/getting-started/quick-start-ci/docker-layers.png"
-alt="Docker Layer Analysis"
-caption="Docker Layer Analysis (click image to enlarge)"
-max-width="70%"
-%}
-
-The built-in Docker image storage is very helpful on its own, but it becomes even more impressive when it is coupled with the capability to use it as a basis for temporary demo environments, as we will see in the next section.
-
-
-
-## Uploading Docker images to Dockerhub
-
-Using the default Docker registry for automatic pushes is great for simple pipelines. However, sometimes you might also want to push your Docker image to a second registry or make it public in Dockerhub.
-
-Since the build step creates a Docker image and pushes it at the same time, Codefresh also [provides a push pipeline step]({{site.baseurl}}/docs/codefresh-yaml/steps/build/) that just pushes an existing Docker image.
-
-
-{% include
-image.html
-lightbox="true"
-file="/images/getting-started/quick-start-ci/docker-push-stage.jpg"
-url="/images/getting-started/quick-start-ci/docker-push-stage.jpg"
-alt="Pushing a Docker image"
-caption="Pushing a Docker image (click image to enlarge)"
-max-width="80%"
-%}
-
-
-Docker images are one of the central concepts in Codefresh pipelines as everything revolves around them. Powerful Codefresh pipelines can be created by using Docker images as build tools, so it is perfectly normal if you manage a large number of images which are not strictly packaged applications. You may create Docker images that contain building or deployment tools and are used as part of
-the build process instead of the build result.
-
-For the purposes of this tutorial we will also push our sample application to [DockerHub](https://cloud.docker.com/) which is the free public Docker hosting registry of Docker Inc. You need to create a free account with the service first and note down your username and password. In your own projects you can use any other [external registry]({{site.baseurl}}/docs/integrations/docker-registries/) you wish.
-
->Note that Docker.io only allows you to push images that are tagged with your username. If you have a choice, create
-a Dockerhub account with the same username that you have in Codefresh. If not, you need to change the Docker image
-created to match your username.
-
-Once you create your Docker Hub account, go to your Account Configuration, by clicking on *Account Settings* on the left sidebar of the Codefresh page. On the first section called *Integrations* click the *Configure* button next to *Docker Registry*.
-Finally click the *Add Registry* drop-down menu and select *Docker Hub*.
-
-{% include
-image.html
-lightbox="true"
-file="/images/getting-started/quick-start-ci/add-docker-hub.png"
-url="/images/getting-started/quick-start-ci/add-docker-hub.png"
-alt="Docker Hub credentials"
-caption="Docker Hub credentials (click image to enlarge)"
-max-width="60%"
-%}
-
-Enter your Docker Hub credentials and click the *TEST* button to verify the connection details. You should see a success message. We have now connected our Docker Hub account to our Codefresh account. Make sure that you note down the *Registry Name* you used.
-
-To actually use the Docker Hub account in a specific project, go back to your pipeline editor. Change the editor contents to:
-
-{% highlight yaml %}
-{% raw %}
-version: '1.0'
-stages:
- - checkout
- - package
- - test
- - upload
-steps:
- main_clone:
- title: Cloning main repository...
- type: git-clone
- repo: '${{CF_REPO_OWNER}}/${{CF_REPO_NAME}}'
- revision: '${{CF_REVISION}}'
- stage: checkout
- MyAppDockerImage:
- title: Building Docker Image
- type: build
- stage: package
- image_name: my-app-image
- working_directory: ./
- tag: v1.0.1
- dockerfile: Dockerfile
- MyUnitTests:
- title: Running Unit tests
- image: '${{MyAppDockerImage}}'
- stage: test
- commands:
- - pip install pytest
- - pytest
- MyPushStep:
- title: Pushing to Docker Registry
- type: push
- stage: upload
- tag: '${{CF_BRANCH}}'
- candidate: '${{MyAppDockerImage}}'
- image_name: kkapelon/pythonflasksampleapp #Change kkapelon to your dockerhub username
- registry: dockerhub # Name of your integration as was defined in the Registry screen
-{% endraw %}
-{% endhighlight %}
-
-We now have added a [push step]({{site.baseurl}}/docs/codefresh-yaml/steps/push/) at the end of the pipeline. The image is tagged with the name of the branch.
-
-Click *Save* to apply your changes and *Run* to start the pipeline again.
-In the build logs a new panel will appear that shows the push progress:
-
-{% include
-image.html
-lightbox="true"
-file="/images/getting-started/quick-start-ci/docker-pushing.png"
-url="/images/getting-started/quick-start-ci/docker-pushing.png"
-alt="Pushing to Docker Hub"
-caption="Pushing to Docker Hub (click image to enlarge)"
-max-width="70%"
-%}
-
-Note that this is in addition to default Docker registry of your Codefresh account. After the build is finished the Docker image of the sample application is stored **both** in the default Docker registry and in Dockerhub.
-
-To verify the latter, you can visit your profile in Dockerhub and look at the image details:
-
-{% include
-image.html
-lightbox="true"
-file="/images/getting-started/quick-start-ci/docker-hub.png"
-url="/images/getting-started/quick-start-ci/docker-hub.png"
-alt="Docker Image details"
-caption="Docker Image details (click image to enlarge)"
-max-width="60%"
-%}
-
-
-Pushing to Dockerhub is the last step in the build pipeline. Now that we have the basic functionality ready we can see how Codefresh handles [Continuous Integration](https://en.wikipedia.org/wiki/Continuous_integration) with Pull requests and automatic builds.
-
-
-## What to read next
-
-* [Introduction to Pipelines]({{site.baseurl}}/docs/configure-ci-cd-pipeline/introduction-to-codefresh-pipelines/)
-* [Working with Docker images]({{site.baseurl}}/docs/docker-registries/working-with-docker-registries/)
-* [Codefresh YAML]({{site.baseurl}}/docs/codefresh-yaml/what-is-the-codefresh-yaml/)
-* [On demand environments]({{site.baseurl}}/docs/getting-started/on-demand-environments/)
-* [Deploy to Kubernetes]({{site.baseurl}}/docs/getting-started/deployment-to-kubernetes-quick-start-guide/)
-
-
-
-
-
-
-
-
-
-
-
diff --git a/_docs/getting-started/create-a-codefresh-account.md b/_docs/getting-started/create-a-codefresh-account.md
deleted file mode 100644
index 14e06cdd9..000000000
--- a/_docs/getting-started/create-a-codefresh-account.md
+++ /dev/null
@@ -1,199 +0,0 @@
----
-title: "Create a Codefresh Account"
-description: "Welcome to Codefresh!"
-group: getting-started
-redirect_from:
- - /docs/
- - /docs/create-an-account/
- - /docs/getting-started/
- - /docs/getting-started/introduction/
----
-Before you can start building and deploying your applications
-you need to create a Codefresh account.
-
-Creating an account is free (no credit card is required) and can be done in 3 simple steps.
-
-{% include
-image.html
-lightbox="true"
-file="/images/getting-started/create-account/create-account-steps.png"
-url="/images/getting-started/create-account/create-account-steps.png"
-alt="Codefresh account creation steps"
-max-width="90%"
-%}
-
-## 1. Select your Identity Provider
-
-First, navigate to the [Codefresh Sign Up page](https://g.codefresh.io/signup).
-Codefresh currently supports GitHub, Bitbucket and GitLab as a Git provider. If you are using another Git provider
-please [contact us](https://codefresh.io/contact-us/) to discuss alternative options. You can also select
-Azure or Google as an identity provider.
-
-{% include
-image.html
-lightbox="true"
-file="/images/getting-started/create-account/select-identity-provider.png"
-url="/images/getting-started/create-account/select-identity-provider.png"
-alt="Codefresh sign-up page"
-caption="Sign-up page (click image to enlarge)"
-max-width="40%"
-%}
-
-The login method is not really important when it comes to git repositories as regardless of your sign-up process
-you can add git repositories from any of your GIT accounts in [GIT integrations]({{site.baseurl}}/docs/integrations/git-providers/).
-
-> Don't worry if by mistake you use multiple sign-up methods. As long as your email
-address is the same, Codefresh will automatically forward you to your account dashboard.
-
-
-## 2. Accept the Permissions Request
-
-After you select the Identity provider, Codefresh requests permission to access your basic details (and for GIT providers to access your Git repositories).
-
-Don't worry, Codefresh will not do anything without your explicit approval, so don't be scared by the permissions shown
-in the request window. The permissions requested by Codefresh are needed in order to build and deploy your projects.
-
-
-This is the GitHub permissions window. Click the button labeled *Authorize codefresh-io* to continue.
-
-{% include
-image.html
-lightbox="true"
-file="/images/getting-started/create-account/github-authorize.png"
-url="/images/getting-started/create-account/github-authorize.png"
-alt="GitHub authorization page"
-caption="GitHub authorization page (click image to enlarge)"
-max-width="50%"
-%}
-
-If you use Bitbucket the following permissions window will appear instead. Click the button labeled *Grant access* to continue.
-
-
-{% include
-image.html
-lightbox="true"
-file="/images/getting-started/create-account/bitbucket-authorize.png"
-url="/images/getting-started/create-account/bitbucket-authorize.png"
-alt="Bitbucket authorization page"
-caption="Bitbucket authorization page (click image to enlarge)"
-max-width="50%"
-%}
-
-Finally if you use GitLab you will see the permissions window shown below. Click the button labeled *Authorize* to continue.
-
-
-{% include
-image.html
-lightbox="true"
-file="/images/getting-started/create-account/gitlab-authorize.png"
-url="/images/getting-started/create-account/gitlab-authorize.png"
-alt="GitLab authorization page"
-caption="GitLab authorization page (click image to enlarge)"
-max-width="50%"
-%}
-
-Once you accept the respective permissions window, Codefresh will automatically connect to your Git provider and fetch your basic account details (such as your email).
-
-
-## 3. Verify Your Account Details
-
-Once Codefresh reads your details from your Identity provider it will present to you the account details for your new account. Review your account details, make the relevant changes, and click *NEXT*.
-
-{% include
-image.html
-lightbox="true"
-file="/images/getting-started/create-account/codefresh-signup.png"
-url="/images/getting-started/create-account/codefresh-signup.png"
-alt="Codefresh account details"
-caption="Codefresh account details (click image to enlarge)"
-max-width="40%"
-%}
-
-Name your account, and click *NEXT*.
-
-{% include
-image.html
-lightbox="true"
-file="/images/getting-started/create-account/codefresh-accountname.png"
-url="/images/getting-started/create-account/codefresh-accountname.png"
-alt="Codefresh account name"
-caption="Codefresh account name (click image to enlarge)"
-max-width="40%"
-%}
-
-Finally, answer the questions to personalize your account and click *FINISH*.
-
-{% include
-image.html
-lightbox="true"
-file="/images/getting-started/create-account/codefresh-personalize.png"
-url="/images/getting-started/create-account/codefresh-personalize.png"
-alt="Codefresh personalize account"
-caption="Codefresh personalize account (click image to enlarge)"
-max-width="40%"
-%}
-
-Congratulations! Your new Codefresh account is now ready.
-
-{% include
-image.html
-lightbox="true"
-file="/images/getting-started/create-account/codefresh-dashboard.png"
-url="/images/getting-started/create-account/codefresh-dashboard.png"
-alt="Codefresh dashboard"
-caption="Codefresh dashboard (click image to enlarge)"
-max-width="40%"
-%}
-
-
-
-The next step is learning how to [build your first application]({{site.baseurl}}/docs/getting-started/create-a-basic-pipeline/).
-
-
-## Other Git connection options
-
-
-
-Codefresh also supports Atlassian Stash/Bitbucket Server. You need to [contact us](https://codefresh.io/contact-us/) to enable this integration before you can use it for your account.
-
-
-{% include
-image.html
-lightbox="true"
-file="/images/getting-started/create-account/stash.png"
-url="/images/getting-started/create-account/stash.png"
-alt="Codefresh and Atlassian Stash"
-caption="Codefresh and Atlassian Stash"
-max-width="100%"
-%}
-
-
-Once that is done, follow the [Stash instructions]({{site.baseurl}}/docs/integrations/git-providers/#atlassian-stash) for more information.
-
-
-
-## Using Codefresh in a secure corporate environment
-
-If your source code repositories are in a private Git account that lies behind your company firewall, or simply has no access to the Internet, we can still help you!
-
-{% include
-image.html
-lightbox="true"
-file="/images/getting-started/create-account/git-firewall.png"
-url="/images/getting-started/create-account/git-firewall.png"
-alt="Git behind firewall"
-caption="Git behind firewall"
-max-width="100%"
-%}
-
-We can establish a VPN / tunnel to your network or discuss options for an on-premises Codefresh deployment. Please [contact us to get started](https://codefresh.io/contact-us/).
-
-
-## What to read next
-
-* [Create a Basic pipeline]({{site.baseurl}}/docs/getting-started/create-a-basic-pipeline/)
-* [Deploy to Kubernetes]({{site.baseurl}}/docs/getting-started/deployment-to-kubernetes-quick-start-guide/)
-* [Introduction to Codefresh pipelines]({{site.baseurl}}/docs/configure-ci-cd-pipeline/introduction-to-codefresh-pipelines/)
-* [Pipeline examples]({{site.baseurl}}/docs/yaml-examples/examples/)
-
-
diff --git a/_docs/getting-started/deployment-to-kubernetes-quick-start-guide.md b/_docs/getting-started/deployment-to-kubernetes-quick-start-guide.md
deleted file mode 100644
index fd14126e7..000000000
--- a/_docs/getting-started/deployment-to-kubernetes-quick-start-guide.md
+++ /dev/null
@@ -1,285 +0,0 @@
----
-title: "Deployment to Kubernetes"
-description: "Using the Codefresh GUI to deploy to a Kubernetes cluster"
-group: getting-started
-redirect_from:
- - /docs/getting-started-deployment-to-kubernetes-quick-start-guide/
- - /docs/kubernetes
- - /docs/kubernetes/
-toc: true
----
-
-In this tutorial we will see how you can use Codefresh to deploy a Docker image to a Kubernetes cluster
-and also how to setup an automated pipeline to automatically redeploy it when the source code changes.
-
->Even though, in this tutorial we use Codefresh to deploy docker images directly to the Kubernetes cluster,
-in production we suggest you use [Helm]({{site.baseurl}}/docs/getting-started/helm-quick-start-guide/) instead. Helm is a package manager for Kubernetes that allows you to
-deploy multiple applications at once as a single entity (Helm Charts) and also perform rollbacks to previous versions.
-Like Kubernetes, [Codefresh has native support for Helm deployments]({{site.baseurl}}/docs/new-helm/using-helm-in-codefresh-pipeline/) including a [release dashboard]({{site.baseurl}}/docs/new-helm/helm-releases-management/).
-
-Notice that for this tutorial we will use the GUI provided by Codefresh to both create the Kubernetes service inside the cluster and also to create the CI/CD pipeline that keeps it up to date. In a real world scenario it is best if you use [Codefresh YAML]({{site.baseurl}}/docs/codefresh-yaml/what-is-the-codefresh-yaml/) which is much more powerful and flexible.
-
-Codefresh also offers [several alternative ways]({{site.baseurl}}/docs/deploy-to-kubernetes/deployment-options-to-kubernetes/) of deploying to Kubernetes.
-
-## Overview
-
-At the end of this tutorial we will have a pipeline that:
-
-1. Checks out code from GitHub and creates a Docker image
-1. Stores it in the default Docker registry of your Codefresh account
-1. Notifies the Kubernetes cluster that a new version of the application is present. Kubernetes will pull the new image and deploy it
-
- {% include
-image.html
-lightbox="true"
-file="/images/getting-started/quick-start-k8s/overview.png"
-url="/images/getting-started/quick-start-k8s/overview.png"
-alt="Deployment overview"
-caption="A complete CI/CD pipeline"
-max-width="80%"
-%}
-
-For simplicity reasons, we will use the [default Docker registry]({{site.baseurl}}/docs/docker-registries/external-docker-registries/#the-default-registry) that is setup globally in your Codefresh account. For your own application you can also use any other of your registries even if it is not the default.
-
-
-## Prerequisites
-
-It is assumed that:
- - You have already [added your Kubernetes cluster]({{site.baseurl}}/docs/deploy-to-kubernetes/add-kubernetes-cluster/) into Codefresh
- - You have connected at least one [Docker registry]({{site.baseurl}}/docs/docker-registries/external-docker-registries/) in your Codefresh account
- - You have already an application that has a Dockerfile. If not, see the [previous tutorial]({{site.baseurl}}/docs/getting-started/create-a-basic-pipeline/)
-
-Notice that for this tutorial you **don't** need a Kubernetes deployment file. Codefresh will create one for you via its friendly GUI. If you already have an existing deployment file for your own application, [consult the main K8s documentation]({{site.baseurl}}/docs/deploy-to-kubernetes/deployment-to-kubernetes-quick-start-guide/) on how to use it.
-
-
-## Deploying a Docker image to Kubernetes manually
-
-Codefresh offers a dedicated GUI that allows you to deploy any Docker image to your cluster without writing any configuration files at all.
-
-Click the *Kubernetes* button from the left side bar.
-The screen that appears is the Codefresh overview of your Kubernetes cluster that shows all your deployments (pods and namespaces)
-
- {% include
-image.html
-lightbox="true"
-file="/images/getting-started/quick-start-k8s/add-service-button.png"
-url="/images/getting-started/quick-start-k8s/add-service-button.png"
-alt="Codefresh Kubernetes Dashboard"
-caption="Codefresh Kubernetes Dashboard (click image to enlarge)"
-max-width="70%"
-%}
-
-
-Click *New* in the top right corner and then *Add Service button*. The screen that appears is a friendly UI that allows you to
-create a Kubernetes deployment (and associated service). You can also toggle the top right button to define a Kubernetes YAML yourself, but for the purposes of this tutorial we will only use the GUI.
-
- {% include
-image.html
-lightbox="true"
-file="/images/getting-started/quick-start-k8s/add-service.png"
-url="/images/getting-started/quick-start-k8s/add-service.png"
-alt="Codefresh Kubernetes add service"
-caption="Codefresh Kubernetes add service (click image to enlarge)"
-max-width="70%"
-%}
-
-
-The fields in this screen are:
-
-* *Cluster* - choose your cluster if you have more than one.
-* *Namespace* - select the namespace where the application will be deployed to (*default* will work just fine).
-* *Service Name* - enter any arbitrary name for your service.
-* *Replicas* - how many replicas you want for resiliency. This affects pricing, so 1 is a good value for a demo.
-* *Expose Port* - check it so that your application is available outside the cluster .
-* *Image* - enter the fully qualified name of your Docker image.
-* *Image Pull Secret* - select your default Docker registry and create a pull secret for it.
-* *Internal Ports* - which port is exposed from your application. The example Python app we deploy, exposes 5000.
-
-From the same screen you can also define environment variables and cpu/mem limits.
-
-You can see the full name of the Docker image, in the [Images tab](https://g.codefresh.io/images/) of the Codefresh GUI of your build.
-
- {% include
-image.html
-lightbox="true"
-file="/images/getting-started/quick-start-k8s/docker-image-name.png"
-url="/images/getting-started/quick-start-k8s/docker-image-name.png"
-alt="Finding the full name of a Docker image"
-caption="Finding the full name of a Docker image (click image to enlarge)"
-max-width="60%"
-%}
-
-By default, Codefresh appends the branch name of a git commit to the resulting Docker image. This is why
-in the *Image* field we used the branch name as tag
-
->Do not use `latest` for your deployments. This doesn't help you to understand which version is deployed. Use
-either branch names or even better git hashes so that you know exactly what is deployed on your Kubernetes cluster. Notice also that the YML manifest
-Codefresh is creating has an image pull policy of `always`, so the cluster will always redeploy the latest image even if it has the same name as the previous one.
-
-Finally click the *deploy* button. Codefresh will create a Kubernetes YAML file behind the scenes and apply it to your
-Kubernetes cluster. The cluster will contact the Codefresh registry and pull the image. The cluster will then create all the needed resources (service, deployments, pods) in order to make the application available.
-
-You can watch the status of the deployment right from the Codefresh UI.
-
- {% include
-image.html
-lightbox="true"
-file="/images/getting-started/quick-start-k8s/after-deployment.png"
-url="/images/getting-started/quick-start-k8s/after-deployment.png"
-alt="Codefresh K8s deployment"
-caption="Codefresh K8s deployment (click image to enlarge)"
-max-width="70%"
-%}
-
-Once the deployment is complete, you will also see the public URL of the application. You can visit it in the browser
-and see the application running.
-
- {% include
-image.html
-lightbox="true"
-file="/images/getting-started/quick-start-k8s/before-change.png"
-url="/images/getting-started/quick-start-k8s/before-change.png"
-alt="Example Python Application"
-caption="Example Python Application (click image to enlarge)"
-max-width="50%"
-%}
-
-This concludes the manual deployment. We deployed a Docker image from Codefresh to a Kubernetes cluster without
-writing any YAML files at all! The next step is to automate this process so that every time a commit happens in git, the application will be redeployed.
-
-## Automating deployments to Kubernetes
-
-The application is now running successfully in the Kubernetes cluster. We will setup a pipeline in Codefresh
-so that any commits that happen in GitHub, are automatically redeploying the application, giving us a true CI/CD pipeline.
-
-To do this, we will add two extra steps in the basic pipeline created in the [previous tutorial]({{site.baseurl}}/docs/getting-started/create-a-basic-pipeline/).
-
-Here is the complete pipeline:
-
-`codefresh.yml`
-{% highlight yaml %}
-{% raw %}
-version: '1.0'
-stages:
- - checkout
- - package
- - test
- - upload
- - deploy
-steps:
- main_clone:
- title: Cloning main repository...
- type: git-clone
- repo: '${{CF_REPO_OWNER}}/${{CF_REPO_NAME}}'
- revision: '${{CF_REVISION}}'
- stage: checkout
- MyAppDockerImage:
- title: Building Docker Image
- type: build
- stage: package
- image_name: my-app-image
- working_directory: ./
- tag: '${{CF_BRANCH}}'
- dockerfile: Dockerfile
- disable_push: true
- MyUnitTests:
- title: Running Unit tests
- image: '${{MyAppDockerImage}}'
- stage: test
- commands:
- - python setup.py test
- MyPushStep:
- title: Pushing to DockerHub Registry
- type: push
- stage: upload
- tag: '${{CF_BRANCH}}'
- candidate: '${{MyAppDockerImage}}'
- image_name: kkapelon/pythonflasksampleapp #Change kkapelon to your dockerhub username
- registry: dockerhub # Name of your integration as was defined in the Registry screen
- DeployToMyCluster:
- title: deploying to cluster
- type: deploy
- stage: deploy
- kind: kubernetes
- ## cluster name as the shown in account's integration page
- cluster: my-demo-k8s-cluster
- # desired namespace
- namespace: default
- service: python-demo
- candidate:
- # The image that will replace the original deployment image
- # The image that been build using Build step
- image: kkapelon/pythonflasksampleapp:${{CF_BRANCH}}
- # The registry that the user's Kubernetes cluster can pull the image from
- # Codefresh will generate (if not found) secret and add it to the deployment so the Kubernetes master can pull it
- registry: dockerhub
-{% endraw %}
-{% endhighlight %}
-
-You can see that we have added a new [deploy step]({{site.baseurl}}/docs/codefresh-yaml/steps/deploy/) at the end of the pipeline. Deploy steps allow you to deploy Kubernetes applications in a declarative manner. Codefresh offers many more [ways for Kubernetes deployments]({{site.baseurl}}/docs/deploy-to-kubernetes/deployment-options-to-kubernetes/).
-
-The deploy step will update an *existing* Kubernetes deployment and will optionally create a [pull secret]({{site.baseurl}}/docs/deploy-to-kubernetes/access-docker-registry-from-kubernetes/) for the image if needed, but it will not create any Kubernetes services (which is ok in our case as we created it manually in the previous section).
-
-Once all the details are filled in the pipeline editor, click the *Save* button.
-
-Now we will change the application in the production branch and commit/push the change to Git.
-
- {% include
-image.html
-lightbox="true"
-file="/images/getting-started/quick-start-k8s/git-change.png"
-url="/images/getting-started/quick-start-k8s/git-change.png"
-alt="Git change"
-caption="Git change (click image to enlarge)"
-max-width="70%"
-%}
-
-Codefresh will pick the change automatically and [trigger]({{site.baseurl}}/docs/configure-ci-cd-pipeline/triggers/) a new build that deploys the new version:
-
-
-
- {% include
-image.html
-lightbox="true"
-file="/images/getting-started/quick-start-k8s/deployment-build.png"
-url="/images/getting-started/quick-start-k8s/deployment-build.png"
-alt="Codefresh K8s deployment"
-caption="Codefresh K8s deployment (click image to enlarge)"
-max-width="90%"
-%}
-
-
-Once the build is complete, if you visit again the URL you will see your change
-applied.
-
- {% include
-image.html
-lightbox="true"
-file="/images/getting-started/quick-start-k8s/after-change.png"
-url="/images/getting-started/quick-start-k8s/after-change.png"
-alt="Example Python Application after change"
-caption="Example Python Application after change (click image to enlarge)"
-max-width="50%"
-%}
-
-You now have a complete CI/CD pipeline in Codefresh for fully automated builds to Kubernetes!
-
-## What to read next
-
-* [Deploying to Kubernetes with Helm]({{site.baseurl}}/docs/getting-started/helm-quick-start-guide/)
-* [Kubernetes deployment methods]({{site.baseurl}}/docs/deploy-to-kubernetes/deployment-options-to-kubernetes/)
-* [Introduction to Pipelines]({{site.baseurl}}/docs/configure-ci-cd-pipeline/introduction-to-codefresh-pipelines/)
-* [Working with Docker registries]({{site.baseurl}}/docs/docker-registries/working-with-docker-registries/)
-* [Codefresh YAML]({{site.baseurl}}/docs/codefresh-yaml/what-is-the-codefresh-yaml/)
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/_docs/getting-started/faq.md b/_docs/getting-started/faq.md
deleted file mode 100644
index 2f0c109fd..000000000
--- a/_docs/getting-started/faq.md
+++ /dev/null
@@ -1,169 +0,0 @@
----
-title: "Frequently Asked Questions"
-description: ""
-group: getting-started
-redirect_from:
- - /docs/kubernetes-frequently-asked-questions/
- - /docs/kubernetes-deployment-frequently-asked-questions/
- - /docs/faq/kubernetes-frequently-asked-questions/
----
-
-This is a collection of common questions we get when people are trying Codefresh for the first time.
-
-## General
-
-**Q. What is Codefresh?**
-A. Codefresh is a [Continuous Integration/Delivery](https://en.wikipedia.org/wiki/Continuous_delivery) solution. It fetches code from your GIT repository and packages/compiles it. Then it deploys the final artifact to a target environment. This basic concept is implemented with [pipelines]({{site.baseurl}}/docs/configure-ci-cd-pipeline/pipelines/).
-
-**Q. Is there an on-premises version of Codefresh?**
-A. Yes. Codefresh is offered in [SAAS, Hybrid and on-premises modes]({{site.baseurl}}/docs/enterprise/installation-security/). Before you consider on-premises please look at the [hybrid mode first]({{site.baseurl}}/docs/enterprise/behind-the-firewall/). In this mode Codefresh runs the Web UI while you only maintain the build nodes behind the firewall.
-
-**Q. Is Codefresh open-source?**
-A. The Web UI is not open source. All the [pipeline plugins](https://codefresh.io/steps/) and the [Codefresh Runner]({{site.baseurl}}/docs/enterprise/codefresh-runner/) are open-source. We also publish several open-source [components](https://github.com/codefresh-io), [examples](https://github.com/codefresh-contrib) and [demos](https://github.com/codefreshdemo/).
-
-**Q. Does Codefresh offer infrastructure for running builds?**
-A. Yes, the cloud version of Codefresh is fully [SAAS](https://en.wikipedia.org/wiki/Software_as_a_service). You only need to open an account and all builds are running on our cloud. You can still use a [Codefresh runner]({{site.baseurl}}/docs/enterprise/codefresh-runner/) to run builds on your own infrastructure, but this is completely optional.
-
-**Q. Does Codefresh offer infrastructure for test environments?**
-A. Yes, each Codefresh account has access to [preview environments]({{site.baseurl}}/docs/getting-started/on-demand-environments/) that are powered by Docker Swarm. You can also run [integration tests]({{site.baseurl}}/docs/testing/integration-tests/) with Databases, Key-Value stores, message queues etc.
-
-**Q. Does Codefresh offer infrastructure for production deployments?**
-A. No. You need to connect your own cloud provider either in the form of VMs, or Kubernetes cluster or Docker Swarm etc.
-
-**Q. Can I deploy with Codefresh to non-Kubernetes targets?**
-A. Yes. Even though Codefresh has great support for Docker and Kubernetes, you can still use it to deploy plain VMs, JAR files, static websites, Wordpress instances, Database changesets etc. Here is an example with [a traditional VM deployment]({{site.baseurl}}/docs/yaml-examples/examples/packer-gcloud/).
-
-## Competitors
-
-**Q. How is Codefresh different that another CI solution?**
-A. This is a long discussion. The quick answer is :
-1. Codefresh is a full CI/CD solution and not just CI.
-1. Codefresh works with all major Git platforms and Cloud providers. There is no lock-in with any particular vendor.
-1. Codefresh has [several unique features]({{site.baseurl}}/docs/configure-ci-cd-pipeline/introduction-to-codefresh-pipelines/) such as a [distributed docker layer cache]({{site.baseurl}}/docs/configure-ci-cd-pipeline/pipeline-caching/), an automounted shared volume, a private Docker registry and a private Helm repository.
-1. Specifically for Kubernetes/Helm, Codefresh has a [Kubernetes dashboard]({{site.baseurl}}/docs/deploy-to-kubernetes/manage-kubernetes/), a [Helm dashboard]({{site.baseurl}}/docs/new-helm/helm-releases-management/), a [Helm charts browser]({{site.baseurl}}/docs/new-helm/add-helm-repository/) and a [Helm environment board]({{site.baseurl}}/docs/new-helm/helm-environment-promotion/).
-1. The Docker registry integrations and all cluster integrations are automatically available to all pipelines. You don't need `docker login` commands or `kubectl` commands to setup a Kube context inside your pipeline.
-1. Codefresh covers the full software lifecycle. You can see a release on the cluster dashboard, click on it, go to the docker image, click on it and go the build that created it, all from a single interface. Codefresh is batteries-included CI/CD.
-
-**Q. How is Codefresh different than Jenkins?**
-A. Codefresh is a superset of Jenkins. Jenkins is only CI. You need to write custom scripts or use another tool such as Ansible to deploy with Jenkins. See the [comparison matrix](https://codefresh.io/compare-codefresh-jenkins/) and the [detailed blog post](https://codefresh.io/continuous-deployment/codefresh-versus-jenkins/). There is also [a comparison with Jenkins X](https://codefresh.io/continuous-deployment/codefresh-versus-jenkins-x/).
-
-**Q. How is Codefresh different than my custom deployment scripts in bash/Ansible/Chef/Puppet/Python?**
-A. These scripts are custom made, complex to maintain and difficult to read. One of the reasons that developers and operators have difficulties in communication is the in-house nature of deployment scripts. Codefresh allows you to create standard declarative pipelines
-where each step is a reusable Docker image.
-
-
-## Integration features
-
-**Q. Can Codefresh run a build on each push/commit?**
-A. Yes, this is one of the most basic functions of a CI system. See our [extensive git support]({{site.baseurl}}/docs/configure-ci-cd-pipeline/triggers/git-triggers/). You can also run builds in a [cron-like manner]({{site.baseurl}}/docs/configure-ci-cd-pipeline/triggers/cron-triggers/) or even from Docker push events from several popular Docker registries.
-
-**Q. Can Codefresh build pull requests?**
-A. Yes, this is one of the most basic functions of a CI system. See our [extensive git support]({{site.baseurl}}/docs/configure-ci-cd-pipeline/triggers/git-triggers/#pull-request-target-field-and-branch-name) and [built-in variables]({{site.baseurl}}/docs/codefresh-yaml/variables/#github-pull-request-variables).
-
-**Q. Can Codefresh build applications in programming language X?**
-A. Yes, Codefresh is agnostic in this manner. The only requirement is that you have a Docker image with the compiler/framework/libraries of your programming language. See some examples for [Java]({{site.baseurl}}/docs/learn-by-example/java/spring-boot-2/), [Go]({{site.baseurl}}/docs/learn-by-example/golang/golang-hello-world/), [Node.js]({{site.baseurl}}/docs/learn-by-example/nodejs/react/), [Ruby]({{site.baseurl}}/docs/learn-by-example/ruby/), [Php]({{site.baseurl}}/docs/learn-by-example/php/), [Python]({{site.baseurl}}/docs/learn-by-example/python/django/), [C++]({{site.baseurl}}/docs/learn-by-example/cc/cpp-cmake/), [C#]({{site.baseurl}}/docs/learn-by-example/dotnet/).
-
-**Q. Can Codefresh build applications which are not Dockerized?**
-A. Yes. Even though Codefresh is especially powerful with containers, you can still use it for traditional applications which are not deployed in containers. Here is [an example with a plain Go executable]({{site.baseurl}}/docs/learn-by-example/golang/goreleaser/) and another with a [C executable]({{site.baseurl}}/docs/learn-by-example/cc/c-make/).
-
-**Q. Can I run tests in my pipelines?**
-A. Codefresh supports all kinds of tests such as [unit tests]({{site.baseurl}}/docs/testing/unit-tests/) and [integration tests]({{site.baseurl}}/docs/testing/integration-tests/) as well as [test reports]({{site.baseurl}}/docs/testing/test-reports/).
-
-**Q. Does Codefresh support parallelism?**
-A. Yes, Codefresh supports both [parallel steps]({{site.baseurl}}/docs/codefresh-yaml/advanced-workflows/) (parallelism within a pipeline) as well as [parallel pipelines]({{site.baseurl}}/docs/integrations/codefresh-api/#using-codefresh-from-within-codefresh).
-
-**Q. Does Codefresh support preview environments for pull requests?**
-A. Yes, although notice that these [are powered by Docker swarm]({{site.baseurl}}/docs/getting-started/on-demand-environments/). If you want preview environments in a Kubernetes namespace you need to connect your own cluster.
-
-**Q. Can I checkout code from non-git sources?**
-A. Yes, you can checkout code [from other source control systems]({{site.baseurl}}/docs/yaml-examples/examples/non-git-checkout/).
-
-**Q. Does Codefresh support git submodules?**
-A. Yes, there is a [git submodule plugin](https://codefresh.io/steps/step/git-submodules).
-
-**Q. Does Codefresh support git monorepos?**
-A. Yes, there is built-in support for [monorepos]({{site.baseurl}}/docs/configure-ci-cd-pipeline/triggers/git-triggers/#monorepo-support-modified-files).
-
-**Q. Does Codefresh support pipeline-as-code?**
-A. Yes, all pipelines can be stored in a git repository (the same one as the application code or a different one). You can also [create pipelines]({{site.baseurl}}/docs/integrations/codefresh-api/#example---creating-codefresh-pipelines-externally) programmatically with our [CLI](https://codefresh-io.github.io/cli/).
-
-**Q. Does Codefresh support secrets?**
-A. For basic usage, feel free to use the [shared configuration]({{site.baseurl}}/docs/configure-ci-cd-pipeline/shared-configuration/) facility. For production grade security we suggest a dedicated solution such as [Hashicorp Vault](https://www.vaultproject.io/). We offer a [vault plugin](https://codefresh.io/steps/step/vault) for this purpose.
-
-**Q. Can I call external service X in a pipeline?**
-A. Yes, everything that has an API or CLI can be called in a Codefresh pipeline (Artifactory/S3/Slack/SonarQube/Twistlock/Codecov etc)
-
-
-## Deployment features
-
-**Q. Can I deploy to different environments (dev/staging/prod)?**
-A. Yes, you can even deploy in parallel to several environments. If you also use Helm you get a [nice graphical dashboard]({{site.baseurl}}/docs/new-helm/helm-environment-promotion/).
-
-
-**Q. Can I pause a pipeline and wait for approval before deploying to production?**
-A. Yes, there is a built-in [approval step]({{site.baseurl}}/docs/codefresh-yaml/steps/approval/).
-
-**Q. Can I deploy to non-Kubernetes targets?**
-A. Yes, you can deploy [to a VM]({{site.baseurl}}/docs/yaml-examples/examples/packer-gcloud/), an FTP site, an application server or even a behind-the-firewall [Nomad cluster]({{site.baseurl}}/docs/yaml-examples/examples/nomad/). You can deploy to anything that has an API or CLI.
-
-**Q. Does Codefresh support infrastructure as code?**
-A. Yes, there is nothing special to it. See the [Terraform]({{site.baseurl}}/docs/yaml-examples/examples/terraform/) and [Pulumi]({{site.baseurl}}/docs/yaml-examples/examples/pulumi/) examples.
-
-**Q. Can I connect my own Docker registry?**
-A. Yes, you can connect your [own external registry]({{site.baseurl}}/docs/docker-registries/external-docker-registries/) as long as Codefresh has network access to it.
-
-**Q. My Kubernetes cluster has automatic scaling/monitoring/logging. Will Codefresh have issues with it?**
-A. Codefresh is using the standard Kubernetes API available to all compliant Kubernetes distributions. After a deployment is finished, Codefresh does not tamper with the cluster in any way.
-
-**Q. Do you support deployment to Kubernetes clusters on Azure, Amazon, etc?**
-A. Yes, we do! If your master node is publicly accessible you can access it as a custom provider, just follow the [cluster connection]({{site.baseurl}}/docs/deploy-to-kubernetes/add-kubernetes-cluster/) instructions.
-In addition, we have native integration with GKE, Azure, Amazon, and Digital Ocean.
-Native Integration with more cloud providers is coming soon.
-
-**Q. Can I run Codefresh pipelines on my Kubernetes cluster?**
-You can but you don't need to. The SAAS version of Codefresh is fully managed and pipelines are running on the cloud.
-You can run Codefresh pipelines on your own cluster using the [Codefresh Runner]({{site.baseurl}}/docs/enterprise/codefresh-runner/) in [Hybrid mode]({{site.baseurl}}/docs/enterprise/behind-the-firewall/). This is normally only needed if you want to access services behind your firewall. If you simply want to *deploy* to a Kubernetes cluster, the SAAS version of Codefresh is enough.
-
-## User interface
-
-**Q. What toolkit does the Codefresh UI use?**
-A. We use Angular JS.
-
-**Q. Can I use Codefresh without the graphical dashboards?**
-A. Yes, all Codefresh functionality is available via our [API]({{site.baseurl}}/docs/integrations/codefresh-api/) and [CLI](https://codefresh-io.github.io/cli/).
-
-**Q. What are the browser requirements for the Codefresh UI?**
-A. We officially support the latest version of the Chrome browser. Any browser released in the last 2 years should work without any 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 |
-
-## Enterprise support
-
-**Q. Does Codefresh support SSO?**
-A. Yes, we support several [popular SSO providers]({{site.baseurl}}/docs/single-sign-on/sso-overview/).
-
-**Q. Does Codefresh support access control?**
-A. Yes, we support both UI and ABAC on [pipelines, projects and clusters]({{site.baseurl}}/docs/enterprise/access-control/).
-
-**Q. Does Codefresh support auditing?**
-A. Yes, audit logs are [built-in]({{site.baseurl}}/docs/enterprise/audit-logs/).
-
-**Q. Is Codefresh security certified?**
-A. We are currently SOC2 compliant and are working to get other certifications as well.
-
-**Q. Do you offer professional services to help us migrate to containers/Kubernetes?**
-A. Yes, we do.
-
-## What to read next
-
-* [Your first CI/CD pipeline]({{site.baseurl}}/docs/getting-started/create-a-basic-pipeline/)
-* [How Codefresh pipelines work]({{site.baseurl}}/docs/configure-ci-cd-pipeline/introduction-to-codefresh-pipelines/)
-* [Kubernetes Deployment tutorial]({{site.baseurl}}/docs/getting-started/deployment-to-kubernetes-quick-start-guide/)
-* [Helm Deployment Tutorial tutorial]({{site.baseurl}}/docs/getting-started/helm-quick-start-guide/)
diff --git a/_docs/getting-started/gitops-codefresh.md b/_docs/getting-started/gitops-codefresh.md
new file mode 100644
index 000000000..357d13570
--- /dev/null
+++ b/_docs/getting-started/gitops-codefresh.md
@@ -0,0 +1,85 @@
+---
+title: "Codefresh for GitOps"
+description: "GitOps and Argo CD with Codefresh"
+group: getting-started
+toc: true
+---
+
+This article reviews the concepts of GitOps and Argo CD, and how Codefresh integrates with and implements both.
+
+
+## GitOps
+
+GitOps is a set of best practices for application/infrastructure deployment centered around the concept of using Git as the single source of truth.
+
+You can read more about GitOps at [OpenGitOps.dev](https://opengitops.dev/).
+
+ Git repositories are the source-control systems that declaratively describe applications and infrastructure using code. The continuous integration and continuous delivery processes synchronize these changes with live environments, making sure that the production state always matches the desired state in Git.
+
+The entire application lifecycle is managed by Git.
+
+The key difference is that while the traditional workflow is based on “pushing” new code changes through the pipeline to production, a GitOps workflow is a “pull” process in which new changes are submitted, and the GitOps agent detects and synchronizes them with the production environment.
+
+Read more in our blog, [What is a GitOps workflow](https://codefresh.io/learn/gitops/gitops-workflow-vs-traditional-workflow-what-is-the-difference/){:target="\_blank"}.
+
+
+
+## Argo CD
+
+Argo CD is "a declarative, GitOps continuous delivery tool for Kubernetes."
+
+Argo CD uses a Kubernetes controller to constantly monitor the state of all resources in production and compare them against the desired states set in Git. When there are changes to the desired state, the controller detects them, and works to synchronize the production configuration to the desired configuration.
+
+Argo CD is also designed to work with Argo Rollouts, a progressive delivery tool for handling canary and blue/green deployments with robust support for most load balancers in use today.
+
+
+## Codefresh for GitOps & Argo CD
+
+Where does Codefresh come into play with GitOps and Argo CD?
+
+Codefresh is the easiest way to get started with GitOps and Argo CD. Codefresh leverages Argo components to have the entire desired state applied from Git to your Kubernetes cluster, and then reported back to Codefresh.
+
+
+
+## GitOps Runtimes
+
+Codefresh offers two models for GitOps deployments:
+
+* Hosted GitOps, which is a fully-managed version of Argo CD. The runtime for Hosted GitOps is hosted on a Codefresh cluster (easy setup) and managed by Codefresh (zero maintenance overhead).
+ If you already have Argo CD installations, this is the option for you. Click once to provision the hosted runtime, and start deploying applications to clusters without having to install and maintain Argo CD.
+
+* Hybrid GitOps, which is a customer-managed version of Argo CD. The Hybrid GitOps runtime is hosted on the customer cluster and managed by the customer.
+ The Hybrid GitOps offering retains runtimes within the customer infrastructure to comply your security rewhile giving you the power of Argo CD with Codefresh’s CI and CD tools, to help achieve continuous integration and continuous delivery goals.
+
+Review [GitOps runtime architecture]({{site.baseurl}}/docs/installation/runtime-architecture/#gitops-architecture).
+For installation, see [Hosted GitOps setup]({{site.baseurl}}/docs/installation/gitops/hosted-runtime/) and [Hybrid GitOps installation]({{site.baseurl}}/docs/installation/gitops/hybrid-gitops/).
+
+## Argo CD applications
+
+Codefresh supports the complete lifecycle to create and deploy Argo CD applications.
+
+You can create full-featured Argo CD applications in Form or YAML modes. Built-in validations make it easy to identify and fix errors before commit.
+
+The application is also completely GitOps-compliant. The application manifest is generated, committed to Git, and synced to your cluster.
+See [Creating]({{site.baseurl}}/docs/deployments/gitops/create-application/) and [Managing]({{site.baseurl}}/docs/deployments/gitops/manage-application/) GitOps applications.
+
+
+Once deployed, our dashboards give you enterprise-wide visibility into deployments, and key metrics.
+From global analytics on applications and deployments (), to failure rate and lead time for changes (DORA dashboard), to application configuration, resource, and rollout management (Applications dashboard).
+
+See:
+[Home]({{site.baseurl}}/docs/dashboards/home-dashboard/)
+[DORA metrics]({{site.baseurl}}/docs/dashboards/dora-metrics/)
+[Monitoring applications]({{site.baseurl}}/docs/deployments/gitops/applications-dashboard/)
+
+## Codefresh & the Argo Project
+
+Codefresh unified all 4 projects of the Argo family into a single *Runtime*, providing an enterprise-supported version of all projects enhanced with unique functionality.
+
+>Our users rely on the Codefresh platform to deliver software, reliably and predictably, without disruptions. To maintain that high standard, we add several weeks of testing and bug fixes to new versions of Argo before making them available within Codefresh. Typically, new versions of Argo are available within 30 days of their release.
+
+## Related articles
+[Codefresh for CI]({{site.baseurl}}/docs/getting-started/ci-codefresh/)
+[Codefresh for CD]({{site.baseurl}}/docs/getting-started/cd-codefresh/)
+[Concepts in Codefresh]({{site.baseurl}}/docs/getting-started/concepts/)
+[Introduction to Codefresh]({{site.baseurl}}/docs/getting-started/intro-to-codefresh/)
diff --git a/_docs/getting-started/helm-quick-start-guide.md b/_docs/getting-started/helm-quick-start-guide.md
deleted file mode 100644
index 9fcf29de4..000000000
--- a/_docs/getting-started/helm-quick-start-guide.md
+++ /dev/null
@@ -1,336 +0,0 @@
----
-title: "Deployment to Kubernetes with Helm"
-description: "Using the Helm package Manager in Codefresh"
-group: getting-started
-toc: true
----
-
-In the [previous quick start guide]({{site.baseurl}}/docs/getting-started/deployment-to-kubernetes-quick-start-guide/) we have seen how you can deploy quickly an application directly to Kubernetes.
-In this guide we will see how we can use [Helm](https://helm.sh/) for deployments and what facilities Codefresh offers to make
-it easier to work with Helm packages.
-
-Helm is a package manager for Kubernetes. It behaves similar to other package managers (yum, apt, npm, maven, pip, gems) but it works at the application level allowing you to deploy multiple manifests together.
-
-Helm offers several extra features on top of vanilla Kubernetes deployments, some of which are:
-
-* The ability to group multiple Kubernetes manifests together and treat them as a single entity (for deployments, rollbacks, and storage). Groups of Manifests are called [Helm Charts](https://helm.sh/docs/topics/charts/).
-* Built-in templating for Kubernetes manifests, putting an end to custom template systems that you might use for replacing things such as the Docker tag inside a manifest.
-* The ability to create Charts of Charts which contain the templates as well as default values. This means
-that you can describe the dependencies of an application in the service level and deploy everything at the same time.
-* The ability to create catalogs of applications (Helm repositories) that function similar to traditional package repositories (think npm registry, cpan, maven central, ruby gems etc).
-
-
-Codefresh has native support for Helm in a number of ways:
-
-1. You can easily deploy existing Helm packages to your Kubernetes cluster overriding the default values.
-1. You can easily create new Helm packages and push them to a Helm repository.
-1. Codefresh gives you an [integrated Helm Repository]({{site.baseurl}}/docs/new-helm/managed-helm-repository/).
-1. You can see the Helm releases and even [perform rollbacks]({{site.baseurl}}/docs/new-helm/helm-releases-management/) from the Helm Dashboard.
-1. You can [browse Helm packages]({{site.baseurl}}/docs/new-helm/add-helm-repository/) both from public repositories and your internal Helm repository.
-1. You can see Helm releases in the [Environment dashboard]({{site.baseurl}}/docs/deploy-to-kubernetes/environment-dashboard/)
-1. You can promote Helm releases with the [Promotion dashboard]({{site.baseurl}}/docs/new-helm/helm-environment-promotion/)
-
-
-## Overview
-
-In this guide we will see how you can:
-
-1. Deploy a Helm application with Codefresh in an automated manner
-1. Manage your Helm releases from within Codefresh
-1. Store a Helm package inside the integrated Codefresh repository
-
-
-
-For simplicity reasons, we will use the [default Docker registry]({{site.baseurl}}/docs/docker-registries/external-docker-registries/#the-default-registry) that is setup globally in your Codefresh account. For your own application you can also use any other of your registries even if it is not the default.
-
-
-## Prerequisites
-
-It is assumed that:
- - You have already [added your Kubernetes cluster]({{site.baseurl}}/docs/deploy-to-kubernetes/adding-non-gke-kubernetes-cluster/) into Codefresh
- - You have connected at least one [Docker registry]({{site.baseurl}}/docs/docker-registries/external-docker-registries/) in your Codefresh account
- - You have already an application that has a Dockerfile and a [Helm chart]({{site.baseurl}}/docs/new-helm/using-helm-in-codefresh-pipeline/#helm-setup)
- - Your cluster has pull access to your default Docker registry. If not read the [previous guide]({{site.baseurl}}/docs/getting-started/deployment-to-kubernetes-quick-start-guide/#deploying-a-docker-image-to-kubernetes-manually) or look at the [documentation]({{site.baseurl}}/docs/deploy-to-kubernetes/deploy-to-kubernetes/create-image-pull-secret/)
-
-If you want to follow along feel free to fork this [repository](https://github.com/codefresh-contrib/python-flask-sample-app) in your Git account and look at the [with-helm](https://github.com/codefresh-contrib/python-flask-sample-app/tree/with-helm) branch.
-
-First, verify that your cluster is setup for Helm by selecting the *Helm Releases* item from the left sidebar. You should see the Helm releases in your cluster or an empty screen if you just started.
-
- {% include
-image.html
-lightbox="true"
-file="/images/getting-started/quick-start-helm/empty-helm-cluster.png"
-url="/images/getting-started/quick-start-helm/empty-helm-cluster.png"
-alt="Empty Helm cluster"
-caption="Empty Helm cluster (click image to enlarge)"
-max-width="70%"
-%}
-
-
-## Deploying a Helm Release to your Kubernetes cluster
-
-Codefresh provides a special [Helm step](https://codefresh.io/steps/step/helm) that you can use to perform a deployment.
-At its most basic form you can put the following step in your [codefresh.yml]({{site.baseurl}}/docs/codefresh-yaml/what-is-the-codefresh-yaml/) file.
-
-`YAML`
-{% highlight yaml %}
-{% raw %}
-deploy:
- type: helm
- arguments:
- action: install
- chart_name: test_chart
- release_name: first
- helm_version: 3.0.1
- kube_context: my-kubernetes-context
-{% endraw %}
-{% endhighlight %}
-
-Under the hood, we use the `cfstep-helm` image to deploy a chart. There are 3 environment variables that are required. The `chart_name` points to the [chart inside the git repository](https://github.com/codefresh-contrib/python-flask-sample-app/tree/with-helm/charts/python). The `release_name` defines the name of the deployment that will be created
-in the cluster. And finally, the `kube_context` defines which cluster will be used. The name is the same as defined in [Codefresh Integrations](https://g.codefresh.io/account-admin/account-conf/integration/kubernetes).
-
-For the full list of variables and modes see the section [using Helm in Codefresh pipelines]({{site.baseurl}}/docs/new-helm/using-helm-in-codefresh-pipeline/)
-
->Notice that we use Helm 3.x in the example above. If you still use Helm 2.x then select another tag of the `codefresh/cfstep-helm` image that matches your Tiller version. For example if you have installed Tiller 2.9.1 then you need to use the 2.9.1 version instead.
-
-This step will deploy the Helm chart using the default values as found in `values.yaml` inside the chart folder. It would make sense to override the defaults using some parameters in the build. For example instead of tagging your docker image with the branch name (which is always the same for each build), you could tag it with the hash of the source revision which is one of the [offered variables]({{site.baseurl}}/docs/codefresh-yaml/variables/).
-
-Thus, the whole pipeline is the following:
-
-`YAML`
-{% highlight yaml %}
-{% raw %}
-version: '1.0'
-stages:
- - checkout
- - package
- - deploy
-steps:
- clone:
- title: Cloning main repository...
- type: git-clone
- arguments:
- repo: '${{CF_REPO_OWNER}}/${{CF_REPO_NAME}}'
- revision: '${{CF_REVISION}}'
- stage: checkout
- BuildingDockerImage:
- title: Building Docker Image
- type: build
- arguments:
- image_name: my-flask-app
- working_directory: ./python-flask-sample-app
- tag: '${{CF_BRANCH_TAG_NORMALIZED}}-${{CF_SHORT_REVISION}}'
- dockerfile: Dockerfile
- stage: package
- 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'
- - 'repository=r.cfcr.io/kostis-codefresh/my-flask-app'
- - 'image_tag=${{CF_BRANCH_TAG_NORMALIZED}}-${{CF_SHORT_REVISION}}'
- - 'image_pullSecret=codefresh-generated-r.cfcr.io-cfcr-default'
-{% endraw %}
-{% endhighlight %}
-
-The `custom_values` override the [default chart values](https://github.com/codefresh-contrib/python-flask-sample-app/blob/with-helm/charts/python/values.yaml). The underscores are replaced with dots.
-Here we override the name of tag (to match the Docker image built in the previous step) and the pull policy.
-
-You can see the value replacements in the Helm logs inside the pipeline:
-
- {% include
-image.html
-lightbox="true"
-file="/images/getting-started/quick-start-helm/helm-logs.png"
-url="/images/getting-started/quick-start-helm/helm-logs.png"
-alt="Helm Value replacement"
-caption="Helm Value replacement"
-max-width="100%"
-%}
-
-
-This is the easiest way to deploy to Kubernetes without having to manually change values in manifests, Helm and Codefresh
-already take care of replacements using the built-in steps.
-
-### Viewing Helm releases
-
-Once a Helm package is deployed in your Kubernetes cluster, Codefresh will show it under [Helm releases]({{site.baseurl}}/docs/new-helm/helm-releases-management/).
-
- {% include
-image.html
-lightbox="true"
-file="/images/getting-started/quick-start-helm/helm-release-details.png"
-url="/images/getting-started/quick-start-helm/helm-release-details.png"
-alt="Codefresh Helm release"
-caption="A Helm release (click image to enlarge)"
-max-width="90%"
-%}
-
-If you don't see your release click on the gear icon on the top right of the cluster and make sure that you choose the correct Helm version along with the namespace of your application.
-
- {% include
-image.html
-lightbox="true"
-file="/images/getting-started/quick-start-helm/helm-version-selection.png"
-url="/images/getting-started/quick-start-helm/helm-version-selection.png"
-alt="Choosing a Helm version"
-caption="Choosing a Helm version (click image to enlarge)"
-max-width="50%"
-%}
-
-You can click on the release and get information regarding its chart, its revisions, changed files and the resulting manifests.
-
-The build values that we defined in the `codefresh.yml` are shown here in a separate tab so it is very easy to
-verify the correct parameters.
-
- {% include
-image.html
-lightbox="true"
-file="/images/getting-started/quick-start-helm/helm-values.png"
-url="/images/getting-started/quick-start-helm/helm-values.png"
-alt="Codefresh Helm values"
-caption="Helm values (click image to enlarge)"
-max-width="70%"
-%}
-
-You also visit the main Kubernetes dashboard and view the services/pods/deployments that comprise the helm release.
-
-
-### Rolling back a Helm release
-
-Another big advantage of Helm is the way it gives you easy rollbacks for free. If you make some commits in your project Helm will keep the same deployment and add new revisions on it.
-
-You can easily rollback to any previous version without actually re-running the pipeline.
-
- {% include
-image.html
-lightbox="true"
-file="/images/getting-started/quick-start-helm/helm-rollback.png"
-url="/images/getting-started/quick-start-helm/helm-rollback.png"
-alt="Helm rollback"
-caption="Helm rollback (click image to enlarge)"
-max-width="70%"
-%}
-
-The server part of Helm keeps a history of all releases and knows the exact contents of each respective Helm package.
-
-Codefresh allows you to do this right from the GUI. Select the History tab in the Helm release and from the list of revisions you can select any of them as the rollback target. Notice that rolling back will actually create a new revision. So, you can go backward and forward in time to any revision possible.
-
-
-
-
-## Storing a Helm chart
-
-Codefresh includes a [built-in Helm repository]({{site.baseurl}}/docs/new-helm/managed-helm-repository/) that comes integrated to all accounts. You can use this repository
-to store charts like any other public Helm repository. It is also possible to manually deploy applications from your repository.
-
-To store a Helm chart, first of all you need to import the shared configuration that defines the integrated Helm Repository, or, you can define the repository URL directly.
-
-Within the pipeline editor click the *Variables* taskbar on the right and click on the vertical ellipsis, select *Add Shared Configuration*. Then, select the shared configuration of the integrated Helm repository and add the variable to your pipeline.
-
- {% include
-image.html
-lightbox="true"
-file="/images/getting-started/quick-start-helm/import-helm-repo-conf.png"
-url="/images/getting-started/quick-start-helm/import-helm-repo-conf.png"
-alt="Helm settings"
-caption="Import Helm repository configuration (click image to enlarge)"
-max-width="70%"
-%}
-
-Once that is done you add or modify the deploy step in your `codefresh.yml` file:
-
-`YAML`
-{% highlight yaml %}
-{% raw %}
-version: '1.0'
-stages:
- - checkout
- - package
- - deploy
-steps:
- clone:
- title: Cloning main repository...
- type: git-clone
- arguments:
- repo: '${{CF_REPO_OWNER}}/${{CF_REPO_NAME}}'
- revision: '${{CF_REVISION}}'
- stage: checkout
- BuildingDockerImage:
- title: Building Docker Image
- type: build
- working_directory: ${{clone}}
- arguments:
- image_name: my-flask-app
- tag: '${{CF_BRANCH_TAG_NORMALIZED}}-${{CF_SHORT_REVISION}}'
- dockerfile: Dockerfile
- stage: package
- deploy:
- title: Storing Helm chart
- type: helm
- stage: deploy
- working_directory: ./python-flask-sample-app
- arguments:
- action: push
- chart_name: charts/python
- helm_version: 3.0.2
- kube_context: 'mydemoAkscluster@BizSpark Plus'
-{% endraw %}
-{% endhighlight %}
-
-We use the same `helm` step as before. But this time we define `push` as the action (the default is deploying a helm package). In this pipeline we only store the Helm chart in the internal repository.
-
- {% include
-image.html
-lightbox="true"
-file="/images/getting-started/quick-start-helm/helm-only-store.png"
-url="/images/getting-started/quick-start-helm/helm-only-store.png"
-alt="Storing the chart"
-caption="Storing the chart"
-max-width="100%"
-%}
-
-Once the pipeline finishes, you can see your chart in the *Helm charts* part in the left sidebar.
-
- {% include
-image.html
-lightbox="true"
-file="/images/getting-started/quick-start-helm/helm-repo.png"
-url="/images/getting-started/quick-start-helm/helm-repo.png"
-alt="Helm settings"
-caption="Import Helm repository configuration (click image to enlarge)"
-max-width="70%"
-%}
-
-There is even an install button if you want to deploy manually the chart. Codefresh will allow to enter your own values
-in that case and also select your target cluster.
-
-You can also create a single pipeline that [both stores the chart as well as deploys it in a cluster]({{site.baseurl}}/docs/yaml-examples/examples/helm/). You can learn more about [Helm best practices and Helm pipelines]({{site.baseurl}}/docs/docs/new-helm/helm-best-practices/#helm-concepts) to determine which solution is best.
-
-## What to read next
-
-* [Codefresh built-in Helm repository]({{site.baseurl}}/docs/new-helm/managed-helm-repository/)
-* [Using Helm in a Pipeline]({{site.baseurl}}/docs/new-helm/using-helm-in-codefresh-pipeline/)
-* [Helm pipeline example]({{site.baseurl}}/docs/yaml-examples/examples/helm/)
-* [Working with Docker registries]({{site.baseurl}}/docs/docker-registries/working-with-docker-registries/)
-* [Codefresh YAML]({{site.baseurl}}/docs/codefresh-yaml/what-is-the-codefresh-yaml/)
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/_docs/getting-started/intro-to-codefresh.md b/_docs/getting-started/intro-to-codefresh.md
new file mode 100644
index 000000000..dafaa5a51
--- /dev/null
+++ b/_docs/getting-started/intro-to-codefresh.md
@@ -0,0 +1,156 @@
+---
+title: "What is Codefresh?"
+description: "Understand the features and benefits of Codefresh"
+group: getting-started
+toc: true
+---
+
+Codefresh is a complete software lifecycle solution with modules for CI, CD and GitOps.
+
+## Codefresh & CI/CD
+
+Codefresh is a cloud-native continuous integration and delivery platform that enables teams to quickly and efficiently develop, deploy, and manage cloud-native applications.
+
+Teams can quickly and easily build, test, and deploy their applications on any cloud platform, including Kubernetes, Docker, and AWS. Our intuitive, easy-to-use UI helps streamline the development process.
+
+Codefresh is a _complete CI/CD solution_, not just CI, covering the full software lifecycle.
+
+View a release in the Kubernetes dashboard, click on the release to go to the Docker image, click on the Docker image to go to the build that created it, all from a single interface!
+
+
+Codefresh works with all major Git platforms and cloud providers. There is no lock-in with any particular vendor. Unlike other CI/CD platforms which can be tightly coupled to a single Git provider, or a specific vendor or set of tools, Codefresh is agnostic to both Git providers and target platforms.
+
+Codefresh has a strong focus on containers/Kubernetes but can also be used for traditional applications that run on Virtual machines or physical datacenters.
+
+
+### CI/CD pipelines
+
+Everything in Codefresh CI/CD starts and ends with pipelines.
+
+A Codefresh pipeline has two distinct aspects, the specification that defines the pipeline, and steps that are essentially a collection of Docker images that define the jobs and CI and CD processes to implement.
+
+To see how pipelines work, start with [Introduction to Codefresh pipelines]({{site.baseurl}}/docs/pipelines/introduction-to-codefresh-pipelines/), or jump to [pipeline creation]({{site.baseurl}}/docs/pipelines/pipelines/).
+
+For ready-to-use collections of pipeline steps, check out our [built-in steps]({{site.baseurl}}/docs/pipelines/steps/), or jump to [pipeline creation]({{site.baseurl}}/docs/configure-ci-cd-pipeline/pipelines/) and our [Plugin marketplace](https://codefresh.io/steps/){:target="\_blank"}.
+
+### Integrations
+
+For a seamless CI/CD experience, Codefresh has native integrations with almost every major Git or Cloud provider.
+Easily connect Git providers, registry providers, storage providers, secret stores, and notification channels.
+
+Docker registries and all cluster integrations are automatically available to all pipelines, without Docker login commands or `kubectl` commands to set up a Kube context inside your pipeline.
+
+
+### Dashboards and insights
+
+Dashboards are key to providing the right information at the right time.
+
+Codefresh has dedicated dashboards for Helm and Kubernetes, and a different dashboard that combines Helm and Kubernetes information in the same location.
+
+* Helm Boards
+ A special environment dashboard to track your applications as they move within your infrastructure (e.g., Dev, QA, Prod), and shift Helm releases between environments.
+ See [Promoting Helm environments]({{site.baseurl}}/docs/deployments/helm/helm-environment-promotion/).
+*
+Helm Releases
+ Here's where you can see everything about the cluster, including current status, currently deployed releases, their previous revisions including change tracking, and even rollbacks.
+ See [Managing Helm releases]({{site.baseurl}}/docs/deployments/helm/helm-releases-management/).
+
+* Kubernetes Services
+ Track the state of your Kubernetes clusters, and even manage services if you have the appropriate access privileges.
+ See [Managing Kubernetes clusters]({{site.baseurl}}/docs/deployments/kubernetes/manage-kubernetes/).
+
+* Environment Dashboard
+ For both Kubernetes and Helm releases, see cluster status and pipeline information.
+ See [Environment dashboard]({{site.baseurl}}/docs/deployments/kubernetes/environment-dashboard/).
+
+
+### Where to go from here
+Here are several useful links to further explore CI/CD with Codefresh:
+
+**Quick starts**
+To get up and running, follow our quick starts. The quick start modules are a series of flows that guide you from setting up your first account in Codefresh, to creating a basic pipeline, and deploying to Kubernetes.
+See [CI/CD quick start]({{site.baseurl}}/docs/quick-start/ci-quick-start/).
+
+**Example catalog**
+If you are familiar with CI/CD, we have an extensive collection of examples that cover several CI and CD scenarios:
+[CI examples]({{site.baseurl}}/docs/example-catalog/ci-examples/)
+[CD examples]({{site.baseurl}}/docs/example-catalog/cd-examples/)
+
+**Guides**
+And finally, you can dive in to our detailed guides. Look for CI/CI guides in the documentation such as [Packaging/Compilations]({{site.baseurl}}/docs/ci-cd-guides/packaging-compilation/) and [Building Docker images]({{site.baseurl}}/docs/ci-cd-guides/building-docker-images/)
+
+
+## Codefresh & GitOps with Argo CD
+
+GitOps provides a way to manage cloud-native applications using Git as the source of truth. Teams can define the desired state of their applications and Kubernetes clusters in a Git repository and then automatically deploy the applications to Kubernetes clusters.
+
+Codefresh is a full-featured, turn-key solution for application deployments and releases powered by Argo CD. By combining GitOps with Codefresh, teams can create Argo Workflows and Argo Applications to seamlessly build, test, and deploy their applications.
+
+
+**GitOps Runtimes**
+You can use [your own GitOps Runtime]({{site.baseurl}}/docs/installation/gitops/hybrid-gitops/) or get started quick with a [runtime hosted by Codefresh]({{site.baseurl}}/docs/installation/gitops/hosted-runtime/).
+
+Codefresh offers security, maintainability, traceability, and most importantly, a single control plane for all stakeholders, be they developers, operators, product owners or project managers.
+
+### Codefresh & 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 unified all 4 projects of the Argo family into a single *Runtime*, providing an enterprise-supported version of all projects enhanced with unique functionality.
+
+>Our users rely on the Codefresh platform to deliver software, reliably and predictably, without disruptions.
+To maintain that high standard, we add several weeks of testing and bug fixes to new versions of Argo before making them available within Codefresh. Typically, new versions of Argo are available in the Codefresh Runtime within 30 days of their release.
+
+### Argo CD applications and deployments
+
+Codefresh supports the complete lifecycle for creating and deploying Argo CD applications.
+
+You can create full-featured Argo CD applications in Form or YAML modes in the Codefresh UI. Every action you take in the Codefresh GUI results in a Git commit behind the scenes. The application manifest is generated, committed to Git, and synced to your cluster. See [Creating]({{site.baseurl}}/docs/deployments/gitops/create-application/) and [Managing]({{site.baseurl}}/docs/deployments/gitops/manage-application/) GitOps applications.
+
+Track the deployed applications in the GitOps Apps dashboard. See [Monitoring GitOps applications]({{site.baseurl}}/docs/deployments/gitops/applications-dashboard/).
+
+### GitOps image enrichment
+
+Image enrichment adds to the quality of deployments by exposing metadata such as feature requests, pull requests, and logs as part of the application’s deployment, for visibility into all aspects of the deployment, making it easier to track actions and identify root cause of failures.
+
+You can use your own third-party CI platforms and tools, such as Jenkins, GitHub Actions, or Codefresh pipelines to enrich and report images to the Codefresh platform with no disruptions to existing CI processes and flows.
+
+Add integration accounts in Codefresh to tools such as Jira, Docker Hub, Quay and, and then connect your CI tool with Codefresh for image enrichment and reporting.
+
+We offer a pipeline step that both reports the image to GitOps and enriches it.
+See [GitOps image enrichment with integrations]({{site.baseurl}}/docs/gitops-integrations/image-enrichment-overview/).
+
+### Dashboards for GitOps insights
+
+Dashboards are key to providing the right information at the right time. Similar to our CI/CD dashboards, we have dedicated dashboards optimized for GitOps, for all stakeholders, developers, product owners, and management.
+
+**Operational GitOps dashboard**
+
+The GitOps Overview dashboard displays the most commonly needed application and environmental information to developers so that they can troubleshoot without needing assistance from the DevOps teams, even in production.
+See [GitOps Overview dashboard]({{site.baseurl}}/docs/dashboards/home-dashboard/).
+
+
+**DORA metrics**
+
+Developers often need to reach out to DevOps to get statistics and metrics around builds and deployments. Codefresh automatically generates DORA metrics as well as many other key indicators of build and deployment efficiency. These analytics are presented to be easily understood by product owners and management alike.
+
+See [DORA metrics]({{site.baseurl}}/docs/dashboards/dora-metrics/).
+
+**Applications dashboard**
+The GitOps Apps dashboard displays a unified view of applications across runtimes and clusters. No matter what the volume and frequency of your deployments, the GitOps 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.
+
+Drill down into an application to view resources, timelines, services and more.
+See [Monitoring GitOps applications]({{site.baseurl}}/docs/deployments/gitops/applications-dashboard/).
+
+
+### Where to go from here
+
+To get up and running, follow our quick starts. The quick start modules are a series of flows that guide you from setting up your first account in Codefresh, to creating and deploying an application.
+
+See [GitOps quick start]({{site.baseurl}}/docs/quick-start/gitops-quick-start/).
+
+
diff --git a/_docs/getting-started/on-demand-environments.md b/_docs/getting-started/on-demand-environments.md
deleted file mode 100644
index 4c594d244..000000000
--- a/_docs/getting-started/on-demand-environments.md
+++ /dev/null
@@ -1,114 +0,0 @@
----
-title: "On-demand environments"
-description: "Code collaboration with Codefresh"
-group: getting-started
-toc: true
-
----
-
-In this tutorial we will see how Codefresh can be used by many developers who work on multiple features and how to create separate demo environments for each feature.
-
-Codefresh has the unique capability of launching Docker images in temporary test environments. These test environments
-are ephemeral and are not intended to be used as QA (let alone production) environments. They are perfect
-for quick demos. Use them
-if you want to quickly share a feature with a colleague or a customer.
-
-## Launching a Docker image using Codefresh
-
-Docker images play a central role in Codefresh. The [basic CI tutorial]({{site.baseurl}}/docs/getting-started/create-a-basic-pipeline/) describes how you can easily create a Docker image from your source code.
-
-In this section we will take this one step further and actually launch the result Docker image.
-Codefresh has the unique capability of launching a docker image (using [Docker Swarm](https://docs.docker.com/engine/swarm/) behind the scenes) on the same hosted environment that Codefresh itself runs.
-
-{% include
-image.html
-lightbox="true"
-file="/images/getting-started/quick-start-test-pr/demo-stage.jpg"
-url="/images/getting-started/quick-start-test-pr/demo-stage.jpg"
-max-width="80%"
-%}
-
-This means that with zero effort from your side you can quickly inspect the status of your application using the Codefresh infrastructure.
-
-
-
-
-
-
-To start a Docker image as a demo environment, locate it in the *Images* section and click the *launch* button.
-
-{% include
-image.html
-lightbox="true"
-file="/images/getting-started/quick-start-test-pr/launch.png"
-url="/images/getting-started/quick-start-test-pr/launch.png"
-alt="Launching a Docker image"
-caption="Launching a Docker image (click image to enlarge)"
-max-width="80%"
-%}
-
-
-Our sample application is self-contained (it consists of only a single Docker image) so choose *standalone* for the popup menu. Codefresh can also launch demo environments for applications that consist of multiple images (e.g. a service image and a database image). This capability happens with Codefresh *compositions* which are described in detail in section [On-Demand Environments]({{site.baseurl}}/docs/on-demand-test-environment/create-composition/).
-
-Codefresh automatically knows which port should be exposed in the test environment
-(i.e. which port of the Docker container should be made available for external connections). The sample application we are using here is exposing its web interface at port 5000 (but a random port will actually be assigned for external connections).
-
-Once your application is launched, Codefresh will present the run log. You will see the same messages that would appear if you executed the `docker run` command locally.
-
-{% include
-image.html
-lightbox="true"
-file="/images/getting-started/quick-start-test-pr/launch-url.png"
-url="/images/getting-started/quick-start-test-pr/launch-url.png"
-alt="Start logs"
-caption="Start logs (click image to enlarge)"
-max-width="60%"
-%}
-
-## Accessing the test environment
-
-Once launch is complete, Codefresh will print a dynamic URL that contains the deployed environment. Now you have a demo environment created just for you! You can send this link with an email to a colleague to ask for feedback or to a customer to show progress.
-
-
-
-{% include
-image.html
-lightbox="true"
-file="/images/getting-started/quick-start-test-pr/demo-environment.png"
-url="/images/getting-started/quick-start-test-pr/demo-environment.png"
-alt="Demo environment"
-caption="Demo environment (click image to enlarge)"
-max-width="60%"
-%}
-
-
-The number of concurrent test environments that you can have depends on your Codefresh account. Remember that you should never treat
-these on demand environments as production ones. They were never designed that way.
-
-If the environment is not functioning correctly for your own application, make sure that the port exposed by Codefresh in the *Launch settings* is the one that is actually used in your application as an HTTP endpoint.
-
-To find your existing on-demand environments, click *Compositions* `->` *Running Compositions* on the left part of the screen. You will get a list of your active environments. You can see details such as:
-
-* Which branch is this environment from
-* Which Git commit represents this environment
-* What is the URL endpoint created by Codefresh
-
-{% include
-image.html
-lightbox="true"
-file="/images/getting-started/quick-start-test-pr/env-details.png"
-url="/images/getting-started/quick-start-test-pr/env-details.png"
-alt="Details for an environment"
-caption="Details for an environment (click image to enlarge)"
-max-width="70%"
-%}
-
-On the right side, you can find a list of buttons that allow you to visit the environment directly, share the link on Slack and most importantly stop the environment, so that it doesn't count against your account. It is a good practice to launch environments only when you need them and clean them up once you are done with them.
-
-## What to read next
-
-* [Deploy to Kubernetes]({{site.baseurl}}/docs/getting-started/deployment-to-kubernetes-quick-start-guide/)
-* [Introduction to Pipelines]({{site.baseurl}}/docs/configure-ci-cd-pipeline/introduction-to-codefresh-pipelines/)
-
-
-
diff --git a/_docs/gitops-integrations/ci-integrations.md b/_docs/gitops-integrations/ci-integrations.md
new file mode 100644
index 000000000..fe1d79861
--- /dev/null
+++ b/_docs/gitops-integrations/ci-integrations.md
@@ -0,0 +1,108 @@
+---
+title: "GitOps CI integrations"
+description: ""
+group: gitops-integrations
+toc: true
+---
+
+Use Codefresh 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 GitOps integrations]({{site.baseurl}}/docs/gitops-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-gitops).
+
+
+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 pipeline 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/deployments/gitops/images/), and in any [application]({{site.baseurl}}/docs/deployments/gitops/applications-dashboard/) in which it is used.
+
+## Connect a third-party CI platform/tool to GitOps
+Connecting the CI platform/tool to GitOps 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, on the toolbar, click the **Settings** icon, and then from the sidebar, select [**GitOps 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 pipelines]({{site.baseurl}}/docs/gitops-integrations/ci-integrations/codefresh-classic/)
+ [GitHub Actions]({{site.baseurl}}/docs/gitops-integrations/ci-integrations/github-actions/)
+ [Jenkins]({{site.baseurl}}/docs/gitops-integrations/ci-integrations/jenkins/)
+
+ >For the complete list of arguments you can use, see [CI integration for GitOps argument reference](#ci-integration-argument-reference) in this article.
+
+{:start="4"}
+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 pipeline with validation errors"
+caption="Example of manifest generated for Codefresh pipeline 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/integrations/classic/classic-manifest.png"
+alt="Example of manifest generated for Codefresh pipeline"
+caption="Example of manifest generated for Codefresh pipeline"
+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/gitops-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/gitops-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 Codefresh pipelines and Jenkins.
{:/} | Required |
+| `CF_GIT_PROVIDER` | The Git provider for the integration, and can be either `github`, `gitlab`, or `bitbucket`. {::nomarkdown}
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 |
+| `CF_GITLAB_TOKEN` | The token to authenticate the GitLab account. {::nomarkdown}
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 |
+| `CF_GITLAB_HOST_URL` | The URL address of your GitLab Cloud/Server instance. {::nomarkdown}
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 |
+| `CF_BITBUCKET_USERNAME` | The username for the Bitbucket or the Bitbucket Server (on-prem) account. {::nomarkdown}
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 |
+| `CF_BITBUCKET_PASSWORD` | The password for the Bitbucket or the BitBucket Server (on-prem) account. {::nomarkdown}
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 |
+| `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 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 |
+|`CF_JIRA_PROJECT_PREFIX` | Relevant only when `CF_ISSUE_TRACKING_INTEGRATION` is defined. The Jira project prefix that identifies the ticket number to use.| Required|
+| `CF_JIRA_MESSAGE` | Relevant only when `CF_ISSUE_TRACKING_INTEGRATION` is defined. The Jira issue IDs matching the string to associate with the image. | Required |
+| `CF_JIRA_FAIL_ON_NOT_FOUND` | Relevant only when `CF_ISSUE_TRACKING_INTEGRATION` is defined. The report image action when the `CF_JIRA_MESSAGE` is not found. When set to `true`, the report image action is failed. | Required |
+
+## Related articles
+[Container registry GitOps integrations]({{site.baseurl}}/docs/gitops-integrations/container-registries/)
+[Issue tracking GitOps intergrations]({{site.baseurl}}/docs/gitops-integrations/issue-tracking/)
+
+
+
+
+
+
diff --git a/_docs/gitops-integrations/ci-integrations/codefresh-classic.md b/_docs/gitops-integrations/ci-integrations/codefresh-classic.md
new file mode 100644
index 000000000..72f4d224c
--- /dev/null
+++ b/_docs/gitops-integrations/ci-integrations/codefresh-classic.md
@@ -0,0 +1,259 @@
+---
+title: "GitOps Codefresh pipeline integration"
+description: ""
+group: gitops-integrations
+sub_group: ci-integrations
+toc: true
+---
+
+
+ Use Hosted GitOps with any popular Continuous Integration (CI) solution, not just with Codefresh CI. If you have Hosted or Hybrid GitOps, you can connect your CI pipelines to Hosted GitOps for deployment with image enrichment and reporting.
+
+
+ Connecting your CI 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 Codefresh pipeline and how to configure the integration, see [CI Integrations]({{site.baseurl}}/docs/gitops-integrations/ci-integrations/).
+
+
+## Example of Codefresh pipeline with report image step
+
+{% highlight yaml %}
+{% raw %}
+
+version: "1.0"
+stages:
+ - "clone"
+ - "build"
+ - "report"
+
+steps:
+ clone:
+ title: "Cloning repository"
+ type: "git-clone"
+ repo: "${{CF_REPO_OWNER}}/${{CF_REPO_NAME}}"
+ revision: "${{CF_BRANCH}}"
+ stage: "clone"
+
+ build:
+ title: "Building Docker image"
+ type: "build"
+ image_name: "${{CF_REPO_OWNER}}/color"
+ working_directory: "${{clone}}"
+ tag: "${{CF_SHORT_REVISION}}"
+ dockerfile: "Dockerfile"
+ registry: docker-lr
+ stage: "build"
+
+ ReportImageMetadataAll:
+ title: Report image to Codefresh CD
+ type: codefresh-report-image
+ working_directory: /code
+ stage: "report"
+ arguments:
+ CF_API_KEY: '${{CF_API_KEY}}'
+ CF_IMAGE: 'docker.io/${{CF_REPO_OWNER}}/color:${{CF_SHORT_REVISION}}'
+ CF_CONTAINER_REGISTRY_INTEGRATION: docker
+ CF_RUNTIME_NAME: "codefresh-hosted"
+ CF_GITHUB_TOKEN: '${{GITHUB_TOKEN}}'
+ CF_GIT_PROVIDER: github
+ CF_GIT_REPO: '${{CF_REPO_OWNER}}/${{CF_REPO_NAME}}'
+ CF_GIT_BRANCH: '${{CF_BRANCH}}'
+ CF_ISSUE_TRACKING_INTEGRATION: jira
+ CF_JIRA_MESSAGE: "${{CF_COMMIT_MESSAGE}}"
+ CF_JIRA_PROJECT_PREFIX: CR
+
+{% endraw %}
+{% endhighlight yaml %}
+
+## Codefresh pipeline-GitOps integration settings
+The table describes the arguments required to connect Codefresh pipelines to Codefresh GitOps.
+
+>Except for Git branch and Git repo which are required, you can omit other Git provider arguments. Codefresh retrieves the required values from the runtime context selected for the integration.
+
+For the complete argument reference, see [CI integration for GitOps argument reference]({{site.baseurl}}/docs/gitops-integrations/ci-integrations/#ci-integration-argument-reference).
+
+
+{: .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 pipeline 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/gitops-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/gitops-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. | Required |
+| `CF_GIT_PROVIDER` | The Git provider for the integration, and can be either `github`, `gitlab`, or `bitbucket`. {::nomarkdown}
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 |
+| `CF_GITLAB_TOKEN` | The token to authenticate the GitLab account. {::nomarkdown}
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 |
+| `CF_GITLAB_HOST_URL` | The URL address of your GitLab Cloud/Server instance. {::nomarkdown}
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 |
+| `CF_BITBUCKET_USERNAME` | The username for the Bitbucket or the Bitbucket Server (on-prem) account. {::nomarkdown}
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 |
+| `CF_BITBUCKET_PASSWORD` | The password for the Bitbucket or the Bitbucket Server (on-prem) account. {::nomarkdown}
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 |
+| `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 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 |
+|`CF_JIRA_PROJECT_PREFIX` | Relevant only when `CF_ISSUE_TRACKING_INTEGRATION` is defined. The Jira project prefix that identifies the ticket number to use.| Required|
+| `CF_JIRA_MESSAGE` | Relevant only when `CF_ISSUE_TRACKING_INTEGRATION` is defined. The Jira issue IDs matching the string to associate with the image. | Required |
+| `CF_JIRA_FAIL_ON_NOT_FOUND` | Relevant only when `CF_ISSUE_TRACKING_INTEGRATION` is defined. The report image action when the `CF_JIRA_MESSAGE` is not found. When set to `true`, the report image action is failed. | Required |
+
+For how-to instructions, see [Connect a third-party CI platform/tool to Codefresh GitOps]({{site.baseurl}}/docs/gitops-integrations/ci-integrations/#connect-a-third-party-ci-platformtool-to-codefresh/).
+
+## Templatization examples for CF arguments
+
+Arguments such as `CF_IMAGE`, `CF_GIT_BRANCH`, and `CF_JIRA_MESSAGE` are populated dynamically when the Codefresh integration pipeline is triggered. You can templatize the values of these arguments to ensure that the required information is included in the reported image.
+
+Codefresh pipelines have [system variables]({{site.baseurl}}/docs/pipelines/variables/#system-provided-variables) you can use to templatize argument values.
+
+{::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 pipeline integration logs
+View and analyze logs for Codefresh pipelines through the Logs tab. When a Codefresh 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 for the pipeline, 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 pipelines: Logs tab"
+caption="Codefresh pipelines: Logs tab"
+max-width="50%"
+%}
+
+**Build in Codefresh**
+
+The Run column includes the link to the pipeline in Codefresh.
+
+Here is an example of the pipeline build in Codefresh with the Enrich image for GitOps 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 pipeline with Codefresh GitOps enrich image step"
+caption="Codefresh pipeline with Codefresh GitOps 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 pipeline build"
+caption="Logs for Codefresh report image step in Codefresh pipeline build"
+max-width="50%"
+%}
+
+## Related articles
+[Shared configuration repo]({{site.baseurl}}/docs/reference/shared-configuration/)
+[Image enrichment with GitOps integrations]({{site.baseurl}}/docs/gitops-integrations/image-enrichment-overview/)
+[Container registry GitOps integrations]({{site.baseurl}}/docs/gitops-integrations/container-registries/)
+[Issue-tracking GitOps integrations]({{site.baseurl}}/docs/gitops-integrations/issue-tracking/)
\ No newline at end of file
diff --git a/_docs/gitops-integrations/ci-integrations/github-actions.md b/_docs/gitops-integrations/ci-integrations/github-actions.md
new file mode 100644
index 000000000..c24dfe538
--- /dev/null
+++ b/_docs/gitops-integrations/ci-integrations/github-actions.md
@@ -0,0 +1,259 @@
+---
+title: "GitOps GitHub Actions integration"
+description: ""
+group: gitops-integrations
+sub_group: ci-integrations
+toc: true
+---
+
+Use 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 Hosted GitOps 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/gitops-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-GitOps integration settings
+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}
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 |
+| `CF_GIT_REPO` | The Git repository with the configuration and code used to build the image. If not defined, Codefresh retrieves it from the repo defined for the GitHub Action. | Required |
+| `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/gitops-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_GITHUB_TOKEN` | The GitHub authentication token. See [Git tokens]({{site.baseurl}}/docs/reference/git-tokens/#git-personal-tokens). | Required |
+|`CF_JIRA_PROJECT_PREFIX` | Relevant only when `CF_ISSUE_TRACKING_INTEGRATION` is defined. The Jira project prefix that identifies the ticket number to use.| Required|
+| `CF_JIRA_MESSAGE` | Relevant only when `CF_ISSUE_TRACKING_INTEGRATION` is defined. The Jira issue IDs matching the string to associate with the image. | Required |
+| `CF_JIRA_FAIL_ON_NOT_FOUND` | Relevant only when `CF_ISSUE_TRACKING_INTEGRATION` is defined. The report image action when the `CF_JIRA_MESSAGE` is not found. When set to `true`, the report image action is failed. | Required |
+
+
+For how-to instructions, see [Connect a third-party CI platform/tool to Codefresh]({{site.baseurl}}/docs/gitops-integrations/ci-integrations/#connect-a-third-party-ci-platformtool-to-codefresh).
+
+## Templatization examples for CF arguments
+
+Arguments such as `CF_IMAGE`, `CF_GIT_BRANCH`, and `CF_JIRA_MESSAGE` are populated dynamically when the GitHub Actions pipeline is triggered. You can templatize the values of these arguments to ensure that the required information is included in the reported image.
+
+See GitHub Actions [environment variables](https://docs.github.com/en/actions/learn-github-actions/environment-variables#default-environment-variables) you can use to templatize argument values.
+
+{::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 GitOps integrations]({{site.baseurl}}/docs/gitops-integrations/image-enrichment-overview/)
+[Container registry GitOps integrations]({{site.baseurl}}/docs/gitops-integrations/container-registries/)
+[Issue-tracking GitOps integrations]({{site.baseurl}}/docs/gitops-integrations/issue-tracking/)
+
+
diff --git a/_docs/gitops-integrations/ci-integrations/jenkins.md b/_docs/gitops-integrations/ci-integrations/jenkins.md
new file mode 100644
index 000000000..9c3214b81
--- /dev/null
+++ b/_docs/gitops-integrations/ci-integrations/jenkins.md
@@ -0,0 +1,250 @@
+---
+title: "GitOps Jenkins integration"
+description: ""
+group: gitops-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/gitops-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-GitOps integration settings
+The table describes the arguments to connect Codefresh pipelines to Codefresh GitOps.
+
+{: .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 pipeline 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/gitops-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/gitops-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 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 |
+| `CF_GITLAB_TOKEN` | The token to authenticate the GitLab account. {::nomarkdown}
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 |
+| `CF_GITLAB_HOST_URL` | The URL address of your GitLab Cloud/Server instance. {::nomarkdown}
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 |
+| `CF_BITBUCKET_USERNAME` | The username for the Bitbucket or the Bitbucket Server (on-prem) account. {::nomarkdown}
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 |
+| `CF_BITBUCKET_PASSWORD` | The password for the Bitbucket or the Bitbucket Server (on-prem) account. {::nomarkdown}
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 |
+| `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 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 |
+|`CF_JIRA_PROJECT_PREFIX` | Relevant only when `CF_ISSUE_TRACKING_INTEGRATION` is defined. The Jira project prefix that identifies the ticket number to use.| Required|
+| `CF_JIRA_MESSAGE` | Relevant only when `CF_ISSUE_TRACKING_INTEGRATION` is defined. The Jira issue IDs matching the string to associate with the image. | Required |
+| `CF_JIRA_FAIL_ON_NOT_FOUND` | Relevant only when `CF_ISSUE_TRACKING_INTEGRATION` is defined. The report image action when the `CF_JIRA_MESSAGE` is not found. When set to `true`, the report image action is failed. | Required |
+
+
+For how-to instructions, see [Connect a third-party CI platform/tool to Codefresh]({{site.baseurl}}/docs/gitops-integrations/ci-integrations/#connect-a-third-party-ci-platform-tool-to-codefresh).
+
+## Templatization examples for CF arguments
+
+Arguments such as `CF_IMAGE`, `CF_GIT_BRANCH`, and `CF_JIRA_MESSAGE` are populated dynamically when the Jenkins pipeline is triggered. You can templatize the values of these arguments in the pipeline to ensure that the required information is included in the reported image.
+
+Jenkins offers a Git plugin with [environment variables](https://plugins.jenkins.io/git/#plugin-content-environment-variables){:target="\_blank"} you can use to templatize argument values.
+
+{::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 GitOps integrations]({{site.baseurl}}/docs/gitops-integrations/image-enrichment-overview/)
+[Container registry GitOps integrations]({{site.baseurl}}/docs/gitops-integrations/container-registries/)
+[Issue-tracking GitOps integrations]({{site.baseurl}}/docs/gitops-integrations/issue-tracking/)
diff --git a/_docs/gitops-integrations/container-registries.md b/_docs/gitops-integrations/container-registries.md
new file mode 100644
index 000000000..f51b9a58c
--- /dev/null
+++ b/_docs/gitops-integrations/container-registries.md
@@ -0,0 +1,91 @@
+---
+title: "GitOps container registry integrations"
+description: ""
+group: gitops-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 pipelines by the name of the registry integration, instead of explicit credentials. See [Image enrichment with integrations]({{site.baseurl}}/docs/gitops-integrations/image-enrichment-overview/) and [CI integrations]({{site.baseurl}}/docs/gitops-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 for GitOps in Codefresh
+Configure the settings for a GitOps container registry integration in Codefresh.
+
+1. In the Codefresh UI, on the toolbar, click the **Settings** icon, and then from the sidebar, select [**GitOps 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/gitops-integrations/container-registries/amazon-ecr/)
+ [Docker Hub]({{site.baseurl}}/docs/gitops-integrations/container-registries/dockerhub/)
+ [GitHub Container Registry]({{site.baseurl}}/docs/gitops-integrations/container-registries/github-cr/)
+ [JFrog Artifactory]({{site.baseurl}}/docs/gitops-integrations/container-registries/jfrog/)
+ [Quay]({{site.baseurl}}/docs/gitops-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 for GitOps
+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 for GitOps
+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, on the toolbar, click the **Settings** icon, and then from the sidebar, select [**GitOps 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 GitOps integrations]({{site.baseurl}}/docs/gitops-integrations/ci-integrations/)
+[Issue-tracking GitOps integrations]({{site.baseurl}}/docs/gitops-integrations/issue-tracking/)
+[Shared configuration repo]({{site.baseurl}}/docs/reference/shared-configuration/)
+[Images]({{site.baseurl}}/docs/deployments/gitops/images/)
+[Monitoring applications]({{site.baseurl}}/docs/deployments/gitops/applications-dashboard/)
+
diff --git a/_docs/gitops-integrations/container-registries/amazon-ecr.md b/_docs/gitops-integrations/container-registries/amazon-ecr.md
new file mode 100644
index 000000000..a54ce8fb5
--- /dev/null
+++ b/_docs/gitops-integrations/container-registries/amazon-ecr.md
@@ -0,0 +1,62 @@
+---
+title: "GitOps Amazon ECR integration"
+description: ""
+group: gitops-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 for GitOps in Codefresh, see [Container registry GitOps integrations]({{site.baseurl}}/docs/gitops-integrations/container-registries/).
+
+>Amazon ECR integration is supported only for Hybrid GitOps.
+
+## 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-GitOps integration settings in Codefresh
+The table describes the arguments required for GitOps integrations with 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:
All runtimes: Created in resources/all-runtimes-all-clusters/
Selected runtimes: Created in resources/runtimes//
You can reference the Docker Hub integration in the CI tool. {:/}|
+| **IAM Role** | The name of the IAM role you defined with the specific permissions for authentication to the ECR. |
+| **Region** | The geographic region hosting the container registry. Define the region nearest to you.|
+| **Test connection** | Click to verify that you can connect to the specified instance before you commit changes. |
+
+
+ {% include
+ image.html
+ lightbox="true"
+ file="/images/integrations/aws/aws-int-settings.png"
+ url="/images/integrations/aws/aws-int-settings.png"
+ alt="Amazon ECR for image enrichment"
+ caption="Amazon ECR for image enrichment"
+ max-width="50%"
+ %}
+
+For how-to instructions, see [Configure container registry integrations for GitOps in Codefresh]({{site.baseurl}}/docs/gitops-integrations/container-registries/#configure-container-registry-integrations-for-gitops-in-codefresh) and [Edit/delete container registry integrations for GitOps in Codefresh]({{site.baseurl}}/docs/gitops-integrations/container-registries/#editdelete-container-registry-integrations).
+
+
+## Related articles
+[Shared configuration repo]({{site.baseurl}}/docs/reference/shared-configuration/)
+[Image enrichment with GitOps integrations]({{site.baseurl}}/docs/gitops-integrations/image-enrichment-overview/)
+[CI GitOps integrations]({{site.baseurl}}/docs/gitops-integrations/ci-integrations/)
+[Issue-tracking GitOps integrations]({{site.baseurl}}/docs/gitops-integrations/issue-tracking/)
\ No newline at end of file
diff --git a/_docs/gitops-integrations/container-registries/dockerhub.md b/_docs/gitops-integrations/container-registries/dockerhub.md
new file mode 100644
index 000000000..c6f89a3bc
--- /dev/null
+++ b/_docs/gitops-integrations/container-registries/dockerhub.md
@@ -0,0 +1,49 @@
+---
+title: "GitOps Docker Hub integration"
+description: ""
+group: gitops-integrations
+sub_group: container-registries
+toc: true
+---
+
+Codefresh has native support for interacting with Docker Hub registries, to push, pull, and deploy images.
+For information on adding a Docker Hub integration in Codefresh, see [GitOps container registry integrations]({{site.baseurl}}/docs/gitops-integrations/container-registries/).
+
+## Prerequisites
+Before you configure settings in Codefresh to integrate Docker Hub registry, do the following:
+
+* [Create an account or sign in to your account at Docker Hub](https://hub.docker.com/signup){:target="\_blank"}
+* (Optional) [Enable 2FA (Two-Factor Authentication)](https://docs.docker.com/docker-hub/2fa/){:target="\_blank"}
+* [Create a personal account token](https://docs.docker.com/docker-hub/access-tokens/){:target="\_blank"}
+
+## Docker Hub-GitOps integration settings in Codefresh
+The table describes the arguments required for Docker Hub GitOps integration 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:
All runtimes: Created in resources/all-runtimes-all-clusters/
Selected runtimes: Created in resources/runtimes//
You can reference the Docker Hub integration in the CI tool. {:/}|
+| **Username** | The Docker Hub username.|
+| **Password** | If you enabled two-factor authentication, enter the personal access token for your Docker Hub account for Codefresh to push images. Personal access tokens are more secure and can be revoked when needed. Codefresh can then push your images. If two-factor authentication is not enabled, enter the password of your Docker Hub account (not recommended).|
+| **Test connection** | Click to verify that you can connect to the specified instance before you commit changes. |
+
+
+ {% include
+ image.html
+ lightbox="true"
+ file="/images/integrations/docker-registries/docker-hub.png"
+ url="/images/integrations/docker-registries/docker-hub.png"
+ alt="Docker Hub integration for image enrichment"
+ caption="Docker Hub integration for image enrichment"
+ max-width="50%"
+ %}
+
+For how-to instructions, see [Configure container registry integrations for GitOps in Codefresh]({{site.baseurl}}/docs/gitops-integrations/container-registries/#configure-container-registry-integrations-in-codefresh) and [Edit/delete container registry integrations for GitOps in Codefresh]({{site.baseurl}}/docs/gitops-integrations/container-registries/#editdelete-container-registry-integrations).
+
+## Related articles
+[Shared configuration repo]({{site.baseurl}}/docs/reference/shared-configuration/)
+[Image enrichment with GitOps integrations]({{site.baseurl}}/docs/gitops-integrations/image-enrichment-overview/)
+[CI GitOps integrations]({{site.baseurl}}/docs/gitops-integrations/ci-integrations/)
+[Issue-tracking GitOps integrations]({{site.baseurl}}/docs/gitops-integrations/issue-tracking/)
+
diff --git a/_docs/gitops-integrations/container-registries/github-cr.md b/_docs/gitops-integrations/container-registries/github-cr.md
new file mode 100644
index 000000000..912d11478
--- /dev/null
+++ b/_docs/gitops-integrations/container-registries/github-cr.md
@@ -0,0 +1,53 @@
+---
+title: "GitOps GitHub Container Registry (GHCR) integration"
+description: ""
+group: gitops-integrations
+sub_group: container-registries
+toc: true
+---
+
+The GitHub Container registry allows you to host and manage your Docker container images in your personal or organisation account on GitHub. One of the benefits is that permissions can be defined for the Docker image independent from any repository. Thus, your repository could be private and your Docker image public.
+For information on adding a GitHub Container registry integration in Codefresh, see [Container registry GitOps integrations]({{site.baseurl}}/docs/gitops-integrations/container-registries/).
+
+## Prerequisites
+Before you configure settings in Codefresh to integrate GitHub container registry:
+* Make sure you have a personal access token with the correct scopes or create one.
+ You need at least the following scopes:
+ * `write:packages`
+ * `read:packages`
+ * `delete:packages`
+ * `repo` (if your repository is private; do not select if it is public)
+
+ For detailed information, see the [Authenticating to the Container registry](https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-container-registry#authenticating-to-the-container-registry){:target="\_blank"}.
+
+
+### GitHub Container registry (GHCR)-GitOps integration settings 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:
All runtimes: Created in resources/all-runtimes-all-clusters/
Selected runtimes: Created in resources/runtimes//
{:/}|
+| **Domain** | The GitHub registry domain and is set to `ghcr.io`.|
+| **Username** | Your GitHub username.|
+| **GitHub Token** | Your GitHub PAT (personal access token).|
+|**Test Connection** | Click to verify that you can connect to the specified instance before you commit changes. |
+
+
+ {% include
+ image.html
+ lightbox="true"
+ file="/images/integrations/githubcr/githubcr-int-settings.png"
+ url="/images/integrations/githubcr/githubcr-int-settings.png"
+ alt="GitHub Container registry integration"
+ caption="GitHub Container registry integration"
+ max-width="50%"
+ %}
+
+For how-to instructions, see [Configure container registry integrations for GitOps in Codefresh]({{site.baseurl}}/docs/gitops-integrations/container-registries/#configure-container-registry-integrations-in-codefresh) and [Edit/delete container registry integrations for GitOps in Codefresh]({{site.baseurl}}/docs/gitops-integrations/container-registries/#editdelete-container-registry-integrations).
+
+## Related articles
+[Shared configuration repo]({{site.baseurl}}/docs/reference/shared-configuration/)
+[Image enrichment with GitOps integrations]({{site.baseurl}}/docs/gitops-integrations/image-enrichment-overview/)
+[CI GitOps integrations]({{site.baseurl}}/docs/gitops-integrations/ci-integrations/)
+[Issue-tracking GitOps integrations]({{site.baseurl}}/docs/gitops-integrations/issue-tracking/)
diff --git a/_docs/gitops-integrations/container-registries/jfrog.md b/_docs/gitops-integrations/container-registries/jfrog.md
new file mode 100644
index 000000000..a35fcc936
--- /dev/null
+++ b/_docs/gitops-integrations/container-registries/jfrog.md
@@ -0,0 +1,44 @@
+---
+title: "GitOps JFrog Artifactory integration"
+description: ""
+group: gitops-integrations
+sub_group: container-registries
+toc: true
+---
+
+Codefresh has native support for interacting with JFrog Artifactory.
+For information on adding a JFrog Artifactory integration in Codefresh, see [GitOps container registry integrations]({{site.baseurl}}/docs/gitops-integrations/container-registries/).
+
+
+
+## JFrog Artifactory-GitOps integration settings 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:
All runtimes: Created in resources/all-runtimes-all-clusters/
Selected runtimes: Created in resources/runtimes//
{:/}|
+| **Server Name** | The URL of the JFrog Artifactory server instance.|
+| **Username** | The JFrog Artifactory username.|
+| **Password** | The JFrog Artifactory password.|
+|**Test Connection** | Click to verify that you can connect to the specified instance before you commit changes. |
+
+
+ {% include
+ image.html
+ lightbox="true"
+ file="/images/integrations/jfrog/jfrog-int-settings.png"
+ url="/images/integrations/jfrog/jfrog-int-settings.png"
+ alt="JFrog Artifactory container registry integration"
+ caption="JFrog Artifactory container registry integration"
+ max-width="50%"
+ %}
+
+For how-to instructions, see [Configure container registry integrations for GitOps in Codefresh]({{site.baseurl}}/docs/gitops-integrations/container-registries/#configure-container-registry-integrations-in-codefresh) and [Edit/delete container registry integrations for GitOps in Codefresh]({{site.baseurl}}/docs/gitops-integrations/container-registries/#editdelete-container-registry-integrations).
+
+
+## Related articles
+[Shared configuration repo]({{site.baseurl}}/docs/reference/shared-configuration/)
+[Image enrichment with GitOps integrations]({{site.baseurl}}/docs/gitops-integrations/image-enrichment-overview/)
+[GitOps CI integrations]({{site.baseurl}}/docs/gitops-integrations/ci-integrations/)
+[GitOps issue-tracking integrations]({{site.baseurl}}/docs/gitops-integrations/issue-tracking/)
diff --git a/_docs/gitops-integrations/container-registries/quay.md b/_docs/gitops-integrations/container-registries/quay.md
new file mode 100644
index 000000000..b84c068cb
--- /dev/null
+++ b/_docs/gitops-integrations/container-registries/quay.md
@@ -0,0 +1,50 @@
+---
+title: "GitOps Quay integration"
+description: ""
+group: gitops-integrations
+sub_group: container-registries
+toc: true
+---
+
+Codefresh has native support for interacting with Quay registries, from where you can push, pull, and deploy images.
+Adding a Quay integration allows you to reference the integration in external CI tools such as GitHub Actions by the name of the integration account, instead of adding explicit credentials. See [Image enrichment with GitOps integrations]({{site.baseurl}}/docs/gitops-integrations/image-enrichment-overview/) and [GitOps CI integrations]({{site.baseurl}}/docs/gitops-integrations/ci-integrations/).
+
+
+## Prerequisites
+
+1. [Create a Redhat/Quay account at Quay](https://quay.io/){:target="\_blank"}.
+1. Optional. For Codefresh integration, [create a robot account](https://docs.quay.io/glossary/robot-accounts.html){:target="\_blank"}.
+
+## Quay-GitOps integration settings 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:
All runtimes: Created in resources/all-runtimes-all-clusters/
Selected runtimes: Created in resources/runtimes//
You can reference the Docker Hub integration in the CI tool. {:/}|
+|**Domain**| Set to `quay.io`.|
+|**Username**| The Quay.io username.|
+|**Password**| The Quay.io encrypted password, or robot account if you created one.|
+
+ {% include image.html
+ lightbox="true"
+ file="/images/integrations/quay/quay-int-settings.png"
+ url="/images/integrations/quay/quay-int-settings.png"
+ alt="Quay Docker Registry integration settings in Codefresh"
+ caption="Quay Docker Registry integration settings in Codefresh"
+ max-width="50%"
+ %}
+
+For how-to instructions, see [Configure container registry integrations for GitOps in Codefresh]({{site.baseurl}}/docs/gitops-integrations/container-registries/#configure-container-registry-integrations-in-codefresh) and [Edit/delete container registry integrations for GitOps in Codefresh]({{site.baseurl}}/docs/gitops-integrations/container-registries/#editdelete-container-registry-integrations).
+
+Make sure you have the:
+* Quay domain username
+* Quay domain-encrypted password or that of the robot account
+
+
+## Related articles
+[Shared configuration repo]({{site.baseurl}}/docs/reference/shared-configuration/)
+[Image enrichment with GitOps integrations]({{site.baseurl}}/docs/gitops-integrations/image-enrichment-overview/)
+[GitOps CI integrations]({{site.baseurl}}/docs/gitops-integrations/ci-integrations/)
+[GitOps issue-tracking integrations]({{site.baseurl}}/docs/gitops-integrations/issue-tracking/)
diff --git a/_docs/gitops-integrations/image-enrichment-overview.md b/_docs/gitops-integrations/image-enrichment-overview.md
new file mode 100644
index 000000000..d232382ad
--- /dev/null
+++ b/_docs/gitops-integrations/image-enrichment-overview.md
@@ -0,0 +1,77 @@
+---
+title: "GitOps image enrichment with integrations"
+description: ""
+group: gitops-integrations
+redirect_from:
+ - /csdp-docs/docs/integrations/image-enrichment-overview/
+toc: true
+---
+
+
+
+
+Image enrichment is a crucial part of the CI/CD process, adding to the quality of deployments. Image enrichment exposes metadata such as feature requests, pull requests, and logs as part of the application's deployment, for visibility into all aspects of the deployment, making it easier to track actions and identify root cause of failures.
+
+If you have your CI tools and our Hosted GitOps, you can still enrich and report images to the Codefresh platform with no disruptions to existing CI processes and flows.
+
+Codefresh has new report images templates, optimized to work with third-party CI tools/plaforms for creating pipelines and workflows. Add integration accounts in Codefresh to tools such as Jira, Docker Hub and Quay, and then connect your CI tool with Codefresh for image enrichment and reporting.
+
+
+
+## CI integration flow for image enrichment
+
+Integrate Codefresh with your CI platform/tool account with a unique name per integration account.
+
+### 1. Add/configure integration
+
+Add/configure the integration account for the third-party tools. You can set up multiple integration accounts for the same tool.
+When you add an integration, Codefresh creates a Sealed Secret with the integration credentials, and a ConfigMap that references the secret.
+
+See:
+* Issue tracking
+ [JIRA]({{site.baseurl}}/docs/gitops-integrations/issue-tracking/jira/)
+
+* Container registries
+ [Amazon ECR]({{site.baseurl}}/docs/gitops-integrations/container-registries/amazon-ecr/)
+ [DockerHub]({{site.baseurl}}/docs/gitops-integrations/container-registries/dockerhub/)
+ [JFrog Artifactory]({{site.baseurl}}/docs/gitops-integrations/container-registries/jfrog/)
+ [Quay]({{site.baseurl}}/docs/gitops-integrations/container-registries/quay/)
+
+We are working on supporting integrations for more tools. Stay tuned for the release announcements.
+For image enrichment with a tool that is as yet unsupported, you must define the explicit credentials.
+
+### 2. Connect CI platform/tool to GitOps
+
+Connect a CI platform/tool to Codefresh GitOps with an API token for the runtime cluster, the integration accounts, and image information for enrichment and reporting.
+
+[Codefresh pipelines]({{site.baseurl}}/docs/gitops-integrations/ci-integrations/codefresh-classic/)
+[GitHub Actions]({{site.baseurl}}/docs/gitops-integrations/ci-integrations/github-actions/)
+[Jenkins]({{site.baseurl}}/docs/gitops-integrations/ci-integrations/jenkins/)
+
+
+### 3. Add the enrichment step for the CI platform/tool to your GitHub Actions pipeline
+
+Finally, add the enrichment step to your CI pipeline with the API token and integration information. Codefresh uses the integration name to get the corresponding Sealed Secret to securely access and retrieve the information for image enrichment.
+
+ [GitHub Action Codefresh report image](https://github.com/marketplace/actions/codefresh-report-image){:target="\_blank"}
+ [Codefresh pipeline Codefresh report image](https://codefresh.io/steps/step/codefresh-report-image){:target="\_blank"}
+
+
+### 4. View enriched image information
+Once deployed, view enriched information in the Codefresh UI:
+* Go to [Images](https://g.codefresh.io/2.0/images){:target="\_blank"}
+* Go to the [Applications dashboard]((https://g.codefresh.io/2.0/applications-dashboard/list){:target="\_blank"}
+
+
+View:
+
+* Commit information as well as committer
+* Links to build and deployment pipelines
+* PRs included in the deployment
+* Jira issues, status and details for each deployment
+
+
+## Related articles
+[Images]({{site.baseurl}}/docs/dashboards/images/)
+[Applications dashboard]({{site.baseurl}}/docs/deployments/gitops/applications-dashboard/)
+
diff --git a/_docs/gitops-integrations/issue-tracking.md b/_docs/gitops-integrations/issue-tracking.md
new file mode 100644
index 000000000..239ec3f48
--- /dev/null
+++ b/_docs/gitops-integrations/issue-tracking.md
@@ -0,0 +1,75 @@
+---
+title: "GitOps issue tracking integrations"
+description: ""
+group: gitops-integrations
+redirect_from:
+ - /csdp-docs/docs/integrations/issue-tracking/jira/
+toc: true
+---
+
+One of the major highlights of the Codefresh platform is the ability to automatically correlate
+software features with their deployment (where and when). While the software version of a component is easily identifiable, what is likely more interesting and important is to know which features are included in a release.
+
+Adding an issue-tracking integration in Codefresh allows you to reference the integration in third-party CI platforms/tools such as GitHub Actions and Codefresh pipelines by the name of the integration, instead of explicit credentials. See [Image enrichment with GitOps integrations]({{site.baseurl}}/docs/gitops-integrations/image-enrichment-overview/) and [CI integrations for GitOps]({{site.baseurl}}/docs/gitops-integrations/ci-integrations/).
+
+You add an issue-tracking integration in Codefresh by:
+* Defining the integration name
+* Selecting the runtime or runtimes it is shared with
+* Defining the arguments
+* Committing the changes
+
+Once added, Codefresh displays the list of existing integrations with their sync status. You can edit or delete any integration.
+
+## Configure issue tracking integrations for GitOps in Codefresh
+Configure the settings for an issue tracking integration for GitOps in Codefresh.
+
+1. In the Codefresh UI, on the toolbar, click the **Settings** icon, and then from the sidebar, select [**GitOps Integrations**](https://g.codefresh.io/2.0/account-settings/integrations){:target="\_blank"}.
+1. Filter by **Issue Tracking**, select the issue tracking tool to integrate, and click **Configure**.
+1. Jira integrations only: For a new Jira integration, from the **Add Integration** dropdown, select the type of integration, as either **Deployment reporting** or **Image enrichment**.
+1. If you already have integrations, click **Add**.
+1. Define the arguments for the issue tracking tool:
+ [Jira]({{site.baseurl}}/docs/gitops-integrations/issue-tracking/jira/)
+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 resource for the issue-tracking integration 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 issue-tracking integrations for GitOps
+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 for GitOps 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, on the toolbar, click the **Settings** icon, and then from the sidebar, select [**GitOps 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 GitOps integrations]({{site.baseurl}}/docs/gitops-integrations/ci-integrations/)
+[Container registry GitOps integrations]({{site.baseurl}}/docs/gitops-integrations/container-registries/)
+
diff --git a/_docs/gitops-integrations/issue-tracking/jira.md b/_docs/gitops-integrations/issue-tracking/jira.md
new file mode 100644
index 000000000..690d2758f
--- /dev/null
+++ b/_docs/gitops-integrations/issue-tracking/jira.md
@@ -0,0 +1,57 @@
+---
+title: "Jira GitOps integration"
+description: " "
+group: gitops-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 GitOps integration in Codefresh, see [Issue-tracking GitOps integrations]({{site.baseurl}}/docs/gitops-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-GitOps integration settings 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:
All runtimes: Created in resources/all-runtimes-all-clusters/
Selected runtimes: Created in resources/runtimes//
You can reference the Docker Hub integration in the CI tool. {:/}|
+|**Jira Host**| The URL of your Jira instance. For example, `https://.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 GitOps integrations]({{site.baseurl}}/docs/gitops-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 GitOps integrations]({{site.baseurl}}/docs/gitops-integrations/image-enrichment-overview/)
+[CI integrations]({{site.baseurl}}/docs/gitops-integrations/ci-integrations/)
+[Container registry integrations]({{site.baseurl}}/docs/gitops-integrations/container-registries/)
diff --git a/_docs/how-to-guides/migrating-from-drone-io.md b/_docs/how-to-guides/migrating-from-drone-io.md
deleted file mode 100644
index 5746b5a73..000000000
--- a/_docs/how-to-guides/migrating-from-drone-io.md
+++ /dev/null
@@ -1,224 +0,0 @@
----
-title: "Migrating from Drone.io"
-description: ""
-group: how-to-guides
-redirect_from:
- - /docs/migrating-from-droneio/
-toc: true
-old_url: /docs/migrating-from-droneio
-was_hidden: true
----
-
-So, you’ve decided to try Codefresh? Welcome on board!
-
-We’ll help you get up to speed with basic functionality such as: compiling, testing and building Docker images.
-
-{{site.data.callout.callout_info}}
-##### Repository
-
-Fork this [__repository__](https://github.com/codefreshdemo/demochat){:target="_blank"} to compare the Drone and Codefresh.
-{{site.data.callout.end}}
-
-## Looking .drone.yml file
-In the root of this repository you'll find a file named `.drone.yml` this is Drone's build descriptor and it describes the different steps that comprise general process (build, publish, notify, etc). Let's quickly review the contents of this file:
-
- `.drone.yml`
-{% highlight yaml %}
-{% raw %}
-pipeline:
- build:
- image: node:latest
- environment:
- - DEBUG=*
- commands:
- - npm install
- - npm install -g mocha
- - npm install -g istanbul
- - npm install -g gulp
- - npm install -g debug
-
- publish:
- image: plugins/docker
- repo: demochat
- username: ${DOCKERHUB_USERNAME}
- password: ${DOCKERHUB_PASSWORD}
- tags: [ "latest", "1.0" ]
- when:
- branch: master
- event: push
-
- slack:
- image: plugins/slack
- webhook: https://hooks.slack.com/services/...
- channel: drone
- username: drone
- template: >
- *{{ build.status }}* <{{ build.link }}|{{ repo.owner }}/{{ repo.name }}#{{ build.commit }}> ({{ build.ref }}) by {{ build.author }}
- when:
- event: [ push, pull_request ]
- status: [ success, failure ]
-{% endraw %}
-{% endhighlight %}
-
-The screen with processes of drone you can see below
-
-{% include image.html
-lightbox="true"
-file="/images/bf4623d-codefresh_drone_processes.png"
-url="/images/bf4623d-codefresh_drone_processes.png"
-alt="codefresh_drone_processes.png"
-max-width="40%"
-%}
-
-## Looking codefresh.yml file
-
-In this file, we will look at on `build, freestyle, composition` steps to see how to use them to build, test and deploy your repository.
-See more details about codefresh.yml steps [_here_]({{ site.baseurl }}/docs/codefresh-yaml/what-is-the-codefresh-yaml/).
-
- `codefresh.yml`
-{% highlight yaml %}
-{% raw %}
-version: '1.0'
-steps:
-
- build_step:
- type: build
- dockerfile: Dockerfile
- image-name: demochat
- tag: ${{CF_BRANCH}}
-
- unit_tests:
- image: ${{build_step}}
- fail-fast: false
- commands:
- - npm install
- - gulp test
-
- integration_step:
- type: composition
- composition:
- version: '2'
- services:
- app:
- image: ${{build_step}}
- links:
- - mongo
- ports:
- - 5000
- mongo:
- image: mongo
- composition-candidates:
- main:
- image: nhoag/curl
- command: bash -c "sleep 30 && curl http://app:5000/" | echo 'works'
-
- deploy_to_ecs:
- image: codefresh/cf-deploy-ecs
- commands:
- - cfecs-update --image-name demochat --image-tag ${{CF_BRANCH}} eu-west-1 demochat-cluster demochat-webapp
- environment:
- - AWS_ACCESS_KEY_ID=${{AWS_ACCESS_KEY_ID}}
- - AWS_SECRET_ACCESS_KEY=${{AWS_SECRET_ACCESS_KEY}}
- when:
- branch:
- only:
- - master
-{% endraw %}
-{% endhighlight %}
-
-The screen with processes of Codefresh build you can see below
-
-{% include image.html
-lightbox="true"
-file="/images/9c12ebe-codefresh_processes.png"
-url="/images/9c12ebe-codefresh_processes.png"
-alt="codefresh_processes.png"
-max-width="40%"
-%}
-
-## Compare steps of Drone vs Codefresh
-Let's take `build` and `publish` steps from `.drone.yml` and create the similar logic using `codefresh.yml` steps.
-
- `build step of .drone.yml`
-{% highlight yaml %}
-{% raw %}
- build:
- image: node:latest
- environment:
- - DEBUG=*
- commands:
- - npm install
- - npm install -g mocha
- - npm install -g istanbul
- - npm install -g gulp
- - npm install -g debug
-{% endraw %}
-{% endhighlight %}
-
-In `build` step of codefresh.yml we just use `Dockerfile` with defined commands to create your docker image.
-
- `Dockerfile`
-{% highlight docker %}
-{% raw %}
-FROM node:latest
-RUN mkdir -p /src
-WORKDIR /src
-COPY package.json /src/
-
-RUN npm install
-RUN npm install -g mocha
-RUN npm install -g istanbul
-RUN npm install -g gulp
-RUN npm install -g debug
-
-COPY . /src
-ENV DEBUG=*
-CMD ["npm", "start"]
-{% endraw %}
-{% endhighlight %}
-
- `build step of codefresh.yml`
-{% highlight docker %}
-{% raw %}
-# codefresh.yml
- build_step:
- type: build
- dockerfile: Dockerfile
- image-name: demochat
- tag: ${{CF_BRANCH}}
-{% endraw %}
-{% endhighlight %}
-
-{{site.data.callout.callout_info}}
-##### Build step of codefresh.yml
-
-More information about `build` step you can find [_here_]({{site.baseurl}}/docs/codefresh-yaml/steps/build/).
-{{site.data.callout.end}}
-
-The `publish` step of .drone.yml in codefresh.yml can be look like `push` step
-
- `build step of codefresh.yml`
-{% highlight docker %}
-{% raw %}
-push_to_dockerhub:
- type: push
- title: Step Title
- description: Free text description
- candidate: ${{build_step}}
- tag: latest
- credentials:
- username: ${DOCKERHUB_USERNAME}
- password: ${DOCKERHUB_PASSWORD}
- fail_fast: false
- when:
- branch:
- only:
- - master
-{% endraw %}
-{% endhighlight %}
-
-{{site.data.callout.callout_info}}
-##### Push step of codefresh.yml
-
-More information about `push` step you can find [_here_]({{site.baseurl}}/docs/codefresh-yaml/steps/push/).
-{{site.data.callout.end}}
diff --git a/_docs/how-to-guides/migrating-from-travis-ci.md b/_docs/how-to-guides/migrating-from-travis-ci.md
deleted file mode 100644
index 7b4beef88..000000000
--- a/_docs/how-to-guides/migrating-from-travis-ci.md
+++ /dev/null
@@ -1,463 +0,0 @@
----
-title: "Migrating from Travis CI"
-description: ""
-group: how-to-guides
-redirect_from:
- - /docs/migrating-from-travis/
-toc: true
-old_url: /docs/migrating-from-travis
-was_hidden: true
----
-So, you’ve decided to try Codefresh? Welcome on board!
-
-We’ll help you get up to speed with basic functionality such as: compiling, testing and building Docker images.
-
-{{site.data.callout.callout_info}}
-##### Repository
-
-Fork this [__repository__](https://github.com/codefreshdemo/demochat){:target="_blank"} to compare the Travis CI and Codefresh.
-{{site.data.callout.end}}
-
-## Looking into .travis.yml
-
-In the root of this repository you'll find a file named `.travis.yml` this is Travis build descriptor and it describes the different steps that comprise general process (install, script, etc). Let's quickly review the contents of this file:
-
- `.travis.yml`
-{% highlight yaml %}
-{% raw %}
-sudo: false
-
-language: node_js
-
-node_js:
- - "7"
-
-before_install:
- - export PORT=5000
-
-services:
- - mongodb
-
-install:
- - npm install
-
-before_script:
- - npm install -g mocha
- - npm install -g istanbul
- - npm install -g gulp
- - npm install -g debug
-
-script:
- - gulp test
-{% endraw %}
-{% endhighlight %}
-
-{% include image.html
-lightbox="true"
-file="/images/94376d0-travis-ci-build.png"
-url="/images/94376d0-travis-ci-build.png"
-alt="94376d0-travis-ci-build.png"
-max-width="40%"
-%}
-
-## Looking into codefresh.yml
-In this file, we will look at on `build, freestyle, composition` steps to see how to use them to build, test and deploy your repository.
-See more details about codefresh.yml steps [_here_]({{ site.baseurl }}/docs/codefresh-yaml/what-is-the-codefresh-yaml/).
-
- `codefresh.yml`
-{% highlight yaml %}
-{% raw %}
-version: '1.0'
-steps:
-
- build_step:
- type: build
- dockerfile: Dockerfile
- image-name: demochat
- tag: ${{CF_BRANCH}}
-
- unit_tests:
- image: ${{build_step}}
- fail-fast: false
- commands:
- - npm install
- - gulp test
-
- integration_step:
- type: composition
- composition:
- version: '2'
- services:
- app:
- image: ${{build_step}}
- links:
- - mongo
- ports:
- - 5000
- mongo:
- image: mongo
- composition-candidates:
- main:
- image: nhoag/curl
- command: bash -c "sleep 30 && curl http://app:5000/" | echo 'works'
-
- deploy_to_ecs:
- image: codefresh/cf-deploy-ecs
- commands:
- - cfecs-update --image-name demochat --image-tag ${{CF_BRANCH}} eu-west-1 demochat-cluster demochat-webapp
- environment:
- - AWS_ACCESS_KEY_ID=${{AWS_ACCESS_KEY_ID}}
- - AWS_SECRET_ACCESS_KEY=${{AWS_SECRET_ACCESS_KEY}}
- when:
- branch:
- only:
- - master
-{% endraw %}
-{% endhighlight %}
-
-{% include image.html
-lightbox="true"
-file="/images/9fc17cc-codefresh_processes.png"
-url="/images/9fc17cc-codefresh_processes.png"
-alt="codefresh_processes.png"
-max-width="40%"
-%}
-
-## Getting Started
-
-Let's start to do the first actions with `.travis.yml` example. This file tells Travis CI that this project is written in PHP, and to test Test.php with `phpunit` against PHP versions 5.6, 7.0
-
- `.travis.yml`
-{% highlight yaml %}
-{% raw %}
-language: php
-php:
-- 5.6
-- 7.0
-script: phpunit Test.php
-{% endraw %}
-{% endhighlight %}
-
-In `Codefresh` you can use the [freestyle step]({{site.baseurl}}/docs/codefresh-yaml/steps/freestyle/) to describe it.
-
-{{site.data.callout.callout_info}}
-Note, in Codefresh you can run [Unit tests]({{site.baseurl}}/docs/yaml-examples/examples/run-integration-tests/) and [Integration tests]({{site.baseurl}}/docs/yaml-examples/examples/run-integration-tests) as separate steps of codefresh.yml
-{{site.data.callout.end}}
-
- `codefresh.yml`
-{% highlight yaml %}
-{% raw %}
-unit_tests_5.6:
- image: php:5.6
- commands:
- - phpunit Test.php
-unit_tests_7.0:
- image: php:7.0
- commands:
- - phpunit Test.php
-{% endraw %}
-{% endhighlight %}
-
-In case if you want to run your tests in parallel you need to create two `codefresh.yml` files
-
- `codefresh.5.6.yml`
-{% highlight yaml %}
-{% raw %}
-version: '1.0'
-steps:
- unit_tests:
- image: php:5.6
- commands:
- - phpunit Test.php
-{% endraw %}
-{% endhighlight %}
-
- `codefresh.7.0.yml`
-{% highlight yaml %}
-{% raw %}
-version: '1.0'
-steps:
- unit_tests:
- image: php:7.0
- commands:
- - phpunit Test.php
-{% endraw %}
-{% endhighlight %}
-
-Now go to the pipelines of the repository and set the path to certain codefresh.yml for each of pipelines. `Add webhook` if you want to start the build automatically after commit and push.
-
-{% include image.html
-lightbox="true"
-file="/images/aaa0cc6-codefresh_pipelines.png"
-url="/images/aaa0cc6-codefresh_pipelines.png"
-alt="codefresh_pipelines.png"
-max-width="40%"
-%}
-
-## The Build Lifycycle: Installing packages
-In Codefresh we use the following steps to describe the flow
-
-- Build
-- Push
-- Git Clone
-- Composition
-- Launch Composition
-
-{{site.data.callout.callout_info}}
-##### More information
-
-[Codefresh YAML Steps]({{ site.baseurl }}/docs/codefresh-yaml/steps/)
-{{site.data.callout.end}}
-
-Using the steps above we can easily replace the commands that are used in Travis
-
-`before_install, install, before_script, script, after_success / after_failure, before_deploy, deploy, after_deploy, after_script`
-
-For instance, if you want to install something in your image you can describe it in Dockerfile using the command `RUN:`
-
- `Dockerfile`
-{% highlight docker %}
-{% raw %}
-FROM ubuntu:14.04
-
-RUN apt-get update
-
-# Add oracle java 8 repository
-RUN echo oracle-java8-installer shared/accepted-oracle-license-v1-1 select true | debconf-set-selections
-RUN apt-get -y install software-properties-common
-RUN add-apt-repository -y ppa:webupd8team/java
-RUN apt-get update
-RUN apt-get install -y oracle-java8-installer maven wget
-RUN rm -rf /var/lib/apt/lists/*
-RUN rm -rf /var/cache/oracle-jdk8-installer
-ENV JAVA_HOME /usr/lib/jvm/java-8-oracle
-
-# Install Maven, wget
-RUN apt-get -y install maven wget
-{% endraw %}
-{% endhighlight %}
-
-or you can install all necessary dependencies before running your test script.
-
- `codefresh.yml`
-{% highlight yaml %}
-{% raw %}
-unit_tests:
- image: php:5.6
- working_directory: ${{main_clone}}
- commands:
- - install-dependencies.sh
- - phpunit Test.php
-{% endraw %}
-{% endhighlight %}
-
-## Expression Condition: Skipping the step, Building specific branches
-For instance, to skip the `install` in Travis you use `install: true`
-We suggest you describe the condition when you want to skip the certain step.
-
-{% highlight yaml %}
-{% raw %}
-when:
- branch:
- only:
- - master
-{% endraw %}
-{% endhighlight %}
-
-{% highlight yaml %}
-{% raw %}
-when:
- branch:
- ignore:
- - master
- - develop
-{% endraw %}
-{% endhighlight %}
-
-{% highlight yaml %}
-{% raw %}
-when:
- condition:
- all:
- noSkipCiInCommitMessage: 'includes(lower("${{CF_COMMIT_MESSAGE}}"), "skip ci") == false'
- masterBranch: '"${{CF_BRANCH}}" == "master"'
-{% endraw %}
-{% endhighlight %}
-
-{: .table .table-bordered .table-hover}
-| Condition | Description |
-|:---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:----------------------------------------------------------------------------------------------------------------|
-| {::nomarkdown}
when: branch: only: -master
{:/} | Only execute the step for the `master` branch |
-| {::nomarkdown}
when: branch: ignore: -master -develop
{:/} | Ignore the develop branch and master branch |
-| {::nomarkdown}
{:/} | Execute if the string `[skip ci]` is not part of the main repository commit message AND if the branch is `master` |
-
-{{site.data.callout.callout_info}}
-##### More information about conditions?
-
-[Expression Condition Syntax]({{ site.baseurl }}/docs/codefresh-yaml/condition-expression-syntax/)
-[Conditional Execution of Steps]({{ site.baseurl }}/docs/codefresh-yaml/conditional-execution-of-steps/)
-{{site.data.callout.end}}
-
-## Breaking the build
-If any of the commands in the first four stages of the build lifecycle return a non-zero exit code, the build is broken.
-In Travis you can use the `after_success, after_failure, after_script` to execute post operations.
-In Codefresh we have the similar post-step operations `on_success, on_finish, on_fail`.
-
-Or you can just add the capability `fail_fast: false` to skip step if it failed and continue performing the following steps.
-
-{{site.data.callout.callout_info}}
-##### More information about post-step operations
-
-[Post-Step Operations]({{ site.baseurl }}/docs/codefresh-yaml/post-step-operations/)
-{{site.data.callout.end}}
-
-## Environment variables
-Travis and Codefresh have the similar syntax to describe the environment variables.
-
- `.travis.yml`
-{% highlight yaml %}
-{% raw %}
-language: ruby
-rvm:
-- 1.9.3
-env:
-- DB=mongodb
-{% endraw %}
-{% endhighlight %}
-
- `codefresh.yml`
-{% highlight yaml %}
-{% raw %}
-step_name:
- image: zedtux/ruby-1.9.3
- environment:
- - DB=mongodb
-{% endraw %}
-{% endhighlight %}
-
-Note: Codefresh allows to use encrypted variables.
-
- `codefresh.yml`
-{% highlight yaml %}
-{% raw %}
-step_name:
- image: zedtux/ruby-1.9.3
- environment:
- - ENCR_VAR=${{ENCR_VAR}}
-{% endraw %}
-{% endhighlight %}
-
-{% include image.html
-lightbox="true"
-file="/images/bb55c94-codefresh-encr_vars.png"
-url="/images/bb55c94-codefresh-encr_vars.png"
-alt="codefresh-encr_vars.png"
-max-width="40%"
-%}
-
-{{site.data.callout.callout_info}}
-##### See which user provided variables exist in Codefresh
-
-[User provided variables]({{ site.baseurl }}/docs/codefresh-yaml/variables/)
-{{site.data.callout.end}}
-
-## Push to docker registry
-
- `.travis.yml`
-{% highlight yaml %}
-{% raw %}
-after_success:
- - if [ "$TRAVIS_BRANCH" == "master" ]; then
- docker login -u="$DOCKER_USERNAME" -p="$DOCKER_PASSWORD";
- docker push USER/REPO;
- fi
-{% endraw %}
-{% endhighlight %}
-
- `codefresh.yml`
-{% highlight yaml %}
-{% raw %}
- build_step_name:
- type: build
- image-name: USER/REPO
- dockerfile: Dockerfile
- tag: latest
-
- push_to_dockerhub:
- type: push
- title: Step Title
- description: Free text description
- candidate: ${{build_step_name}}
- tag: latest
- credentials:
- username: ${{DOCKER_USERNAME}}
- password: ${{DOCKER_PASSWORD}}
- when:
- branch:
- only:
- - master
-{% endraw %}
-{% endhighlight %}
-
-{{site.data.callout.callout_info}}
-##### More about push step
-
-[Push step]({{site.baseurl}}/docs/codefresh-yaml/steps/push/)
-{{site.data.callout.end}}
-
-## Deploy on example of AWS Elastic Beanstalk
-To deploy to AWS Elastic Beanstalk need to use the following step in Travis and Codefresh
-
- `.travis.yml`
-{% highlight yaml %}
-{% raw %}
-deploy:
- provider: elasticbeanstalk
- access_key_id:
- secret_access_key:
- secure: "Encypted ="
- region: "us-east-1"
- app: "example-app-name"
- env: "example-app-environment"
-{% endraw %}
-{% endhighlight %}
-
- `codefresh.yml`
-{% highlight yaml %}
-{% raw %}
-deploy-to-beanstalk:
- image: garland/aws-cli-docker:latest
- commands:
- - sh -c "aws configure set region '${{AWS_REGION}}' && aws elasticbeanstalk update-environment --environment-name '${{AWS_ENV_NAME}}' --version-label '${{AWS_VERSION}}' "
- when:
- condition:
- all:
- masterBranch: "'${{CF_BRANCH}}' == '${{AWS_BRANCH}}'"
-{% endraw %}
-{% endhighlight %}
-
-In the pipeline of repository, need to provide the following environment variables
-
-{% include image.html
-lightbox="true"
-file="/images/60d70d4-codefresh_eb_env_vars.png"
-url="/images/60d70d4-codefresh_eb_env_vars.png"
-alt="codefresh_eb_env_vars.png"
-max-width="40%"
-%}
-
-## Command line client
-
-{: .table .table-bordered .table-hover}
-| Travis | Codefresh |
-|:----------------------------------------------------------------------------------------------|:------------------------------------------------------------------------------------------------------|
-| [Travis command line client](https://github.com/travis-ci/travis.rb#readme){:target="_blank"} | [Codefresh command line client](https://www.npmjs.com/package/@codefresh-io/cf-cli){:target="_blank"} |
-
-See our [examples]({{ site.baseurl }}/docs/learn-by-example/general/): how to use Codefresh command line as step of codefresh.yml
-
-## Validating yml files
-
-{: .table .table-bordered .table-hover}
-| Travis | Codefresh |
-|:-----------------------------------------------------------------------------------------------|:---------------------------------------------------------------------------------------------------------------|
-| [Validating .travis.yml files](https://docs.travis-ci.com/user/travis-lint/){:target="_blank"} | [Validating codefresh.yml files](https://www.npmjs.com/package/@codefresh-io/yaml-validator){:target="_blank"} |
diff --git a/_docs/incubation/arm-support.md b/_docs/incubation/arm-support.md
index 8f6c425b2..5a0b54b8c 100644
--- a/_docs/incubation/arm-support.md
+++ b/_docs/incubation/arm-support.md
@@ -2,6 +2,8 @@
title: "ARM Support"
description: "Use Docker containers on ARM architecture"
group: incubation
+redirect_from:
+ - /docs/incubation/arm-support/
toc: true
---
@@ -10,23 +12,23 @@ is only available to Enterprise customers.
## Enabling ARM support
-~~To run ARM pipelines in Codefresh, [open a free account]({{site.baseurl}}/docs/getting-started/create-a-codefresh-account/) and then [contact sales](https://codefresh.io/contact-us/) in order to enable ARM support.~~
+To run ARM pipelines in Codefresh, [open a free account]({{site.baseurl}}/docs/administration/account-user-management/create-codefresh-account/) and then [contact sales](https://codefresh.io/contact-us/){:target="\_blank"} in order to enable ARM support.
>Due to unforeseen circumstances, we are currently unable to support ARM builds on our SaaS infrastructure. We apologize for the inconvenience.
-Once approved, you will get access to a new runtime environment installed on an ARM cluster. This means that you will be able to run both ARM and Linux/x86 builds from the same Codefresh account by choosing the appropriate [pipeline settings]({{site.baseurl}}/docs/configure-ci-cd-pipeline/pipelines/#pipeline-settings).
+Once approved, you will get access to a new runtime environment installed on an ARM cluster. This means that you will be able to run both ARM and Linux/x86 builds from the same Codefresh account by choosing the appropriate [pipeline settings]({{site.baseurl}}/docs/pipelines/pipelines/#pipeline-settings).
## Using ARM builders in Codefresh
Once ARM support is enabled for your account, there is no other special requirement to start building ARM images.
-Just read the normal Codefresh documentation:
+Just read the Codefresh documentation:
-* [Introduction to Pipelines]({{site.baseurl}}/docs/configure-ci-cd-pipeline/introduction-to-codefresh-pipelines/)
-* [Creating a Pipeline]({{site.baseurl}}/docs/configure-ci-cd-pipeline/pipelines/)
-* [Codefresh YAML]({{site.baseurl}}/docs/codefresh-yaml/what-is-the-codefresh-yaml/)
-* [Working with Docker registries]({{site.baseurl}}/docs/docker-registries/working-with-docker-registries/)
-* [On demand environments]({{site.baseurl}}/docs/getting-started/on-demand-environments/)
+* [Introduction to Pipelines]({{site.baseurl}}/docs/pipelines/introduction-to-codefresh-pipelines/)
+* [Creating a Pipeline]({{site.baseurl}}/docs/pipelines/pipelines/)
+* [Codefresh YAML]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/)
+* [Working with Docker registries]({{site.baseurl}}/docs/ci-cd-guides/working-with-docker-registries/)
+* [On demand environments]({{site.baseurl}}/docs/quick-start/ci-quick-start/on-demand-environments/)
The only important thing to notice is to make sure that the base Docker images you use are ARM-compiled.
@@ -50,7 +52,7 @@ You will get errors only if you use a less popular image that has no ARM support
## Example for an ARM build
-The [Python sample application](https://github.com/codefresh-contrib/python-flask-sample-app) used in the [quick start guide]({{site.baseurl}}/docs/getting-started/create-a-basic-pipeline/) is based on an official Docker image that already has ARM support.
+The [Python sample application](https://github.com/codefresh-contrib/python-flask-sample-app){:target="\_blank"} used in the [quick start guide]({{site.baseurl}}/docs/quick-start/ci-quick-start/create-ci-pipeline/) is based on an official Docker image that already has ARM support.
Create a pipeline for it with the following YAML content:
@@ -84,9 +86,9 @@ This pipeline creates a Docker image for a python application and then runs unit
It contains three [steps]({{site.baseurl}}/docs/codefresh-yaml/steps/):
-1. A [clone step]({{site.baseurl}}/docs/codefresh-yaml/steps/git-clone/) that checks out code from the Git repository.
-1. A [build step]({{site.baseurl}}/docs/codefresh-yaml/steps/build/) that reads a Dockerfile and creates a Docker image.
-1. A [freestyle step]({{site.baseurl}}/docs/codefresh-yaml/steps/freestyle/) that runs unit tests.
+1. A [clone step]({{site.baseurl}}/docs/pipelines/steps/git-clone/) that checks out code from the Git repository.
+1. A [build step]({{site.baseurl}}/docs/pipelines/steps/build/) that reads a Dockerfile and creates a Docker image.
+1. A [freestyle step]({{site.baseurl}}/docs/pipelines/steps/freestyle/) that runs unit tests.
The logs verify that this is an ARM image:
@@ -112,7 +114,7 @@ caption="Private Registry for ARM docker images"
max-width="60%"
%}
-You can also launch it as a [demo environment]({{site.baseurl}}/docs/getting-started/on-demand-environments/).
+You can also launch it as a [demo environment]({{site.baseurl}}/docs/quick-start/ci-quick-start/on-demand-environments/).
{% include
image.html
@@ -126,8 +128,7 @@ max-width="60%"
In summary, the workflow for ARM images is exactly the same as the usual Linux/x86 images.
-## What to read next
-
-* [Windows container support]({{site.baseurl}}/docs/incubation/windows-beta/)
-* [macOS and iOS builds]({{site.baseurl}}/docs/incubation/osx-ios-builds/)
+## Related articles
+[Windows container support]({{site.baseurl}}/docs/incubation/windows-beta/)
+[macOS and iOS builds]({{site.baseurl}}/docs/incubation/osx-ios-builds/)
diff --git a/_docs/incubation/osx-ios-builds.md b/_docs/incubation/osx-ios-builds.md
index 936ad93c7..96b111463 100644
--- a/_docs/incubation/osx-ios-builds.md
+++ b/_docs/incubation/osx-ios-builds.md
@@ -2,16 +2,18 @@
title: "macOS and iOS builds"
description: "Using Codefresh for Mac/iPhone applications"
group: incubation
+redirect_from:
+ - /docs/incubation/osx-ios-builds/
toc: true
---
-Codefresh is offering alpha support for macOS and/or iOS as a CI/CD environment. Access to the build environment is possible after invite only. To run macOS/iOS pipelines in Codefresh, [open a free account]({{site.baseurl}}/docs/getting-started/create-a-codefresh-account/) and then [contact sales](https://codefresh.io/contact-us/) in order to enable this build environment type.
+Codefresh offers alpha support for macOS and/or iOS as a CI/CD environment. Access to the build environment is possible by invitation only. To run macOS/iOS pipelines in Codefresh, [open a free account]({{site.baseurl}}/docs/administration/account-user-management/create-codefresh-account/) and then [contact sales](https://codefresh.io/contact-us/){:target="\_blank"} in order to enable this build environment type.
> macOS/iOS builds are only available for the SaaS platform. They are not available for the Hybrid platform at this time.
## Enabling macOS/iOS support
-Once approved, you will get access to a special runtime environment environment that will run your macOS/iOS builds. To use this environment [create a new pipeline]({{site.baseurl}}/docs/configure-ci-cd-pipeline/pipelines/) and select it in the pipeline settings screen.
+Once approved, you will get access to a special runtime environment that will run your macOS/iOS builds. To use this environment [create a new pipeline]({{site.baseurl}}/docs/pipelines/pipelines/) and select it in the pipeline settings screen.
{% include
image.html
@@ -27,7 +29,7 @@ The macOS runtime environment has Xcode already installed for your iOS and/or ma
## Building macOS/iOS applications with Codefresh
-Once you assign the special macOS runtime to your pipeline, you can write your [Codefresh YAML]({{site.baseurl}}/docs/codefresh-yaml/what-is-the-codefresh-yaml/) as usual, keeping in mind the following points
+Once you assign the special macOS runtime to your pipeline, you can write your [Codefresh YAML]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/) as usual, keeping in mind the following points
* The git-clone step is available
* Freestyle steps must use the `freestyle-ssh` type
@@ -40,7 +42,7 @@ As part of the alpha version the nodes that run your macOS builds are actual nod
## macOS build pipeline example
-You can find a full Codefresh example at [https://github.com/alex-codefresh/osx-demo-webserver](https://github.com/alex-codefresh/osx-demo-webserver).
+You can find a full Codefresh example at [https://github.com/alex-codefresh/osx-demo-webserver](https://github.com/alex-codefresh/osx-demo-webserver){:target="\_blank"}.
Create a pipeline for it with the following YAML content:
@@ -103,7 +105,7 @@ steps:
This pipeline clones the sample application, builds it with Xcode and then runs it. Notice that the run step
cleans up on its own (because macOS builds are not docker based so nothing is cleaned up automatically when the pipeline has finished).
-Notice also that `freestyle-ssh` steps do not define a docker image (unlike normal [freestyle steps]({{site.baseurl}}/docs/codefresh-yaml/steps/freestyle/)).
+Notice also that `freestyle-ssh` steps do not define a docker image (unlike normal [freestyle steps]({{site.baseurl}}/docs/pipelines/steps/freestyle/)).
The logs will show all build information:
@@ -117,5 +119,5 @@ caption="macOS build log"
max-width="90%"
%}
-Currently, we are working on offering configurable versions of Xcode, Swift, and macOS so that pipelines can define exactly what development environment they need. We also plan [fastlane](https://fastlane.tools/) integration.
+Currently, we are working on offering configurable versions of Xcode, Swift, and macOS so that pipelines can define exactly what development environment they need. We also plan [fastlane](https://fastlane.tools/){:target="\_blank"} integration.
diff --git a/_docs/incubation/windows.md b/_docs/incubation/windows.md
index 6b874122a..c2c9413f5 100644
--- a/_docs/incubation/windows.md
+++ b/_docs/incubation/windows.md
@@ -3,6 +3,7 @@ title: "Windows Containers Support Overview"
description: "Using Docker on Windows in Codefresh"
group: incubation
redirect_from:
+ - /docs/incubation/windows/
- /docs/windows/
- /docs/incubation/windows-beta/
toc: true
@@ -12,16 +13,15 @@ Codefresh pipelines have the option to support Windows based containers.
If you have projects in your organization based on the .NET Framework or are in transition from Windows to Linux based projects and still need to have CI/CD pipelines for Windows containers, you’ll now be able to achieve this by using Codefresh.
-> Note: To enable Windows builds on your Codefresh account please [contact sales](https://codefresh.io/contact-us/)
+> Note: To enable Windows builds on your Codefresh account please [contact sales](https://codefresh.io/contact-us/){:target="\_blank"}
-Once approved, you will get access to a new runtime environment on a dedicated Windows Server version 1709 VM. This means that you will be able to run both Windows and Linux/x86 builds from the same Codefresh account by choosing the appropriate [pipeline settings]({{site.baseurl}}/docs/configure-ci-cd-pipeline/pipelines/#pipeline-settings).
+Once approved, you will get access to a new runtime environment on a dedicated Windows Server version 1709 VM. This means that you will be able to run both Windows and Linux/x86 builds from the same Codefresh account by choosing the appropriate [pipeline settings]({{site.baseurl}}/docs/pipelines/pipelines/#pipeline-settings).
-> Note: For .NET Core projects you can use a standard Linux based Codefresh account. See [our example]({{site.baseurl}}/docs/learn-by-example/dotnet/)
-
+> Note: For .NET Core projects you can use a standard Linux based Codefresh account. See [our example]({{site.baseurl}}/docs/example-catalog/ci-examples/dotnet/).
Codefresh Windows pipelines support the following Codefresh steps:
**Clone**, **Build**, **Push**, **Composition**, **Deploy** and **Freestyle**.
-Please refer to our [steps documentation](https://codefresh.io/docs/docs/codefresh-yaml/steps/) to learn more about each of them.
+Please refer to our [steps documentation]({{site.baseurl}}/docs/pipelines/steps/) to learn more about each of them.
## Example
@@ -76,9 +76,8 @@ steps:
```
-## What to read next
-
-* [Introduction to pipelines]({{site.baseurl}}/docs/configure-ci-cd-pipeline/introduction-to-codefresh-pipelines/)
-* [Creating pipelines]({{site.baseurl}}/docs/configure-ci-cd-pipeline/pipelines/)
-* [Codefresh YAML]({{site.baseurl}}/docs/codefresh-yaml/what-is-the-codefresh-yaml/)
-* [Installation options]({{site.baseurl}}/docs/administration/installation-security/)
+## Related articles
+[Introduction to pipelines]({{site.baseurl}}/docs/pipelines/introduction-to-codefresh-pipelines/)
+[Creating pipelines]({{site.baseurl}}/docs/pipelines/pipelines/)
+[Codefresh YAML]({{site.baseurl}}/docs/pipelines/what-is-the-codefresh-yaml/)
+[Installation options]({{site.baseurl}}/docs/installation/installation-options/)
diff --git a/_docs/installation/behind-the-firewall.md b/_docs/installation/behind-the-firewall.md
new file mode 100644
index 000000000..8ca10c151
--- /dev/null
+++ b/_docs/installation/behind-the-firewall.md
@@ -0,0 +1,246 @@
+---
+title: "Runner installation behind firewalls"
+description: "Run Codefresh pipelines in your own secure infrastructure"
+group: installation
+redirect_from:
+ - /docs/administration/behind-the-firewall/
+ - /docs/enterprise/behind-the-firewall/
+toc: true
+---
+
+As described in [installation options]({{site.baseurl}}/docs/installation/installation-options/), Codefresh offers Runner and GitOps options for hybrid installations.
+This articles focuses on the Runner installation option and its advantages.
+
+## Running Codefresh in secure environments
+
+Codefresh has an on-premises installation in which the Codefresh platform is installed on the customer's premises. While
+this solution is very effective as far as security is concerned, it places a lot of overhead on the customer, as all updates
+and improvements done in the platform must also be transferred to the customer premises.
+
+Hybrid Runner installs the Runner within the customer premises, while the UI (and management platform) stays in Codefresh.
+
+Here is the overall architecture:
+
+{% include image.html
+ lightbox="true"
+ file="/images/runtime/behind-the-firewall/architecture.png"
+ url="/images/runtime/behind-the-firewall/architecture.png"
+ alt="Codefresh Hybrid CD/CD behind the firewall"
+ caption="Codefresh Hybrid CD/CD behind the firewall"
+ max-width="100%"
+ %}
+
+The advantages for this scenario are multi-fold.
+
+Regarding platform maintenance:
+
+ 1. Codefresh is responsible for the heavy lifting for platform maintenance, instead of the customer.
+ 1. Updates to the UI, build engine, integrations etc., happen automatically, without any customer involvement.
+ 1. Actual builds run in the customer premises under fully controlled conditions.
+ 1. Codefresh Runner is fully automated. It handles volume claims and build scheduling on its own within the Kubernetes cluster it is placed.
+
+Regarding security of services:
+
+ 1. Pipelines can run in behind-the-firewall clusters with internal services.
+ 1. Pipelines can use integrations (such as Docker registries) that are private and secure.
+ 1. Source code does not ever leave the customer premises.
+
+Regarding firewall security:
+
+ 1. Uni-directional, outgoing communication between the Runner and Codefresh. The Runner polls the platform for jobs.
+ 1. Codefresh never connects to the customer network. No ports need to be open in the customer firewall for the runner to work.
+ 1. Codefresh Runner is fully open-sourced, so its code can be scrutinized by any stakeholder.
+
+
+
+## Using secure services in your pipelines
+
+After installing the [Codefresh Runner]({{site.baseurl}}/docs/installation/codefresh-runner/) on your private Kubernetes cluster in your infrastructure, all pipelines in the private Kubernetes cluster have access to all other internal services that are network reachable.
+
+You can easily create pipelines that:
+
+ * Use databases internal to the company
+ * Run integration tests against services internal to the company
+ * Launch [compositions]({{site.baseurl}}/docs/pipelines/steps/composition/) that communicate with other secure services
+ * Upload and download artifacts from a private artifact repository (e.g., Nexus or Artifactory)
+ * Deploy to any other cluster accessible in the secure network
+ * Create infrastructure such as machines, load balancers, auto-scaling groups etc.
+
+ Any of these pipelines will work out the box without extra configuration. In all cases,
+ all data stays witin the private local network and does not exit the firewall.
+
+ >Notice that [long-running compositions]({{site.baseurl}}/docs/pipelines/steps/composition/) (preview test environments) are not yet available via the Codefresh Runner.
+
+
+
+### Checking out code from a private GIT repository
+
+To check out code from your private Git repository, you need to connect first to Codefresh via [Git integrations]({{site.baseurl}}/docs/integrations/git-providers/). However, once you define your GIT provider as *on premise* you also
+need to mark it as *behind the firewall* as well:
+
+{% include image.html
+ lightbox="true"
+ file="/images/runtime/behind-the-firewall/behind-the-firewall-toggle.png"
+ url="/images/runtime/behind-the-firewall/behind-the-firewall-toggle.png"
+ alt="Behind the firewall toggle"
+ caption="Behind the firewall toggle"
+ max-width="100%"
+ %}
+
+Once you do that save your provider and make sure that it has the correct tags. The name you used for the Git provider will also be used in the pipeline. You cannot "test the connection" because
+the Codefresh SAAS doesn't have access to your on-premises GIT repository.
+
+{% include image.html
+ lightbox="true"
+ file="/images/runtime/behind-the-firewall/behind-the-firewall-tag.png"
+ url="/images/runtime/behind-the-firewall/behind-the-firewall-tag.png"
+ alt="Behind the firewall tags"
+ caption="Behind the firewall tags"
+ max-width="100%"
+ %}
+
+To check out code just use a [clone step]({{site.baseurl}}/docs/pipelines/steps/git-clone/) like any other clone operation.
+The only thing to remember is that the Git URL must be fully qualified. You need to [create a pipeline]({{site.baseurl}}/docs/pipelines/pipelines/#pipeline-creation-modes) on it its own from the *Pipelines* section of the left sidebar (instead of one adding a Git repository to Codefresh)
+
+
+
+`YAML`
+{% highlight yaml %}
+{% raw %}
+version: '1.0'
+steps:
+ main_clone:
+ type: git-clone
+ description: Step description
+ repo: https://github-internal.example.com/my-username/my-app
+ git: my-internal-git-provider
+ BuildingDockerImage:
+ title: Building Docker Image
+ type: build
+ image_name: my-image
+ tag: '${{CF_BRANCH_TAG_NORMALIZED}}-${{CF_SHORT_REVISION}}'
+ dockerfile: Dockerfile
+{% endraw %}
+{% endhighlight %}
+
+Once you trigger the pipeline, the Codefresh Build Runtimes communicates with your private Git instance and checks out code.
+
+>Note that currently there is a limitation on the location of the `codefresh.yml` file. Only the [inline mode]({{site.baseurl}}/docs/pipelines/pipelines/#writing-codefresh-yml-in-the-gui) is supported. Soon we will allow the loading of the pipeline from the Git repository itself.
+
+You can also use a [network proxy]({{site.baseurl}}/docs/pipelines/steps/git-clone/#using-git-behind-a-proxy) for the Git clone step.
+
+#### Adding triggers from private Git repositories
+
+
+In the previous section we have seen how a pipeline can check out code from an internal Git repository. We also need to set up a trigger,
+so that every time a commit or any other supported event occurs, the Codefresh pipeline is triggered automatically.
+
+If you have installed the [optional app-proxy]({{site.baseurl}}/docs/installation/codefresh-runner/#optional-installation-of-the-app-proxy), adding a trigger can be done exactly like the SAAS version of Codefresh, using only the Codefresh UI.
+
+If you haven't installed the app-proxy, then adding a Git trigger is a two-step process:
+
+1. First we set up a webhook endpoint in Codefresh.
+1. Then we create the webhook call in the side of the the GIT provider.
+
+> To support triggers based on PR (Pull Request) events, it is mandatory to install `app-proxy`.
+
+For the Codefresh side, follow the usual instructions for creating a [basic Git trigger]({{site.baseurl}}/docs/pipelines/triggers/git-triggers/).
+
+Once you select your GIT provider, you need to manually enter your username and repository that you wish to trigger the build.
+
+{% include image.html
+ lightbox="true"
+ file="/images/runtime/behind-the-firewall/enter-repo-details.png"
+ url="/images/runtime/behind-the-firewall/enter-repo-details.png"
+ alt="Entering repository details"
+ caption="Entering repository details"
+ max-width="60%"
+ %}
+
+All other details (git events, branch naming, monorepo pattern, etc.) are still the same as normal SAAS GIT providers.
+Once that is done, Codefresh will show you the webhook endpoint along with a secret for triggering this pipeline. Note them down.
+
+
+{% include image.html
+ lightbox="true"
+ file="/images/runtime/behind-the-firewall/codefresh-webhook.png"
+ url="/images/runtime/behind-the-firewall/codefresh-webhook.png"
+ alt="Codefresh webhook details"
+ caption="Codefresh webhook details"
+ max-width="60%"
+ %}
+
+This concludes the setup on the Codefresh side. The final step is create a webhook call on the side of your GIT provider.
+The instructions are different per GIT provider:
+
+* [GitHub webhooks](https://developer.github.com/webhooks/){:target="\_blank"}
+* [GitLab webhooks](https://docs.gitlab.com/ee/user/project/integrations/webhooks.html){:target="\_blank"}
+* [Stash webhooks](https://confluence.atlassian.com/bitbucketserver/managing-webhooks-in-bitbucket-server-938025878.html){:target="\_blank"}
+
+In all cases make sure that the payload is JSON, because this is what Codefresh expects.
+
+* For GitHub the events monitored should be `Pull requests` and `Pushes`.
+* For GitLab the events monitored should be `Push events`,`Tag push events` and `Merge request events`.
+
+After the setup is finished, the Codefresh pipeline will be executed every time a git event happens.
+
+### Accessing an internal docker registry
+
+To access an internal registry just follow the instructions for [adding registries]({{site.baseurl}}/docs/integrations/docker-registries/). Like Git repositories, you need to mark the Docker registry as *Behind the firewall*.
+
+Once that is done, use the [push step]({{site.baseurl}}/docs/pipelines/steps/push/) as usual with the name you gave to the registry during the integration setup.
+
+
+`YAML`
+{% highlight yaml %}
+{% raw %}
+version: '1.0'
+steps:
+ gitClone:
+ type: git-clone
+ description: Step description
+ repo: https://github-internal.example.com/my-username/my-app
+ git: my-internal-git-repo
+ BuildingDockerImage:
+ title: Building Docker Image
+ type: build
+ image_name: my-image
+ dockerfile: Dockerfile
+ PushingDockerImage:
+ title: Pushing a docker image
+ type: push
+ candidate: '${{BuildingDockerImage}}'
+ tag: '${{CF_BRANCH}}'
+ registry: my-internal-docker-registry
+{% endraw %}
+{% endhighlight %}
+
+
+### Deploying to an internal Kubernetes cluster
+
+To connect a cluster that is behind the firewall follow the [connecting cluster guide]({{site.baseurl}}/docs/integrations/kubernetes/#connect-a-kubernetes-cluster), paying attention to the following two points:
+
+1. Your cluster should be added as a _Adding any other cluster type (not dependent on any provider_.
+1. You need to mark the cluster as internal by using the toggle switch.
+
+
+
+
+{% include image.html
+ lightbox="true"
+ file="/images/runtime/behind-the-firewall/cluster-behind-firewall.png"
+ url="/images/runtime/behind-the-firewall/cluster-behind-firewall.png"
+ alt="Marking a Kubernetes cluster as internal"
+ caption="Marking a Kubernetes cluster as internal"
+ max-width="60%"
+ %}
+
+The cluster where the runner works on should have network connectivity with the cluster you wish to deploy to.
+
+>Notice that the service account used in the cluster configuration is completely independent from the privileges granted to the Codefresh build runner. The privileges needed by the runner are only used to launch Codefresh pipelines within your cluster. The Service account used in the "custom provider" setting should have the needed privileges for deployment.
+
+Once your cluster is connected you can use any of the familiar deployment methods such as the [dedicated deploy step]({{site.baseurl}}/docs/deployments/kubernetes/) or [custom kubectl commands]({{site.baseurl}}/docs/deployments/kubernetes/custom-kubectl-commands/).
+
+## Related articles
+[Google marketplace integration]({{site.baseurl}}/docs/integrations/google-marketplace/)
+[Managing your Kubernetes cluster]({{site.baseurl}}/docs/deployments/kubernetes/manage-kubernetes/)
diff --git a/_docs/installation/cli.md b/_docs/installation/cli.md
new file mode 100644
index 000000000..f2ed820bc
--- /dev/null
+++ b/_docs/installation/cli.md
@@ -0,0 +1,25 @@
+---
+title: "CLI"
+description: "Run Codefresh pipelines in your own secure infrastructure"
+group: installation
+toc: true
+---
+
+Codefresh has two different CLIs, one for Codefresh pipelines, and one for Codefresh GitOps.
+
+**Codefresh CLI**
+Interact with Codefresh through the CLI and:
+* Perform any UI operation
+* Create complex automation from your local machine
+* Create and run pipelines for complex use cases using the CLI within pipeline steps
+
+For installation instructions and CLI command descriptions, see the [CLI documentation](https://codefresh-io.github.io/cli/getting-started/){:target="\_blank"}.
+
+
+
+**GitOps CLI**
+Keep up to date with the latest features through the GitOps CLI.
+The GitOps CLI is required to install GitOps runtimes. As several new features are available only with the latest GitOps CLI release, it's important to have the latest one.
+Upgrade is easy as you don't have to keep track of the different versions. The GitOps CLI automatically checks its own version and prints a banner if there is a newer version.
+
+For details, see [Download/Upgrade the GitOps CLI]({{site.baseurl}}/docs/installation/gitops/upgrade-gitops-cli/).
\ No newline at end of file
diff --git a/_docs/administration/codefresh-on-prem-upgrade.md b/_docs/installation/codefresh-on-prem-upgrade.md
similarity index 75%
rename from _docs/administration/codefresh-on-prem-upgrade.md
rename to _docs/installation/codefresh-on-prem-upgrade.md
index 458a70862..8889f058e 100644
--- a/_docs/administration/codefresh-on-prem-upgrade.md
+++ b/_docs/installation/codefresh-on-prem-upgrade.md
@@ -1,9 +1,10 @@
---
title: "Codefresh On-Premises Upgrade"
description: "Use the Kubernetes Codefresh Installer to upgrade the Codefresh On-Premises platform "
-group: administration
+group: installation
redirect_from:
- /docs/enterprise/codefresh-on-prem-upgrade/
+ - /docs/administration/codefresh-on-prem-upgrade/
toc: true
---
Upgrade the Codefresh on-premises platform to the latest version:
@@ -12,10 +13,10 @@ Upgrade the Codefresh on-premises platform to the latest version:
* Complete post-upgrade configuration: If needed, also based on the version you are upgrading to, complete the required tasks
-### Upgrade to 1.1.1
+## Upgrade to 1.1.1
Prepare for the upgrade to v1.1.1 by performing the tasks listed below.
-#### Maintain backward compatibility for infrastructure services
+### Maintain backward compatibility for infrastructure services
If you have Codefresh version 1.0.202 or lower installed, and are upgrading to v1.1.1, to retain the existing images for the services listed below, update the `config.yaml` for `kcfi`.
* `cf-mongodb`
@@ -63,7 +64,7 @@ consul:
ImageTag: 1.0.0 # (default `imageTag:1.11`)
...
```
-### Upgrade to 1.2.0 and higher
+## Upgrade to 1.2.0 and higher
This major release **deprecates** the following Codefresh managed charts:
* Ingress
* Rabbitmq
@@ -78,7 +79,7 @@ See the instructions below for each of the affected charts.
`kubectl delete pdb cf-rabbitmq --namespace ${CF_NAMESPACE}`
`kubectl delete pdb cf-redis --namespace ${CF_NAMESPACE}`
-#### Update configuration for Ingress chart
+### Update configuration for Ingress chart
From version **1.2.0 and higher**, we have deprecated support for `Codefresh-managed-ingress`.
Kubernetes community public `ingress-nginx` chart replaces `Codefresh-managed-ingress` chart. For more information on the `ingress-nginx`, see [kubernetes/ingress-nginx](https://github.com/kubernetes/ingress-nginx).
@@ -90,7 +91,7 @@ You must update `config.yaml`, if you are using:
* External ingress controllers, including ALB (Application Load Balancer)
* Codefresh-managed ingress controller with _custom_ values
-##### Update configuration for external ingress controllers
+#### Update configuration for external ingress controllers
For external ingress controllers, including ALB (Application Load Balancer), update the relevant sections in `config.yaml` to align with the new name for the ingress chart:
@@ -132,7 +133,7 @@ ingress:
# kubernetes.io/ingress.class: my-non-codefresh-nginx
```
-##### Update configuration for Codefresh-managed ingress with custom values
+#### Update configuration for Codefresh-managed ingress with custom values
If you were running `Codefresh-managed ingress` controller with _custom_ values refer to [values.yaml](https://github.com/kubernetes/ingress-nginx/blob/main/charts/ingress-nginx/values.yaml) from the official repo. If needed, update the `ingress-nginx` section in `config.yaml`. The example below shows the default values (already provided in Codefresh chart) for `ingress-nginx`:
@@ -168,7 +169,7 @@ ingress-nginx:
`kubectl get svc cf-ingress-nginx-controller -o jsonpath={.status.loadBalancer.ingress[0].ip`
-#### Update configuration for RabbitMQ chart
+### Update configuration for RabbitMQ chart
From version **1.2.2 and higher**, we have deprecated support for the `Codefresh-managed Rabbitmq` chart. Bitnami public `bitnami/rabbitmq` chart has replaced the `Codefresh-managed rabbitmq`. For more information, see [bitnami/rabbitmq](https://github.com/bitnami/charts/tree/master/bitnami/rabbitmq).
> Configuration updates are not required if you are running an **external** RabbitMQ service.
@@ -238,7 +239,7 @@ rabbitmq:
size: 32Gi
```
-#### Update configuration for Redis chart
+### Update configuration for Redis chart
From version **1.2.2 and higher**, we have deprecated support for the `Codefresh-managed Redis` chart. Bitnami public `bitnami/redis` chart has replaced the `Codefresh-managed Redis` chart. For more information, see [bitnami/redis](https://github.com/bitnami/charts/tree/master/bitnami/redis).
Redis storage contains **CRON and Registry** typed triggers so you must migrate existing data from the old deployment to the new stateful set.
@@ -248,7 +249,7 @@ This is done by backing up the existing data before upgrade, and then restoring
* When running an **external** Redis service.
* If CRON and Registy triggers have not been configured.
-##### Verify existing Redis data for CRON and Registry triggers
+#### Verify existing Redis data for CRON and Registry triggers
Check if you have CRON and Registry triggers configured in Redis.
* Run `codefresh get triggers`
@@ -269,7 +270,7 @@ keys * #show keys
* If there are results, continue with _Back up existing Redis data_.
-##### Back up existing Redis data
+#### Back up existing Redis data
Back up the existing data before the upgrade:
* Connect to the pod, run `redis-cli`, export AOF data from old `cf-redis-*` pod:
@@ -281,7 +282,7 @@ REDIS_POD=$(kubectl get pods -l app=cf-redis -o custom-columns=:metadata.name --
kubectl cp $REDIS_POD:/bitnami/redis/data/appendonly.aof appendonly.aof -c cf-redis
```
-##### Restore backed-up Redis data
+#### Restore backed-up Redis data
Restore the data after the upgrade:
* Copy `appendonly.aof` to the new `cf-redis-master-0` pod:
@@ -368,19 +369,19 @@ redis:
> If you run the upgrade without redis backup and restore procedure, **Helm Releases Dashboard** page might be empty for a few minutes after the upgrade.
-### Upgrade to 1.3.0 and higher
+## Upgrade to 1.3.0 and higher
This major release **deprecates** the following Codefresh managed charts:
* Consul
* Nats
-#### Update configuration for Consul
+### Update configuration for Consul
From version **1.3.0 and higher**, we have deprecated the Codefresh-managed `consul` chart, in favor of Bitnami public `bitnami/consul` chart. For more information, see [bitnami/consul](https://github.com/bitnami/charts/tree/master/bitnami/consul).
Consul storage contains data about **Windows** worker nodes, so if you had any Windows nodes connected to your OnPrem installation, see the following instruction:
> Use `https:///admin/nodes` to check for any existing Windows nodes.
-##### Back up existing consul data
+#### Back up existing consul data
_Before starting the upgrade_, back up existing data.
> Because `cf-consul` is a StatefulSet and has some immutable fields in its spec with both old and new charts having the same names, you cannot perform a direct upgrade.
@@ -403,7 +404,7 @@ kubectl cp -n codefresh cf-consul-0:backup.snap backup.snap
kubectl delete statefulset cf-consul -n codefresh
```
-##### Restore backed up data
+#### Restore backed up data
After completing the upgrade to the current version, restore the `consul` data that you backed up.
@@ -420,7 +421,7 @@ kubectl exec -it cf-consul-0 -n codefresh -- consul snapshot restore /tmp/backup
For the complete list of values, see [values.yaml](https://github.com/bitnami/charts/blob/master/bitnami/consul/values.yaml)
-#### Update Nats configuration
+### Update Nats configuration
From version **1.3.0 and higher**, we have deprecated Codefresh-managed `nats` chart in favor of Bitnami public `bitnami/nats` chart. For more information, see [bitnami/nats](https://github.com/bitnami/charts/tree/master/bitnami/consul).
> Because `cf-nats` is a StatefulSet and has some immutable fields in its spec, both the old and new charts have the same names, preventing a direct upgrade.
@@ -436,7 +437,7 @@ kubectl delete statefulset cf-nats -n codefresh
> Nats chart was replaced, and values structure might be different for some parameters.
For the complete list of values, see [values.yaml](https://github.com/bitnami/charts/blob/master/bitnami/nats/values.yaml).
-#### Upgrade to 1.3.1 and higher
+### Upgrade to 1.3.1 and higher
Chart **v1.3.1** fixes duplicated env vars `CLUSTER_PROVIDERS_URI` and `CLUSTER_PROVIDERS_PORT` in `cf-api` deployment.
```yaml
@@ -456,71 +457,94 @@ builder:
- "myregistrydomain.com:5000"
```
-### Upgrade to 1.4.0 and higher
+## Upgrade to 1.4.0 and higher
-> Update `kcfi` tool to the latest [0.5.18](https://github.com/codefresh-io/kcfi/releases/tag/0.5.18) version
+Affected values:
+- `HorizontalPodAutoscaler` is renamed to `hpa`
+
+> Update `kcfi` tool to the latest [0.5.18](https://github.com/codefresh-io/kcfi/releases/tag/0.5.18){:target="\_blank"} version
This major release **deprecates** the following Codefresh managed charts and replaces them with Bitnami charts:
* [Postgresql](#update-configuration-for-postgresql-chart)
* [Mongodb](#update-configuration-for-mongodb-chart)
-Read both instructions prior the upgrade.
+>Read instructions _before_ the upgrade.
+
+### Update configuration for Postgresql chart
+From version **1.4.0 and higher**, we have deprecated support for the `Codefresh-managed Postgresql` chart. It has been replaced with Bitnami public chart `bitnami/postgresql`.
+For more information, see [bitnami/postgresql](https://github.com/bitnami/charts/tree/master/bitnami/postgresql){:target="\_blank"}.
-#### Update configuration for Postgresql chart
-From version **1.4.0 and higher**, we have deprecated support for the `Codefresh-managed Postgresql` chart. Bitnami public `bitnami/postgresql` chart has replaced the `Codefresh-managed postgresql`. For more information, see [bitnami/postgresql](https://github.com/bitnami/charts/tree/master/bitnami/postgresql).
+> If in `config.yaml`, `postgresql.enabled=false` indicating that you are running and [**external** Postgresql service]({{site.baseurl}}/docs/installation/codefresh-on-prem/#configuring-an-external-postgres-database), you can ignore the configuration instructions.
-> If you run [**external** Postgresql service]({{site.baseurl}}/docs/administration/codefresh-on-prem/#configuring-an-external-postgres-database) (i.e. `postgresql.enabled=false` is specified in `config.yaml`), you can skip the following instruction.
+> **Important!** Run the upgrade with `global.seedJobs=true` flag:
+
+```yaml
+global:
+ seedJobs: true
+```
+
+#### Manual backup and restore
-##### Manual backup and restore
**Before the upgrade:**
-Obtain the PostgresSQL administrator password:
+1. Obtain the PostgresSQL administrator password:
```shell
-export PGPASSWORD=$(kubectl get secret --namespace codefresh cf-postgresql -o jsonpath="{.data.postgres-password}" | base64 --decode)
+NAMESPACE=codefresh
+export PGPASSWORD=$(kubectl get secret --namespace $NAMESPACE cf-postgresql -o jsonpath="{.data.postgres-password}" | base64 --decode)
```
-
-Forward the PostgreSQL service port and place the process in the background:
+1. Forward the PostgreSQL service port and place the process in the background:
```shell
-kubectl port-forward --namespace codefresh svc/cf-postgresql 5432:5432 &
+kubectl port-forward --namespace $NAMESPACE svc/cf-postgresql 5432:5432 &
```
-
-Create a directory for the backup files and make it the current working directory:
+1. Create a directory for the backup files and make it the current working directory:
```shell
mkdir psqlbackup
chmod o+w psqlbackup
cd psqlbackup
```
-
-Back up the contents of audit database to the current directory using the *pg_dump* tool. If this tool is not installed on your system, use [Bitnami's PostgreSQL Docker image](https://github.com/bitnami/containers/tree/main/bitnami/postgresql) to perform the backup, as shown below:
+1. Back up the contents of audit database to the current directory using the *pg_dump* tool.
+ If this tool is not installed on your system, use [Bitnami's PostgreSQL Docker image](https://github.com/bitnami/containers/tree/main/bitnami/postgresql){:target="\_blank"} to perform the backup, as shown below:
```shell
docker run --rm --name postgresql-backup -e PGPASSWORD=$PGPASSWORD -v $(pwd):/app --net="host" bitnami/postgresql:13 pg_dump -Fc --dbname audit -h host.docker.internal -p 5432 -f /app/audit.dump
```
-Here, the *--net* parameter lets the Docker container use the host's network stack and thereby gain access to the forwarded port. The *pg_dump* command connects to the PostgreSQL service and creates backup files in the */app* directory, which is mapped to the current directory (*psqlbackup/*) on the Docker host with the *-v* parameter. Finally, the *--rm* parameter deletes the container after the *pg_dump* command completes execution.
+> The above command is true for Windows and macOS, for Linux users `host.docker.internal` has to be replaced with `127.0.0.1`
+
+Here:
+* The *--net* parameter lets the Docker container use the host's network stack and thereby gain access to the forwarded port.
+* The *pg_dump* command connects to the PostgreSQL service and creates backup files in the */app* directory, which is mapped to the current directory (*psqlbackup/*) on the Docker host with the *-v* parameter.
+* The *--rm* parameter deletes the container after the *pg_dump* command completes execution.
**After the upgrade:**
Create an environment variable with the password for the new stateful set:
```shell
-export PGPASSWORD=$(kubectl get secret --namespace codefresh cf-postgresql -o jsonpath="{.data.postgres-password}" | base64 --decode)
+export PGPASSWORD=$(kubectl get secret --namespace $NAMESPACE cf-postgresql -o jsonpath="{.data.postgres-password}" | base64 --decode)
```
Forward the PostgreSQL service port for the new stateful set and place the process in the background:
```shell
-kubectl port-forward --namespace codefresh svc/cf-postgresql 5432:5432
+kubectl port-forward --namespace $NAMESPACE svc/cf-postgresql 5432:5432
```
Restore the contents of the backup into the new release using the *pg_restore* tool. If this tool is not available on your system, mount the directory containing the backup files as a volume in Bitnami's PostgreSQL Docker container and use the *pg_restore* client tool in the container image to import the backup into the new cluster, as shown below:
```shell
cd psqlbackup
-docker run --rm --name postgresql-backup -e PGPASSWORD=$PGPASSWORD -v $(pwd):/app --net="host" bitnami/postgresql:13 pg_restore --Fc --create --dbname postgres -h host.docker.internal -p 5432 /app/audit.dump
+docker run --rm --name postgresql-backup -e PGPASSWORD=$PGPASSWORD -v $(pwd):/app --net="host" bitnami/postgresql:13 pg_restore -Fc --create --dbname postgres -h host.docker.internal -p 5432 /app/audit.dump
```
-##### Backup and restore via Helm hooks
+> The above command is true for Windows and macOS, for Linux users `host.docker.internal` has to be replaced with `127.0.0.1`
+
+#### Backup and restore via Helm hooks
-It’s is also possible to run Postgresql database migration with `pre-upgrade` and `post-upgrade` helm hooks. To enable it, set `postgresql.migration.enabled=true` (specify additional parameters if necessary).
-It will create a k8s Job with PVC and run `pg_dump` and `pg_restore` during the upgrade.
+You can also run Postgresql database migration with `pre-upgrade` and `post-upgrade` helm hooks.
+> It's strongly recommended to create a **MANUAL** backup prior to the upgrade!
+
+
+**To enable backup and restore via Helm hooks:**
+* Set `postgresql.migration.enabled=true` (specify additional parameters if necessary).
+ It will create a k8s Job with PVC, and run `pg_dump` and `pg_restore` during the upgrade.
```yaml
postgresql:
@@ -539,73 +563,89 @@ postgresql:
resources: {}
```
-> It's strongly recommended to create a **MANUAL** backup prior the upgrade!
-#### Update configuration for Mongodb chart
+### Update configuration for Mongodb chart
-From version **1.4.0 and higher**, we have deprecated support for the `Codefresh-managed MongoDB` chart. Bitnami public `bitnami/mongodb` chart has replaced the `Codefresh-managed MongoDB`. For more information, see [bitnami/mongodb](https://github.com/bitnami/charts/tree/master/bitnami/mongodb).
+From version **1.4.0 and higher**, we have deprecated support for the `Codefresh-managed MongoDB` chart. It has been replaced with Bitnami public chart `bitnami/mongodb`.
+For more information, see [bitnami/mongodb](https://github.com/bitnami/charts/tree/master/bitnami/mongodb){:target="\_blank"}.
-> If you run [**external** MongoDB service]({{site.baseurl}}/docs/administration/codefresh-on-prem/#configuring-an-external-mongodb) (i.e. `mongo.enabled=false` is specified in `config.yaml`), you can skip the following instruction.
+> If in `config.yaml`, `mongo.enabled=false`, indicating that you are running an [**external** MongoDB service]({{site.baseurl}}/docs/installation/codefresh-on-prem/#configuring-an-external-mongodb), you can ignore the configuration updates.
-##### Manual backup and restore
+> **Important!** Run the upgrade with `global.seedJobs=true` flag:
-**Before the upgrade:**
+```yaml
+global:
+ seedJobs: true
+```
+
+#### Manual backup and restore
+
+**Before the upgrade:**
-Obtain the MongoDB administrator password:
+1. Obtain the MongoDB administrator password:
```shell
-export MONGODB_ROOT_PASSWORD=$(kubectl get secret --namespace codefresh cf-mongodb -o jsonpath="{.data.mongodb-root-password}" | base64 --decode)
+NAMESPACE=codefresh
+export MONGODB_ROOT_PASSWORD=$(kubectl get secret --namespace $NAMESPACE cf-mongodb -o jsonpath="{.data.mongodb-root-password}" | base64 --decode)
```
-
-Forward the MongoDB service port and place the process in the background:
+1. Forward the MongoDB service port and place the process in the background:
```shell
-kubectl port-forward --namespace codefresh svc/mongodb 27017:27017 &
+kubectl port-forward --namespace $NAMESPACE svc/mongodb 27017:27017 &
```
-
-Create a directory for the backup files and make it the current working directory:
+1. Create a directory for the backup files and make it the current working directory:
```shell
mkdir mongobackup
chmod o+w mongobackup
cd mongobackup
```
-
-Back up the contents of all the databases to the current directory using the monogodump tool. If this tool is not installed on your system, use [Bitnami's MongoDB Docker image](https://github.com/bitnami/containers/tree/main/bitnami/mongodb) to perform the backup, as shown below:
+1. Back up the contents of all the databases to the current directory using the `monogodump` tool.
+ If this tool is not installed on your system, use [Bitnami's MongoDB Docker image](https://github.com/bitnami/containers/tree/main/bitnami/mongodb){:target="\_blank"} to perform the backup, as shown below:
```shell
docker run --rm --name mongodb-backup -v $(pwd):/app --net="host" bitnami/mongodb:4.2 mongodump --host="host.docker.internal:27017" -u root -p $MONGODB_ROOT_PASSWORD -o /app
```
-Here, the *--net* parameter lets the Docker container use the host's network stack and thereby gain access to the forwarded port. The *mongodump* command connects to the MongoDB service and creates backup files in the */app* directory, which is mapped to the current directory (*mongobackup/*) on the Docker host with the *-v* parameter. Finally, the *--rm* parameter deletes the container after the *mongodump* command completes execution.
+> The above command is true for Windows and macOS, for Linux users `host.docker.internal` has to be replaced with `127.0.0.1`
+
+Here:
+* The *--net* parameter lets the Docker container use the host's network stack and thereby gain access to the forwarded port.
+* The *mongodump* command connects to the MongoDB service and creates backup files in the */app* directory, which is mapped to the current directory (*mongobackup/*) on the Docker host with the *-v* parameter.
+* The *--rm* parameter deletes the container after the *mongodump* command completes execution.
**After the upgrade:**
-Create an environment variable with the password for the new stateful set:
+1. Create an environment variable with the password for the new stateful set:
```shell
-export MONGODB_ROOT_PASSWORD=$(kubectl get secret --namespace codefresh cf-mongodb -o jsonpath="{.data.mongodb-root-password}" | base64 --decode)
+export MONGODB_ROOT_PASSWORD=$(kubectl get secret --namespace $NAMESPACE cf-mongodb -o jsonpath="{.data.mongodb-root-password}" | base64 --decode)
```
-
-Forward the MongoDB service port for the new stateful set and place the process in the background:
-
+1. Forward the MongoDB service port for the new stateful set and place the process in the background:
(**Note!** Default service address was changed)
```shell
-kubectl port-forward --namespace codefresh svc/cf-mongodb 27017:27017 &
+kubectl port-forward --namespace $NAMESPACE svc/cf-mongodb 27017:27017 &
```
-
-Restore the contents of the backup into the new release using the *mongorestore* tool. If this tool is not available on your system, mount the directory containing the backup files as a volume in Bitnami's MongoDB Docker container and use the *mongorestore* client tool in the container image to import the backup into the new cluster, as shown below:
+1. Restore the contents of the backup into the new release using the `mongorestore` tool.
+ If this tool is not available on your system, mount the directory containing the backup files as a volume in Bitnami's MongoDB Docker container and use the `mongorestore` client tool in the container image to import the backup into the new cluster, as shown below:
```shell
cd mondgobackup
docker run --rm --name mongodb-backup -v $(pwd):/app --net="host" bitnami/mongodb:4.2 mongorestore --host="host.docker.internal:27017" -u root -p $MONGODB_ROOT_PASSWORD /app
```
-Stop the service port forwarding by terminating the background process.
+> The above command is true for Windows and macOS, for Linux users `host.docker.internal` has to be replaced with `127.0.0.1`
-Connect to the new stateful set and confirm that your data has been successfully restored:
+1. Stop the service port forwarding by terminating the background process.
+1. Connect to the new stateful set and confirm that your data has been successfully restored:
```shell
-kubectl run --namespace codefresh mongodb-new-client --rm --tty -i --restart='Never' --image docker.io/bitnami/mongodb:4.2 --command -- mongo codefresh --host cf-mongodb --authenticationDatabase admin -u root -p $MONGODB_ROOT_PASSWORD --eval "db.accounts.find()"
+kubectl run --namespace $NAMESPACE mongodb-new-client --rm --tty -i --restart='Never' --image docker.io/bitnami/mongodb:4.2 --command -- mongo codefresh --host cf-mongodb --authenticationDatabase admin -u root -p $MONGODB_ROOT_PASSWORD --eval "db.accounts.find()"
```
-##### Backup and restore via Helm hooks
+#### Backup and restore via Helm hooks
+
+You can also run MongoDB database migration with `pre-upgrade` and `post-upgrade` helm hooks.
+
+> It's strongly recommended to create a **MANUAL** backup prior to the upgrade!
+
-It’s is also possible to run MongoDB database migration with `pre-upgrade` and `post-upgrade` helm hooks. To enable it, set `mongodb.migration.enabled=true` (specify additional parameters if necessary).
-It will create a k8s Job with PVC and run `mongodump` and `mongorestore` during the upgrade.
+**To enable backup and restore via Helm hooks:**
+* Set `mongodb.migration.enabled=true` (specify additional parameters if necessary).
+ It will create a k8s Job with PVC and run `mongodump` and `mongorestore` during the upgrade.
```yaml
mongodb:
@@ -624,9 +664,8 @@ mongodb:
resources: {}
```
-> It's strongly recommended to create a **MANUAL** backup prior the upgrade!
-### Upgrade the Codefresh Platform with [kcfi](https://github.com/codefresh-io/kcfi)
+## Upgrade the Codefresh Platform with [kcfi](https://github.com/codefresh-io/kcfi)
1. Locate the `config.yaml` file you used in the initial installation.
1. Change the release number inside it.
@@ -649,9 +688,9 @@ mongodb:
1. Log in to the Codefresh UI, and check the new version.
1. If needed, enable/disable new feature flags.
-### Codefresh with Private Registry
+## Codefresh with Private Registry
-If you install/upgrade Codefresh on the air-gapped environment (without access to public registries or Codefresh Enterprise registry) you will have to copy the images to your organization container registry.
+If you install/upgrade Codefresh on an air-gapped environment (without access to public registries or Codefresh Enterprise registry), you will have to copy the images to your organization's container registry.
**Obtain [image list](https://github.com/codefresh-io/onprem-images/tree/master/releases) for specific release**
diff --git a/_docs/administration/codefresh-on-prem.md b/_docs/installation/codefresh-on-prem.md
similarity index 79%
rename from _docs/administration/codefresh-on-prem.md
rename to _docs/installation/codefresh-on-prem.md
index 69ba0dd9a..2ea9ec604 100644
--- a/_docs/administration/codefresh-on-prem.md
+++ b/_docs/installation/codefresh-on-prem.md
@@ -1,113 +1,218 @@
---
-title: "Codefresh On-Premises Installation"
+title: "Codefresh On-Prem Installation & Configuration"
description: "Use the Kubernetes Codefresh Installer to install the Codefresh On-Premises platform "
-group: administration
+group: installation
redirect_from:
+ - /docs/administration/codefresh-on-prem/
- /docs/enterprise/codefresh-on-prem/
toc: true
---
-## Introduction
-This manual will guide you through the installation of the Codefresh platform on your on-prem environment. This manual is intended to cover all aspects of installation, and maintenance. Please read this manual carefully before installing Codefresh.
+This article will guide you through the installation of the Codefresh platform on your on-prem environment. This article covers all aspects of installation and configuration. Please read the article carefully before installing Codefresh.
[kcfi](https://github.com/codefresh-io/kcfi) (the Kubernetes Codefresh Installer) is a one-stop-shop for this purpose. Even though Codefresh offers multiple tools to install components, `kcfi` aggregates all of them into a single tool.
-## Survey -- What Codefresh Needs to Know
+## Survey: What Codefresh needs to know
-The following information needs to be provided to Codefresh before the installation to make sure your on-prem environment is ready for deployment:
+Fill out this survey before the installation to make sure your on-prem environment is ready for deployment:
-Please fill out [this survey](https://docs.google.com/forms/d/e/1FAIpQLSf18sfG4bEQuwMT7p11F6q70JzWgHEgoAfSFlQuTnno5Rw3GQ/viewform).
+[Survey](https://docs.google.com/forms/d/e/1FAIpQLSf18sfG4bEQuwMT7p11F6q70JzWgHEgoAfSFlQuTnno5Rw3GQ/viewform)
-## Supported Operating Systems and Git Providers
+## On-prem system requirements
-The `kcfi` tool supports the following operating systems:
+{: .table .table-bordered .table-hover}
+| Item | Requirement |
+| -------------- | -------------- |
+|Kubernetes cluster | Server versions v1.22+. |
+|Operating systems|{::nomarkdown}
Windows 10/7
Linux
OSX
{:/}|
+|Git providers |{::nomarkdown}
GitHub: SaaS and on-premises versions
Bitbucket: SaaS and Bitbucket server (on-premises) 5.4.0 version and above
GitLab: SaaS and on-premise versions (API v4 only)
{:/}|
+|Minimum node sizes |{::nomarkdown}
Single node: 8 CPU core and 16GB RAM
Multi node: master(s) + 3 nodes with 4 CPU core and 8GB RAM (24 GB in total)
{:/}|
-- Windows
-- Linux
-- OSX
-Codefresh supports the following Git providers:
-- GitHub: SaaS and on-premises versions
-- Bitbucket: SaaS and Bitbucket server (on-premises) 5.4.0 version and above
-- GitLab: SaaS and on-premise versions (API v4 only)
## Prerequisites
-- Kubernetes cluster v1.22+
- - Minimum node sizes:
- - Single node: 8 CPU core and 16GB RAM
- - Multi node: master(s) + 3 nodes with 4 CPU core and 8GB RAM (24 GB in total)
+### Service Account file
+The GCR Service Account JSON file, `sa.json` is provided by Codefresh. Contact support to get the file before installation.
+
+### Default app credentials
+Also provided by Codefresh. Contact support to get them file before installation.
+
+### TLS certificates
+For a secured installation, we highly recommend using TLS certificates. Make sure your `ssl.cert` and `private.key` are valid.
+
+> Use a Corporate Signed certificate, or any valid TLS certificate, for example, from lets-encrypt.
+
+### Interent connections
+We require outbound internet connections for these services:
+* GCR to pull platform images
+* Dockerhub to pull pipeline images
+
+
+## Security Constraints
+
+Codefresh has some security assumptions about the Kubernetes cluster it is installed on.
+
+### RBAC for Codefresh
+
+The Codefresh installer should be run with a Kubernetes RBAC role that allows object creation in a single namespace. If, by corporate policy, you do not allow the creation of service accounts or roles, a Kubernetes administrator will need to create the role, service account, and binding as shown below.
+
+>Users with the `codefresh-app` role cannot create other roles or role bindings.
+
+`codefresh-app-service-account.yaml`
+```yaml
+apiVersion: v1
+kind: ServiceAccount
+metadata:
+ name: codefresh-app
+ namespace: codefresh
+```
+
+`codefresh-app-role.yaml`
+```yaml
+apiVersion: rbac.authorization.k8s.io/v1
+kind: Role
+metadata:
+ name: codefresh-app
+ namespace: codefresh
+rules:
+- apiGroups:
+ - ""
+ - apps
+ - codefresh.io
+ - autoscaling
+ - extensions
+ - batch
+ resources:
+ - '*'
+ verbs:
+ - '*'
+- apiGroups:
+ - networking.k8s.io
+ - route.openshift.io
+ - policy
+ resources:
+ - routes
+ - ingresses
+ - poddisruptionbudgets
+ verbs:
+ - '*'
+```
-- Service Account file (provided by Codefresh)
-- Default app credentials (provided by Codefresh)
-- Storage size allocated for Codefresh persisted services - described in the storage section
+`codefresh-app-roleBinding.yaml`
+```yaml
+apiVersion: rbac.authorization.k8s.io/v1
+kind: RoleBinding
+metadata:
+ labels:
+ app: codefresh
+ name: codefresh-app-binding
+ namespace: codefresh
+roleRef:
+ apiGroup: rbac.authorization.k8s.io
+ kind: Role
+ name: codefresh-app
+subjects:
+- kind: ServiceAccount
+ name: codefresh-app
+```
-Codefresh will need an outbound connection to the Internet for the following services:
+To apply these changes, run:
+
+```
+kubectl apply -f [file]
+```
-- GCR - pulling platform images
-- Dockerhub - pulling pipeline images
+### Operator CRD
-## Download and Install `kcfi`
+If, due to security rules you are not allowed to create a CRD for a client running `kcfi`, have an Administrator create the RBAC (as instructed above) and the CRD as follows:
-`kcfi` is a single binary and doesn’t have any dependencies.
+`codefresh-crd.yaml`
+```yaml
+apiVersion: apiextensions.k8s.io/v1beta1
+kind: CustomResourceDefinition
+metadata:
+ name: codefreshes.codefresh.io
+ labels:
+ app: cf-onprem-operator
+spec:
+ group: codefresh.io
+ names:
+ kind: Codefresh
+ listKind: CodefreshList
+ plural: codefreshes
+ singular: codefresh
+ scope: Namespaced
+ subresources:
+ status: {}
+ versions:
+ - name: v1alpha1
+ served: true
+ storage: true
+```
-Download the binary from [GitHub](https://github.com/codefresh-io/kcfi/releases).
->Note: Darwin is for OSX
+To apply these changes, run:
+```
+kubectl apply -f codefresh-crd.yaml
+```
-Extract the downloaded file.
+You will also need to modify the `config.yaml` for `kcfi` by setting `skipCRD: true` and `serviceAccountName: codefresh-app`:
-Copy the file to your $PATH, i.e. `cp /path/to/kcfi /usr/local/bin`
+`config.yaml`
+```yaml
+ operator:
+ #dockerRegistry: gcr.io/codefresh-enterprise
+ #image: codefresh/cf-onprem-operator
+ #imageTag:
+ serviceAccountName: codefresh-app
+ skipCRD: true
+```
## Install the Codefresh Platform
-### Step 1 -- Set the Current Context
+### Before you begin
-Make sure you have a `kubeconfig` file with the correct context set.
+### Step1 : Download and extract `kcfi`
+Download the binary for `kcfi`. It is a single binary without dependencies.
-i.e.,
+1. Download the binary from [GitHub](https://github.com/codefresh-io/kcfi/releases){:target="\_blank"}.
+ >Note: Darwin is for OSX
+1. Extract the downloaded file.
+1. Copy the file to your $PATH: `cp /path/to/kcfi /usr/local/bin`
+
+### Step 2: Set the current context
+* Make sure you have a `kubeconfig` file with the correct context, as in this example:
```
kubectl config get-contexts # display list of contexts
kubectl config use-context my-cluster-name # set the default context to my-cluster-name
kubectl config current-context # verify the current-context`
```
+### Step 3: Initialize and configure `config.yaml`
+Prepare the platform for installation by initializing the directory with `config.yaml`. Then edit `config.yaml` and configure all installation settings, including files and directories required, and then deploy to Kubernetes.
-### Step 2 -- Prepare the Codefresh Platform Installation
+The `config.yaml` is includes descriptions for every parameter.
-Run the following:
+1. Create the directory with the `config.yaml`:
```
kcfi init codefresh [-d /path/to/stage-dir]
```
-Running the init command will create a directory containing a `config.yaml` file, which will be uses to configure our installation, along with other files and directories required for the installation.
-
-Edit the configuration in `config.yaml` and deploy to Kubernetes. The `config.yaml` is very descriptive and it contains an explanation for every parameter.
-
-#### Installation Methods (Helm)
-
-You have the option to install by using **Helm**, which will install/upgrade the chart from the client.
-Define **helm** as your preferred installation method in the `config.yaml`:
+1. Below `installer`, define your installation method as either Helm or Codefresh CRD:
```yaml
-metadata:
installer:
- type: helm
- helm:
- chart: codefresh
- repoUrl: https://chartmuseum.codefresh.io/codefresh # install/upgrade helm chart from client
+ # type:
+ # "operator" - apply codefresh crd definition
+ # "helm" - install/upgrade helm chart from client
```
+1. If you are installing Codefresh in an air-gapped environment (without access to public Docker Hub or codefresh-enterprise registry), copy the images to your organization container registry (Kubernetes will pull the images from it as part of the installation).
-Specify your `global.appUrl` domain name. It will be used as Ingress hostname.
-
-```yaml
-global:
- appUrl: onprem.codefresh.local
-```
+ 1. Set `usePrivateRegistry` to `true`.
+ 1. Define `privateRegistry` `address`, `username` and `password`.
-If you install Codefresh on the air-gapped environment (without access to public Docker Hub or codefresh-enterprise registry) you will have to copy the images to your organization container registry (Kubernetes will pull the images from it as part of the installation).
-This can be done by uncommenting and setting the proper values in the `config.yaml` file:
```yaml
images:
@@ -120,38 +225,57 @@ images:
lists:
- images/images-list
```
-Set `usePrivateRegistry: true`, and set `privateRegistry` `address`, `username` and `password`.
+1. Push all or a single image:
+ * All images:
+ ```
+ kcfi images push [-c|--config /path/to/config.yaml]
+ ```
+ * Single image:
+ ```
+ kcfi images push [-c|--config /path/to/config.yaml] [options] repo/image:tag [repo/image:tag]
+ ```
-Then, execute the following:
+ > To get the full list of options, run `kcfi images --help`.
-```
-kcfi images push [-c|--config /path/to/config.yaml]
-```
+ >Even if you are running a Kubernetes cluster with outgoing access to the public internet, note that Codefresh platform images are not public and can be obtained by using `sa.json` file provided by Codefresh support personnel.
+ Use the flag `--codefresh-registry-secret` to pass the path to the file `sa.json`.
-Or, to push a single image, execute the following:
-```
-kcfi images push [-c|--config /path/to/config.yaml] [options] repo/image:tag [repo/image:tag]
-```
+### Step 4: (Optional) Configure TLS certificates
+If you are using TLS, enable it in `config.yaml`.
-You can find a full list of options by running `kcfi images --help`.
+1. Set `tls.selfSigned =false`.
+1. Place both `ssl.crt` and `private.key` into certs/ directory.
-Even if you are running a Kubernetes cluster that has outgoing access to the public Internet, note that Codefresh platform images are not public and can be obtained by using `sa.json` file provided by Codefresh support personnel.
+### Step 5: Deploy On-premises platform
-Use the flag `--codefresh-registry-secret` to pass the path to the file `sa.json`.
+1. Run:
-### Step 3 -- TLS Certificates (Optional)
+```
+kcfi deploy [ -c config.yaml ] [ --kube-context ] [ --atomic ] [ --debug ] [ helm upgrade parameters ]
+```
+### Step 6: Install the Codefresh Kubernetes Agent
-It is highly recommended to use TLS certificates for a secured installation. In the `config.yaml` file set `tls.selfSigned=false` and place both `ssl.crt` and `private.key` into certs/ directory.
+Install the `cf-k8s-agent` on a cluster separate from the installer, or in a different namespace on the same cluster.
+The `cf-k8s-agent` accesses Kubernetes resources (pods, deployments, services, etc.) behind the firewall to display them in the Codefresh UI. The agent streams updates from cluster resources and then sends information updates to the `k8s-monitor` service.
->Note: Any valid TLS certificate will work, i.e. certificates from lets-encrypt or a Corporate Signed certificate.
+1. Create a staging directory for the agent:
-### Step 4 -- Deploy
+```
+kcfi init k8s-agent
+```
+ A staging directory is created, named k8s-agent with a `config.yaml`.
+1. Edit k8s-agent/config.yaml ?? for what??
-Deploy the Codefresh Platform by running:
+1. Run:
```
-kcfi deploy [ -c config.yaml ] [ --kube-context ] [ --atomic ] [ --debug ] [ helm upgrade parameters ]
+kcfi deploy [ -c config.yaml ] [-n namespace]
```
+ where:
+ [namespace] is the namespace if you are installing the agent in the same cluster.
+
+
+
## High-Availability (HA) with active-passive clusters
Enable high-availability in the Codefresh platform for disaster recovery with an active-passive cluster configuration.
@@ -245,11 +369,11 @@ These services are not considered critical as they are part of build-handling. I
* `cf-sign`
-## Additional Configurations
+## Additional configuration
-After you install Codefresh, these are some day-2 operations that you should follow.
+After you install Codefresh, these are post-installation operations that you should follow.
-### Selectively enable SSO providers
+### Selectively enable SSO provider for account
As a Codefresh administrator, you can select the providers you want to enable for SSO in your organization, for both new and existing accounts.
You can always renable a provider when needed.
@@ -258,7 +382,7 @@ You can always renable a provider when needed.
1. From the left pane, select **Providers**.
1. Disable the providers not relevant for the accounts.
These providers are not displayed as options during sign-up/sign-in.
-
+
{% include image.html
lightbox="true"
file="/images/administration/sso/enable-disable-providers.png"
@@ -269,9 +393,9 @@ These providers are not displayed as options during sign-up/sign-in.
%}
-### Setup Git Integration (Optional)
+### (Optional) Set up Git integration
-Codefresh supports out-of-the-box Git logins using your local username and password, or logins using your git provider (per the list and instructions of providers below). You can also configure login to supported SSO providers post-install as described [in the Codefresh documentation]({{site.baseurl}}/docs/administration/single-sign-on/sso-setup-oauth2/).
+Codefresh supports out-of-the-box Git logins using your local username and password, or logins using your Git provider, as described below.You can also configure login to supported SSO providers after installation, as described in [Setting up OpenID Connect (OIDC) Federated Single Sign-On (SSO)]({{site.baseurl}}/docs/single-sign-on/oidc/).
If you’d like to set up a login to Codefresh using your Git provider, first login using the default credentials (username: `AdminCF`, password: `AdminCF` and add your Git provider OAuth integration details in our admin console:
@@ -310,17 +434,22 @@ Click **Save application**.
After app creation, note down the created Application ID and Client Secret. They will be required for the settings in **Codefresh Admin**->**IDPs**.
+
>Note: When configuring the default IDP (for GitHub, GitLab, etc), do not modify the Client Name field. Please keep them as GitHub, GitLab, BitBucket, etc. Otherwise, the signup and login views won’t work.
### Proxy Configuration
-If your environment resides behind HTTP proxies, you need to uncomment the following section in config.yaml:
+If your environment resides behind HTTP proxies, you need to uncomment the following section in `config.yaml`:
```yaml
global:
@@ -391,7 +520,7 @@ Codefresh installation supports automatic storage provisioning based on the stan
### Retention policy for Codefresh builds
-You can define a retention policy to manage Codefresh builds. The retention settings are controlled through `cf-api` deployment environment variables, all of which have default settings which you can retain or customize. The default policy is set to delete builds older than six months, including offline logs.
+Define a retention policy to manage Codefresh builds. The retention settings are controlled through `cf-api` deployment environment variables, all of which have default settings which you can retain or customize. By default, Codefresh deletes builds older than six months, including offline logs.
The retention mechanism, implemented as a Cron Job, removes data from collections such as:
* workflowproccesses
@@ -399,34 +528,33 @@ The retention mechanism, implemented as a Cron Job, removes data from collection
* workflowrevisions
{: .table .table-bordered .table-hover}
-| Env Variable | Description | Default |
-|------------------------------- |-------------------------------------------------------------------------------- |---------------------- |
-|`RETENTION_POLICY_IS_ENABLED` | Determines if automatic build deletion through the Cron job is enabled. | `true` |
-|`RETENTION_POLICY_BUILDS_TO_DELETE`| The maximum number of builds to delete by a single Cron job. To avoid database issues, especially when there are large numbers of old builds, we recommend deleting them in small chunks. You can gradually increase the number after verifying that performance is not affected. | `50` |
+| Env Variable | Description | Default |
+|---------------|--------------------------- |---------------------- |
+|`RETENTION_POLICY_IS_ENABLED` | Determines if automatic build deletion through the Cron job is enabled. | `true` |
+|`RETENTION_POLICY_BUILDS_TO_DELETE`| The maximum number of builds to delete by a single Cron job. To avoid database issues, especially when there are large numbers of old builds, we recommend deleting them in small chunks. You can gradually increase the number after verifying that performance is not affected. | `50` |
|`RETENTION_POLICY_DAYS` | The number of days for which to retain builds. Builds older than the defined retention period are deleted. | `180` |
|`RUNTIME_MONGO_URI` | Optional. The URI of the Mongo database from which to remove MongoDB logs (in addition to the builds). | |
### Managing Codefresh backups
-Codefresh on-premises backups can be automated by installing a specific service as an addon to your Codefresh on-premises installation. It is based on the [mgob](https://github.com/stefanprodan/mgob) open source project and can run scheduled backups with retention, S3 & SFTP upload, notifications, instrumentation with Prometheus and more.
-
-#### Configuring and Installing the Backup Manager
-
-Backup manager is installed as an addon and therefore it needs an existing Codefresh on-premises installation. Before installing it, please make sure you have selected a proper kube config pointing to the cluster, where you have Codefresh installed on.
+Codefresh on-premises backups can be automated by installing a specific service as an addon to your Codefresh on-premises installation. It is based on the [mgob](https://github.com/stefanprodan/mgob){:target="\_blank"} open source project, and can run scheduled backups with retention, S3 & SFTP upload, notifications, instrumentation with Prometheus and more.
-To configure backup manager, please go to the staging directory of your Codefresh installation and find a specific config file: `your-CF-stage-dir/addons/backup-manager/config.yaml`.
+#### Configure and deploy the Backup Manager
-There you will find a few configuration parameters, which you might want to change:
+Backup Manager is installed as an addon and therefore it needs an existing Codefresh on-premises installation.
+Before installing it, please make sure you have selected a proper kube config pointing to the cluster, where you have Codefresh installed on.
-* `metadada` - various CF-installer-specific parameters, which should not be changed in this case
-* `kubernetes` - here you can specify a kube context, kube config file and a namespace for the backup manager
-* `storage`- storage class, storage size and read modes for persistent volumes to store backups locally within your cluster
-* Backup plan configuration parameters under `jobConfigs.cfBackupPlan`:
+1. Go to the staging directory of your Codefresh installation, and open the config file: `your-CF-stage-dir/addons/backup-manager/config.yaml`.
+1. Retain or customize the values of these configuration parameters:
+ * `metadada`: Various CF-installer-specific parameters, which should not be changed in this case
+ * `kubernetes`: Specify a kube context, kube config file, and a namespace for the backup manager
+ * `storage`: Storage class, storage size and read modes for persistent volumes to store backups locally within your cluster
+ * Backup plan configuration parameters under `jobConfigs.cfBackupPlan`:
* `target.uri` - target mongo URI. It is recommended to leave the mongo uri value blank - it will be taken automatically from the Codefresh release installed in your cluster
* `scheduler` - here you can specify cron expression for your backups schedule, backups retention and timeout values
-For more advanced backup plan settings, like specifying various remote cloud-based storage providers for your backups, configuring notifications and other, please refer to [this](https://github.com/stefanprodan/mgob#configure) page
+For more advanced backup plan settings, such as specifying various remote cloud-based storage providers for your backups, configuring notifications and other, please refer to [this](https://github.com/stefanprodan/mgob#configure) page
To **deploy the backup manager** service, please select a correct kube context, where you have Codefresh on-premises installed and deploy backup-manager with the following command:
@@ -452,7 +580,7 @@ By default Codefresh deploys the [ingress-nginx](https://github.com/kubernetes/i
#### NLB
-To use a **Network Load Balancer** - deploy a regular Codefresh installation with the following ingress config for the the `cf-ingress-controller` controller service.
+To use a **Network Load Balancer** - deploy a regular Codefresh installation with the following ingress config for the `cf-ingress-controller` controller service.
`config.yaml`
```yaml
diff --git a/_docs/administration/codefresh-runner.md b/_docs/installation/codefresh-runner.md
similarity index 94%
rename from _docs/administration/codefresh-runner.md
rename to _docs/installation/codefresh-runner.md
index 2f157bc94..f62d1c61e 100644
--- a/_docs/administration/codefresh-runner.md
+++ b/_docs/installation/codefresh-runner.md
@@ -1,9 +1,11 @@
---
-title: "Codefresh Runner"
-description: "Install Runner to run Codefresh pipelines on your private Kubernetes cluster"
-group: administration
+title: "Codefresh Runner installation"
+description: "Run Codefresh pipelines on your private Kubernetes cluster"
+group: installation
redirect_from:
+ - /docs/administration/codefresh-runner/
- /docs/enterprise/codefresh-runner/
+ - /docs/administration/codefresh-hybrid/
toc: true
---
@@ -13,7 +15,6 @@ As the Codefresh Runner is **not** dependent on any special dockershim features,
-
## System requirements
@@ -88,8 +89,8 @@ codefresh runner init --token <--dry-run>
{% include image.html
lightbox="true"
- file="/images/administration/runner/installation-wizard.png"
- url="/images/administration/runner/installation-wizard.png"
+ file="/images/runtime/runner/installation-wizard.png"
+ url="/images/runtime/runner/installation-wizard.png"
alt="Codefresh Runner wizard"
caption="Codefresh Runner wizard"
max-width="100%"
@@ -99,8 +100,8 @@ codefresh runner init --token <--dry-run>
{% include image.html
lightbox="true"
- file="/images/administration/runner/sample-pipeline.png"
- url="/images/administration/runner/sample-pipeline.png"
+ file="/images/runtime/runner/sample-pipeline.png"
+ url="/images/runtime/runner/sample-pipeline.png"
alt="Codefresh Runner example pipeline"
caption="Codefresh Runner example pipeline"
max-width="90%"
@@ -441,7 +442,7 @@ codefresh runner init --values values-ebs.yaml --exec-demo-pipeline false --skip
GKE volume configuration includes:
* [Local SSD storage configuration](#local-ssd-storage-configuration)
-* [GCE disk storage configuration](#gce-disk-storage-configuration)
+* [GCE disk storage configuration](#gce-disk-storage-configuration)
@@ -587,18 +588,17 @@ Once you have applied the patch, future builds will include the label preventing
## View Codefresh Runner and runtime environments
-Once installed, the Runner polls Codefresh every three seconds by default to automatically create all resources needed for running pipelines.
-
-* In the Codefresh UI, to see the cluster with the Runner, from the sidebar, select [Runtime Environments](https://g.codefresh.io/account-admin/account-conf/runtime-environments){:target="\_blank"}.
-
-
+Once installed, the Runner polls Codefresh every three seconds by default to automatically create all resources needed for running pipelines.
+To see the cluster with the Runner:
+* In the Codefresh UI, click the **Settings** icon on the toolbar.
+* From the sidebar, select **Pipeline Runtimes**, and then click the **Codefresh Runners**(https://g.codefresh.io/account-admin/codefresh-runners){:target="\_blank"} tab.
{% include image.html
lightbox="true"
- file="/images/administration/runner/runtime-environments.png"
- url="/images/administration/runner/runtime-environments.png"
+ file="/images/runtime/runner/runtime-environments.png"
+ url="/images/runtime/runner/runtime-environments.png"
alt="Available runtime environments"
caption="Available runtime environments"
max-width="60%"
@@ -608,7 +608,9 @@ Once installed, the Runner polls Codefresh every three seconds by default to aut
If you have multiple runtime environments, select the one to use as the default environment for all the pipelines in the account.
-* From the list of [Runtime Environments](https://g.codefresh.io/account-admin/account-conf/runtime-environments){:target="\_blank"}, click the context menu of the runtime to set as the default.
+* In the Codefresh UI, click the **Settings** icon on the toolbar.
+* From the sidebar, select [**Pipeline Runtimes**](https://g.codefresh.io/account-admin/pipeline-runtimes){:target="\_blank"}.
+* From the list of Pipeline Runtimes, click the context menu of the runtime to set as the default.
* Select **Set as Default**.
@@ -618,8 +620,8 @@ Override the default runtime environment for a specific pipeline through the pip
{% include image.html
lightbox="true"
- file="/images/administration/runner/environment-per-pipeline.png"
- url="/images/administration/runner/environment-per-pipeline.png"
+ file="/images/runtime/runner/environment-per-pipeline.png"
+ url="/images/runtime/runner/environment-per-pipeline.png"
alt="Running a pipeline on a specific environment"
caption="Running a pipeline on a specific environment"
max-width="60%"
@@ -807,21 +809,21 @@ Override environment variables for `dind-lv-monitor` daemonset if necessary:
{% include image.html
lightbox="true"
- file="/images/administration/runner/codefresh_runner.png"
- url="/images/administration/runner/codefresh_runner.png"
+ file="/images/runtime/runner/codefresh_runner.png"
+ url="/images/runtime/runner/codefresh_runner.png"
alt="Codefresh Runner architecture overview"
caption="Codefresh Runner architecture overview"
max-width="100%"
%}
-1. [Runtime-Environment specification]({{site.baseurl}}/docs/administration/codefresh-runner/#runtime-environment-specification) defines engine and dind pods spec and PVC parameters.
+1. [Runtime-Environment specification](#runtime-environment-specification) defines engine and dind pods spec and PVC parameters.
2. Runner pod (Agent) pulls tasks (Builds) from Codefresh API every 3 seconds.
3. Once the agent receives build task (either Manual run build or Webhook triggered build) it calls k8s API to create engine/dind pods and PVC object.
4. Volume Provisioner listens for PVC events (create) and based on StorageClass definition it creates PV object with the corresponding underlying volume backend (ebs/gcedisk/local).
5. During the build, each step (clone/build/push/freestyle/composition) is represented as docker container inside dind (docker-in-docker) pod. Shared Volume (`/codefresh/volume`) is represented as docker volume and mounted to every step (docker containers). PV mount point inside dind pod is `/var/lib/docker`.
6. Engine pod controls dind pod. It deserializes pipeline yaml to docker API calls, terminates dind after build has been finished or per user request (sigterm).
-7. `dind-lv-monitor` DaemonSet OR `dind-volume-cleanup` CronJob are part of [runtime cleaners](#types-of-runtime-cleaners), `app-proxy` Deployment and Ingress are described in the [App-Proxy installation](#app-proxy-installation), `monitor` Deployment is for [Kubernetes Dashboard]({{site.baseurl}}/docs/deploy-to-kubernetes/manage-kubernetes/).
+7. `dind-lv-monitor` DaemonSet OR `dind-volume-cleanup` CronJob are part of [runtime cleaners](#types-of-runtime-cleaners), `app-proxy` Deployment and Ingress are described in the [App-Proxy installation](#app-proxy-installation), `monitor` Deployment is for [Kubernetes Dashboard]({{site.baseurl}}/docs/deployments/kubernetes/manage-kubernetes/).
## Customized Codefresh Runner installations
@@ -870,8 +872,8 @@ Here is the architecture of the App-Proxy:
{% include image.html
lightbox="true"
- file="/images/administration/runner/app-proxy-architecture.png"
- url="/images/administration/runner/app-proxy-architecture.png"
+ file="/images/runtime/runner/app-proxy-architecture.png"
+ url="/images/runtime/runner/app-proxy-architecture.png"
alt="How App Proxy and the Codefresh runner work together"
caption="How App Proxy and the Codefresh runner work together"
max-width="80%"
@@ -1294,7 +1296,7 @@ https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md#h
**How to**
-* Make sure target the correct cluster:
+* Make sure to target the correct cluster:
```shell
$ kubectl config current-context
@@ -1395,11 +1397,12 @@ You have completed installing the Codefresh Runner on an EKS cluster. You can tr
### Install Codefresh Runner on Rancher RKE 2.X
Installing Codefresh Runner on Rancher RKE 2.X includes these steps:
-[Step 1: Configure kubelet for Runner StorageClass](#step-1-configure-kubelet-for-runner-storageclass)
-[Step 2: Set kubeconfig user permissions](#step-2-set-kubeconfig-user-permissions)
-[Step 3: Install the Runner](#step-3-install-the-runner)
-[Step 4: Update Runner Docker MTU](#step-4-update-runner-docker-mtu)
-[Step 5: Create the cluster integration](#step-5-create-the-cluster-integration)
+
+* [Step 1: Configure kubelet for Runner StorageClass](#step-1-configure-kubelet-for-runner-storageclass)
+* [Step 2: Set kubeconfig user permissions](#step-2-set-kubeconfig-user-permissions)
+* [Step 3: Install the Runner](#step-3-install-the-runner)
+* [Step 4: Update Runner Docker MTU](#step-4-update-runner-docker-mtu)
+* [Step 5: Create the cluster integration](#step-5-create-the-cluster-integration)
#### Step 1: Configure kubelet for Runner StorageClass
@@ -1410,8 +1413,8 @@ Configure the cluster to allow the Runner's default `StorageClass` to create the
{% include image.html
lightbox="true"
- file="/images/administration/runner/rancher-cluster.png"
- url="/images/administration/runner/rancher-cluster.png"
+ file="/images/runtime/runner/rancher-cluster.png"
+ url="/images/runtime/runner/rancher-cluster.png"
alt="Drill into your cluster and click Edit Cluster on the right"
caption="Drill into your cluster and click Edit Cluster on the right"
max-width="100%"
@@ -1421,8 +1424,8 @@ Configure the cluster to allow the Runner's default `StorageClass` to create the
{% include image.html
lightbox="true"
- file="/images/administration/runner/rancher-cluster-2.png"
- url="/images/administration/runner/rancher-cluster-2.png"
+ file="/images/runtime/runner/rancher-cluster-2.png"
+ url="/images/runtime/runner/rancher-cluster-2.png"
alt="Click Edit Cluster on the right in your cluster list"
caption="Click Edit Cluster on the right in your cluster list"
max-width="100%"
@@ -1433,8 +1436,8 @@ Configure the cluster to allow the Runner's default `StorageClass` to create the
{% include image.html
lightbox="true"
- file="/images/administration/runner/rancher-edit-as-yaml.png"
- url="/images/administration/runner/rancher-edit-as-yaml.png"
+ file="/images/runtime/runner/rancher-edit-as-yaml.png"
+ url="/images/runtime/runner/rancher-edit-as-yaml.png"
alt="Cluster Options -> Edit as YAML"
caption="Cluster Options -> Edit as YAML"
max-width="100%"
@@ -1455,8 +1458,8 @@ rancher_kubernetes_engine_config:
{% include image.html
lightbox="true"
- file="/images/administration/runner/rancher-kublet.png"
- url="/images/administration/runner/rancher-kublet.png"
+ file="/images/runtime/runner/rancher-kublet.png"
+ url="/images/runtime/runner/rancher-kublet.png"
alt="Add volume to rancher_kubernetes_engine_config.services.kublet.extra_binds"
caption="Add volume to rancher_kubernetes_engine_config.services.kublet.extra_binds"
max-width="100%"
@@ -1487,7 +1490,7 @@ There are two options to create a user:
* Copy the Bearer Token field (combines Access Key and Secret Key).
* Edit your `kubeconfig` and paste the Bearer Token you copied in the `token` field of your user.
- {% include image.html lightbox="true" file="/images/administration/runner/rancher-security.png" url="/images/administration/runner/rancher-security.png" alt="Create a cluster admin user for Codefresh" caption="Create a cluster admin user for Codefresh" max-width="100%" %}
+ {% include image.html lightbox="true" file="/images/runtime/runner/rancher-security.png" url="/images/runtime/runner/rancher-security.png" alt="Create a cluster admin user for Codefresh" caption="Create a cluster admin user for Codefresh" max-width="100%" %}
#### Step 3: Install the Runner
@@ -1536,8 +1539,8 @@ kubectl edit cm codefresh-dind-config -n codefresh
{% include image.html
lightbox="true"
- file="/images/administration/runner/rancher-mtu.png"
- url="/images/administration/runner/rancher-mtu.png"
+ file="/images/runtime/runner/rancher-mtu.png"
+ url="/images/runtime/runner/rancher-mtu.png"
alt="Update the runner's Docker MTU"
caption="Update the runner's Docker MTU"
max-width="100%"
@@ -1665,7 +1668,7 @@ You can [monitor the runner](#using-the-codefresh-runner).
### Install monitoring component
-If your cluster is located [behind the firewall]({{site.baseurl}}/docs/administration/behind-the-firewall/), you can use the Runner's monitoring component to get valuable information about cluster resources to Codefresh dashboards. For example, to [Kubernetes](https://g.codefresh.io/kubernetes/services/){:target="\_blank"} and [Helm Releases](https://g.codefresh.io/helm/releases/releasesNew/){:target="\_blank"} dashboards.
+If your cluster is located [behind the firewall]({{site.baseurl}}/docs/installation/behind-the-firewall/), you can use the Runner's monitoring component to get valuable information about cluster resources to Codefresh dashboards. For example, to [Kubernetes](https://g.codefresh.io/kubernetes/services/){:target="\_blank"} and [Helm Releases](https://g.codefresh.io/helm/releases/releasesNew/){:target="\_blank"} dashboards.
You can install the monitoring component during Runner installation with cluster integration, or after Runner installation without cluster integration.
@@ -1769,7 +1772,7 @@ RunAwsCli:
## Runtime environment specification
The following section describes the runtime environment specification and possible options to modify it.
-Notice that there are additional and hidden fields that are autogenerated by Codefresh that complete a full runtime spec. You can view and edit these fields only for [Codefresh On-Premises Installation]({{site.baseurl}}/docs/administration/codefresh-on-prem/).
+Notice that there are additional and hidden fields that are autogenerated by Codefresh that complete a full runtime spec. You can view and edit these fields only for [Codefresh On-Premises Installation]({{site.baseurl}}/docs/installation/codefresh-on-prem/).
### Modify runtime
1. Get a list of all available runtimes:
@@ -1849,14 +1852,14 @@ accountId: 5f048d85eb107d52b16c53ea
| `imagePullPolicy` | string | Override image pull policy (default `IfNotPresent`) |
| `type` | string | `KubernetesPod` |
| `envVars` | object | Override or add environment variables passed into the engine pod |
-| `userEnvVars` | object | Add external env var(s) to the pipeline. See [Custom Global Environment Variables]({{site.baseurl}}/docs/administration/codefresh-runner/#custom-global-environment-variables) |
+| `userEnvVars` | object | Add external env var(s) to the pipeline. See [Custom Global Environment Variables](#custom-global-environment-variables) |
| `cluster` | object | k8s related information (`namespace`, `serviceAccount`, `nodeSelector`) |
| `resources` | object | Specify non-default `requests` and `limits` for engine pod |
| `tolerations` | array | Add tolerations to engine pod |
| `annotations` | object | Add custom annotations to engine pod (empty by default `{}`) |
| `labels` | object | Add custom labels to engine pod (empty by default `{}`) |
-| `dnsPolicy` | string | Engine pod's [DNS policy](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#pod-s-dns-policy) |
-| `dnsConfig` | object | Engine pod's [DNS config](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#pod-dns-config) |
+| `dnsPolicy` | string | Engine pod's [DNS policy](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#pod-s-dns-policy){:target="\_blank"} |
+| `dnsConfig` | object | Engine pod's [DNS config](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#pod-dns-config){:target="\_blank"} |
`runtimeScheduler` example:
{% highlight yaml %}
@@ -1905,16 +1908,16 @@ runtimeScheduler:
| -------------- |-------------------------| -------------------------|
| `dindImage` | string | Override default dind image |
| `type` | string | `DindPodPvc` |
-| `envVars` | object | Override or add environment variables passed into the dind pod. See [IN-DIND cleaner]({{site.baseurl}}/docs/administration/codefresh-runner/#cleaners) |
-| `userVolumeMounts` with `userVolumes` | object | Add volume mounts to the pipeline See [Custom Volume Mounts]({{site.baseurl}}/docs/administration/codefresh-runner/#custom-volume-mounts) |
+| `envVars` | object | Override or add environment variables passed into the dind pod. See [IN-DIND cleaner](https://github.com/codefresh-io/dind/tree/master/cleaner){:target="\_blank"} |
+| `userVolumeMounts` with `userVolumes` | object | Add volume mounts to the pipeline See [Custom Volume Mounts](#custom-volume-mounts) |
| `cluster` | object | k8s related information (`namespace`, `serviceAccount`, `nodeSelector`) |
| `defaultDindResources` | object | Override `requests` and `limits` for dind pod (defaults are `cpu: 400m` and `memory:800Mi` ) |
| `tolerations` | array | Add tolerations to dind pod |
| `annotations` | object | Add custom annotations to dind pod (empty by default `{}`) |
| `labels` | object | Add custom labels to dind pod (empty by default `{}`) |
-| `pvc` | object | Override default storage configuration for PersistentVolumeClaim (PVC) with `storageClassName`, `volumeSize`, `reuseVolumeSelector`. See [Volume Reusage Policy]({{site.baseurl}}/docs/administration/codefresh-runner/#volume-reusage-policy) |
-| `dnsPolicy` | string | Dind pod's [DNS policy](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#pod-s-dns-policy) |
-| `dnsConfig` | object | Dind pod's [DNS config](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#pod-dns-config) |
+| `pvc` | object | Override default storage configuration for PersistentVolumeClaim (PVC) with `storageClassName`, `volumeSize`, `reuseVolumeSelector`. See [Volume reuse policy](#volume-reuse-policy) |
+| `dnsPolicy` | string | Dind pod's [DNS policy](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#pod-s-dns-policy){:target="\_blank"} |
+| `dnsConfig` | object | Dind pod's [DNS config](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#pod-dns-config){:target="\_blank"} |
`dockerDaemonScheduler` example:
{% highlight yaml %}
@@ -2006,7 +2009,7 @@ dockerDaemonScheduler:
### Debug timeout duration
-The default timeout for [debug mode]({{site.baseurl}}/docs/configure-ci-cd-pipeline/debugging-pipelines/) is 14 minutes, even if the user is actively working.
+The default timeout for [debug mode]({{site.baseurl}}/docs/pipelines/debugging-pipelines/) is 14 minutes, even if the user is actively working.
To change the duration of the debugger for a runtime, you must update the Runtime Spec of that runtime with the `DEBUGGER_TIMEOUT` to the environment variable. The timeout is defined in minutes, so '30' corresponds to 30 minutes.
* Under `.runtimeScheduler`, add an `envVars` section
@@ -2099,7 +2102,7 @@ kubectl label nodes arch=arm
**Step 2: Runner installation**
-* Use [values.yaml](https://github.com/codefresh-io/venona/blob/release-1.0/venonactl/example/values-example.yaml) to inject `tolerations`, `kube-node-selector`, `build-node-selector` into the Runtime Environment spec.
+* Use [values.yaml](https://github.com/codefresh-io/venona/blob/release-1.0/venonactl/example/values-example.yaml){:target="\_blank"} to inject `tolerations`, `kube-node-selector`, `build-node-selector` into the Runtime Environment spec.
`values-arm.yaml`
@@ -2214,10 +2217,10 @@ codefresh runner delete --help
## Troubleshooting
-For troubleshooting refer to the [Knowledge Base](https://support.codefresh.io/hc/en-us/sections/4416999487762-Hybrid-Runner)
+For troubleshooting refer to the [Knowledge Base](https://support.codefresh.io/hc/en-us/sections/4416999487762-Hybrid-Runner){:target="\_blank"}
-## What to read next
+## Related articles
+[Codefresh installation options]({{site.baseurl}}/docs/installation/installation-options/)
+[Codefresh On-Premises installation]({{site.baseurl}}/docs/installation/codefresh-on-prem/)
+[Codefresh API]({{site.baseurl}}/docs/integrations/codefresh-api/)
-* [Codefresh installation options]({{site.baseurl}}/docs/administration/installation-security/)
-* [Codefresh On-Premises]({{site.baseurl}}/docs/administration/codefresh-on-prem/)
-* [Codefresh API]({{site.baseurl}}/docs/integrations/codefresh-api/)
diff --git a/_docs/installation/gitops.md b/_docs/installation/gitops.md
new file mode 100644
index 000000000..a49fb87df
--- /dev/null
+++ b/_docs/installation/gitops.md
@@ -0,0 +1,14 @@
+---
+title: "GitOps installation"
+description: "Use GitOps with Codefresh"
+group: installation
+toc: true
+---
+
+Codefresh has several modes for working with GitOps applications
+
+* The easiest way to get started is to use [a hosted GitOps runtime]({{site.baseurl}}/docs/installation/gitops/hosted-runtime/)
+* You can install [your own GitOps runtime]({{site.baseurl}}/docs/installation/gitops/hybrid-gitops/). in your own cluster
+* You can add [external clusters]({{site.baseurl}}/docs/installation/gitops/managed-cluster/) to any runtime (hosted or private)
+
+.
\ No newline at end of file
diff --git a/_docs/installation/gitops/git-sources.md b/_docs/installation/gitops/git-sources.md
new file mode 100644
index 000000000..42ed0c2d3
--- /dev/null
+++ b/_docs/installation/gitops/git-sources.md
@@ -0,0 +1,101 @@
+---
+title: "Add Git Sources to GitOps Runtimes"
+description: "Manage Git Sources storing resources"
+group: installation
+toc: true
+---
+
+
+A Git Source is the equivalent of an Argo CD application that tracks a Git repository and syncs the desired state of the repo to the destination K8s cluster. In addition to application resources, the Git Source can store resources for GitOps Runtimes, and CI/CD entities such as delivery pipelines, Workflow Templates, workflows, and applications.
+
+Provisioning a GitOps Runtime automatically creates a Git Source that stores resources for the Runtime and for the demo CI pipelines that are optionally installed with the Runtime. Every Git Source is associated with a GitOps Runtime. You can add more Git Sources at any time, to the same or to different Runtimes.
+
+Once you create a Git Source for a GitOps Runtime, you can store resources for CI/CD entities associated with it. For example, when creating pipelines or applications, you can select the Git Source to which to store manifest definitions.
+
+
+## View Git Sources and definitions
+Drill down on a runtime in List View to see its Git Sources.
+
+1. In the Codefresh UI, go to the [GitOps Runtimes](https://g.codefresh.io/2.0/account-settings/runtimes){:target="\_blank"} page.
+1. From the **List View** (the default), select a Runtime name, and then select the **Git Sources** tab.
+
+ {% include
+ image.html
+ lightbox="true"
+ file="/images/runtime/git-source-list.png"
+ url="/images/runtime/git-source-list.png"
+ alt="Git Sources in runtime"
+ caption="Git Sources in runtime"
+ max-width="60%"
+%}
+
+{:start="3"}
+1. To go to the repo tracked by the Git Source, in the Repo column, mouse over the repo name and select **Go to Git repo**.
+1. To see the definitions for the Git Source, select the three dots at the end of the row.
+
+## Create a Git Source
+Create Git Sources for any provisioned Runtime. The Git Sources are available to store resources for pipelines or applications when you create them.
+
+>Make sure you are in the List View to create Git Sources.
+
+1. In the Codefresh UI, on the toolbar, click the **Settings** icon.
+1. From Runtimes in the sidebar, select [GitOps Runtimes](https://g.codefresh.io/2.0/account-settings/runtimes**){:target="\_blank"}.
+1. In the List View, select the Runtime for which to add a Git Source, and then click the **Git Sources** tab.
+1. Click **Create Git Sources**, and in the Create Git Source panel, define the definitions for the Git Source:
+
+ {% include
+ image.html
+ lightbox="true"
+ file="/images/runtime/create-git-source.png"
+ url="/images/runtime/create-git-source.png"
+ alt="Create Git Source"
+ caption="Create Git Source"
+ max-width="60%"
+%}
+
+ * **Git Source Name**: The name of the Git Source, which must be unique within the cluster.
+ * **Source**: The Git repo with the desired state, tracked by the Git Source, and synced to the destination cluster.
+ * **Repository**: Mandatory. The URL to the Git repo.
+ * **Branch**: Optional. The specific branch within the repo to track.
+ * **Path**: Optional. The specific path within the repo, and branch if one is specified, to track.
+ * **Destination**: The destination cluster with the actual state to which to apply the changes from the **Source**.
+ * **Namespace**: The namespace in the destination cluster to which to sync the changes.
+
+ * **Include Files** and **Exclude Files**: The file or files to include or exclude from the Git repo when syncing to the destination cluster.
+ Use GLOB to define patterns using wildcards to match path names in the source Git repo.
+ For example, `workflows/**/*.yaml`, in the Include Files field would include all files in the `workflows` directory and all its child directories, with `.yaml` as the extension.
+ `**/images/**/*` in the Exclude Files field, would ignore all directories entitled `images`.
+ For GLOB guidelines and examples, see this [article](https://deepsource.io/blog/glob-file-patterns/){:target="\_blank"}.
+
+{:start="4"}
+1. Click **+ Create Git Source**.
+
+## Edit Git Source definitions
+Edit an existing Git Source by changing the source and destination definitions, and included/excluded files.
+> You cannot change the name of the Git Source.
+
+1. In the Codefresh UI, on the toolbar, click the **Settings** icon.
+1. From Runtimes in the sidebar, select [GitOps Runtimes](https://g.codefresh.io/2.0/account-settings/runtimes**){:target="\_blank"}.
+1. From the **List View** (the default), select the Runtime with the Git Source, and then select the **Git Sources** tab.
+1. In the row with the Git Source to edit, from the context menu select **Details**.
+1. In the panel that appears, click **Edit**.
+
+{% include
+ image.html
+ lightbox="true"
+ file="/images/runtime/edit-git-source.png"
+ url="/images/runtime/edit-git-source.png"
+ alt="Edit Git Source"
+ caption="Edit Git Source"
+ max-width="30%"
+%}
+{:start="4"}
+1. Update **Source**, **Destination**, and **Include** and **Exclude** definitions for the Git Source, and select **Save**.
+
+
+
+## Related articles
+[Monitoring & managing GitOps Runtimes]({{site.baseurl}}/docs/installation/gitops/monitor-manage-runtimes/)
+[Shared configuration repo]({{site.baseurl}}/docs/reference/shared-configuration)
+
+
diff --git a/_docs/installation/gitops/hosted-runtime.md b/_docs/installation/gitops/hosted-runtime.md
new file mode 100644
index 000000000..e8bd8c042
--- /dev/null
+++ b/_docs/installation/gitops/hosted-runtime.md
@@ -0,0 +1,324 @@
+---
+title: "Hosted GitOps Runtime setup"
+description: "Provision Hosted GitOps environment"
+group: installation
+sub_group: gitops
+toc: true
+---
+
+
+
+Set up your environment with the Hosted GitOps Runtime to leverage Codefresh GitOps capabilities.
+
+
+## System requirements for Hosted GitOps Runtimes
+
+{: .table .table-bordered .table-hover}
+| Item | Requirement |
+| -------------- | -------------- |
+|Kubernetes cluster | Server version 1.18 and higher to which to deploy applications|
+|Git provider | {::nomarkdown}
GitHub
Bitbucket Cloud
{:/}|
+
+
+## Where to start with Hosted GitOps Runtimes
+If you have not provisioned a Hosted GitOps Runtime, Codefresh presents you with the setup instructions in the **GitOps Overview** dashboard.
+
+
+
+* In the Codefresh UI, from OPS in the sidebar, select [GitOps Overview](https://g.codefresh.io/2.0/?time=LAST_7_DAYS){:target="\_blank"}.
+ Codefresh guides you through the three-step setup, as described below.
+
+{% include
+image.html
+lightbox="true"
+file="/images/runtime/hosted-gitops-initial-view.png"
+url="/images/runtime/hosted-gitops-initial-view.png"
+alt="Hosted GitOps Runtime setup"
+caption="Hosted GitOps Runtime setup"
+max-width="80%"
+%}
+
+ >You can provision a single Hosted GitOps Runtime per Codefresh account.
+
+
+
+## Step 1: Install Hosted GitOps Runtime
+Start installing the Hosted GitOps Runtime with a single-click. Codefresh completes the installation without any further intervention on your part.
+The Hosted GitOps Runtime is provisioned on the Codefresh cluster, and completely managed by Codefresh with automatic version and security upgrades.
+
+
+
+1. Do one of the following:
+ * To set up Hosted GitOps Runtime later, click **Install later**, and continue from step _2_.
+ * To start setup, click **Install**, and continue from step _3_.
+
+{% include
+image.html
+lightbox="true"
+file="/images/runtime/hosted-installing.png"
+url="/images/runtime/hosted-installing.png"
+alt="Step 1: Installing Hosted GitOps Runtime"
+caption="Step 1: Installing Hosted GitOps Runtime"
+max-width="80%"
+%}
+
+{:start="2"}
+1. Do the following:
+ * In the Codefresh UI, click the **Settings** icon on the toolbar.
+ * From Runtimes in the sidebar, select [**GitOps Runtimes**](https://g.codefresh.io/2.0/account-settings/runtimes){:target="\_blank"}, and click **+ Add Runtime**.
+ * Select **Hosted Runtime** and click **Add**.
+ >An account can be provisioned with a single Hosted GitOps Runtime. If you have already provisioned a Hosted GitOps Runtime for your account, the Hosted GitOps Runtime option is disabled.
+ * Continue from _step 3_.
+
+{:start="3"}
+1. When complete, to view the components for the Hosted GitOps Runtime, click **View Runtime**.
+ You are directed to the Runtime Components tab.
+
+{% include
+image.html
+lightbox="true"
+file="/images/runtime/hosted-runtime-components.png"
+url="/images/runtime/hosted-runtime-components.png"
+alt="Runtime components for Hosted GitOps Runtime"
+caption="Runtime components for Hosted GitOps Runtime"
+max-width="70%"
+%}
+
+> You can see that there are two steps to complete Hosted GitOps setup.
+ The Git Sources and the Managed Clusters are empty as they will be set up in the next steps.
+
+If you navigate to **Runtimes > List View**, you can identify the Hosted GitOps Runtime through the Type column (Hosted), the Cluster/Namespace column (Codefresh), and the Module column (CD Ops).
+
+{% include
+image.html
+lightbox="true"
+file="/images/runtime/hosted-runtimes-list-view.png"
+url="/images/runtime/hosted-runtimes-list-view.png"
+alt="Hosted GitOps Runtime in List view"
+caption="Hosted GitOps Runtime in List view"
+max-width="70%"
+%}
+
+
+## Step 2: Connect Git provider
+Connect your Hosted GitOps Runtime to a Git provider for Codefresh to create the required Git repos. First authorize access to your Git provider through an OAuth token, and then select the Git organizations or accounts in which to create the required Git repos.
+
+>Only authorized organizations are displayed in the list. To authorize organizations for the Codefresh application in GitHub, see [Authorize organizations/projects]({{site.baseurl}}/docs/administration/account-user-management/hosted-authorize-orgs/).
+
+
+{% include
+image.html
+lightbox="true"
+file="/images/runtime/hosted-connect-git.png"
+url="/images/runtime/hosted-connect-git.png"
+alt="Step 2: Connect to Git provider"
+caption="Step 2: Connect to Git provider"
+max-width="80%"
+%}
+
+
+Once you authorize access, Codefresh creates two Git repositories, one to store the runtime configuration settings, and the other to store the runtime's application settings:
+* Shared runtime configuration repo
+
+ The shared runtime configuration repo is a centralized Git repository that stores configuration settings for the Hosted GitOps Runtime. Additional runtimes provisioned for the account can point to this repo to retrieve and reuse the configuration.
+ Read about [Shared configuration repo]({{site.baseurl}}/docs/reference/shared-configuration/).
+
+* Git Source application repo
+
+ Codefresh creates a Git Source application repo for every Hosted GitOps Runtime.
+ Read about [Git sources]({{site.baseurl}}/docs/installation/gitops/git-sources/).
+
+
+>Hosted runtimes support only OAuth authentication.
+
+1. Click **Connect**.
+1. Click **Authorize Access**, and enter your OAuth token.
+ If you don't have an OAuth token, see the instructions on how to generate one in [How to update a Git token]({{site.baseurl}}/docs/administration/user-settings/#how-to-update-a-git-personal-token).
+
+{% include
+image.html
+lightbox="true"
+file="/images/runtime/hosted-authorize-access.png"
+url="/images/runtime/hosted-authorize-access.png"
+alt="Authorize access to Git"
+caption="Authorize access to Git"
+max-width="40%"
+%}
+
+{:start="3"}
+1. Select the **Git Organization for which to create the repos**.
+ >If the organization does not appear in the list, you need to authorize access to it. See [Authorize organizations/projects]({{site.baseurl}}/docs/administration/account-user-management/hosted-authorize-orgs/).
+1. Click **Create**.
+ Codefresh creates the two Git repositories in the paths shown.
+
+ {% include
+image.html
+lightbox="true"
+file="/images/runtime/hosted-select-git-repo.png"
+url="/images/runtime/hosted-select-git-repo.png"
+alt="Git configuration repos for Git Organization"
+caption="Git configuration repos for Git Organization"
+max-width="50%"
+%}
+
+{:start="5"}
+1. Verify that both repositories have been created in your Git account.
+
+ Shared runtime configuration repo
+
+ {% include
+image.html
+lightbox="true"
+file="/images/runtime/hosted-git-shared-repo.png"
+url="/images/runtime/hosted-git-shared-repo.png"
+alt="Shared configuration repo in Git"
+caption="Shared configuration repo in Git"
+max-width="70%"
+%}
+
+ Runtime Git Source repo
+
+{% include
+image.html
+lightbox="true"
+file="/images/runtime/hosted-git-shared-repo.png"
+url="/images/runtime/hosted-git-shared-repo.png"
+alt="Shared configuration repo in Git"
+caption="Shared configuration repo in Git"
+max-width="70%"
+%}
+
+{:start="6"}
+1. Optional. To see your tokens, click **View Tokens**.
+
+If you return to the Runtimes page and select the Git Source tab, you will now see the Git Source that Codefresh created.
+The Sync State may be Unknown for a few moments until it is synced to the Codefresh cluster.
+
+{% include
+image.html
+lightbox="true"
+file="/images/runtime/hosted-git-source-in-ui.png"
+url="/images/runtime/hosted-git-source-in-ui.png"
+alt="Git Source tab for Hosted GitOps Runtime"
+caption="Git Source tab for Hosted GitOps Runtime"
+max-width="80%"
+%}
+
+
+## 3. Connect a Kubernetes cluster
+
+Connect a destination cluster to the Hosted GitOps Runtime and register it as a managed cluster. Deploy applications and configuration to the cluster.
+For managed cluster information and installing Argo Rollouts, see [Add and manage external clusters]({{site.baseurl}}/docs/installation/gitops/managed-cluster/).
+
+
+ {% include
+image.html
+lightbox="true"
+file="/images/runtime/hosted-connect-cluster-step.png"
+url="/images/runtime/hosted-connect-cluster-step.png"
+alt="Step 3: Connect a K8s cluster for Hosted GitOps Runtime"
+caption="Step 3: Connect a K8s cluster for Hosted GitOps Runtime"
+max-width="70%"
+%}
+
+**Before you begin**
+* Make sure your cluster has internet access
+
+**How to**
+1. Click **Connect**.
+1. In the Add Managed Cluster panel, copy the command `cf cluster add`, and run it in the terminal.
+1. When prompted to select the `kube-context`, select from the list of available clusters as defined in `kubeconfig`.
+
+ {% include
+ image.html
+ lightbox="true"
+ file="/images/runtime/hosted-add-cluster.png"
+ url="/images/runtime/hosted-add-cluster.png"
+ alt="Add Managed Cluster panel"
+ caption="Add Managed Cluster panel"
+ max-width="50%"
+ %}
+
+{:start="4"}
+1. Return to the **Runtimes** page, and then select **Topology View**.
+ You can see the new K8s cluster you connected.
+
+ {% include
+ image.html
+ lightbox="true"
+ file="/images/runtime/hosted-new-cluster-topology.png"
+ url="/images/runtime/hosted-new-cluster-topology.png"
+ alt="New K8s cluster in Hosted GitOps Runtime"
+ caption="New K8s cluster in Hosted GitOps Runtime"
+ max-width="80%"
+ %}
+
+{:start="5"}
+1. Configure access to the IP addresses required. See [Codefresh IP addresses]({{site.baseurl}}/docs/administration/platform-ip-addresses/).
+
+If you could not connect a cluster, you may not have the latest version of the CLI:
+[Upgrade the GitOps CLI]({{site.baseurl}}/docs/installation/gitops/upgrade-gitops-cli/).
+
+You have completed setting up your Hosted GitOps Runtime. You are ready to create applications, and connect third-party CI tools for image enrichment.
+
+### (Optional) Create application
+Optional. Create an application in Codefresh, deploy it to the cluster, and track deployment and performance in the Applications dashboard.
+
+1. Follow our quick-start to create and deploy the `codefresh-guestbook` application. Start with [Create application resources]({{site.baseurl}}/docs/quick-start/gitops-quick-start/create-app-specs/).
+ OR
+ Create your own application. See [Create an application]({{site.baseurl}}/docs/deployments/gitops/create-application/)
+
+{:start="2"}
+2. In the Codefresh UI, view your application in the [Applications dashboard]((https://g.codefresh.io/2.0/applications-dashboard/list){:target="\_blank"}.
+
+### (Optional) Connect CI
+Optional. Integrate Codefresh with the third-party tools you use for CI to enrich image information in deployments.
+
+[Image enrichment with integrations]({{site.baseurl}}/docs/gitops-integrations/image-enrichment-overview/)
+
+## Related articles
+[Monitoring & managing GitOps Runtimes]({{site.baseurl}}/docs/installation/gitops/monitor-manage-runtimes/)
+[Add Git Sources to runtimes]({{site.baseurl}}/docs/installation/gitops/git-sources/)
+[Shared configuration repo]({{site.baseurl}}/docs/reference/shared-configuration)
+[GitOps Overview dashboard]({{site.baseurl}}/docs/dashboards/home-dashboard/)
+[DORA metrics]({{site.baseurl}}/docs/dashboards/dora-metrics/)
+
diff --git a/_docs/installation/gitops/hybrid-gitops.md b/_docs/installation/gitops/hybrid-gitops.md
new file mode 100644
index 000000000..2d32696b3
--- /dev/null
+++ b/_docs/installation/gitops/hybrid-gitops.md
@@ -0,0 +1,1292 @@
+---
+title: "Hybrid GitOps Runtime installation"
+description: "Provision Hybrid GitOps Runtimes"
+group: installation
+sub_group: gitops
+toc: true
+---
+
+Provision one or more Hybrid GitOps Runtimes in your Codefresh account.
+Start by reviewing [system requirements](#minimum-system-requirements) for Hybrid GitOps.
+If you are installing with ingress-controllers, you must configure them as required _before_ starting the installation.
+
+> To provision a Hosted GitOps Runtime, see [Provision a hosted runtime]({{site.baseurl}}/docs/installation/gitops/hosted-runtime//#1-provision-hosted-runtime) in [Set up a hosted (Hosted GitOps) environment]({{site.baseurl}}/docs/installation/gitops/hosted-runtime/).
+
+**Git providers and Hybrid Runtimes**
+Your Codefresh account is always linked to a specific Git provider. This is the Git provider you select on installing the first GitOps Runtime, either Hybrid or Hosted, in your Codefresh account. All the Hybrid GitOps Runtimes you install in the same account use the same Git provider.
+If Bitbucker Server is your Git provider, you must also select the specific server instance to associate with the runtime.
+
+>To change the Git provider for your Codefresh account after installation, contact Codefresh support.
+
+
+**Codefresh and Argo CD s**
+ The Hybrid GitOps Runtime comprises Argo CD components and Codefresh-specific components.
+
+Codefresh users rely on our platform to deliver software reliably, and predictably without interruption.
+To maintain that high standard, we add several weeks of testing and bug fixes to new versions of Argo before making them available within Codefresh.
+Typically, new versions of Argo are available within 30 days of release in Argo.
+
+
+There are two parts to installing a Hybrid GitOps Runtime:
+
+1. [Installing the GitOps CLI](#gitops-cli-installation)
+2. [Installing the Hybrid GitOps Runtime](#install-hybrid-gitops-runtime), either through the CLI wizard or via silent installation through the installation flags.
+ The Hybrid GitOps Runtime is installed in a specific namespace on your cluster. You can install more Hybrid GitOps Runtimes on different clusters in your deployment.
+ Every Hybrid GitOps Runtime installation makes commits to three Git repos:
+ * Runtime install repo: The installation repo that manages the Hybrid Runtime itself with Argo CD. If the repo URL does not exist, it is automatically created during installation.
+ * Git Source repo: Created automatically during Runtime installation. The repo where you store manifests for pipelines and applications. See [Git Sources]({{site.baseurl}}/docs/installation/gitops/git-sources).
+ * Shared configuration repo: Created for the first GitOps Runtime installed in your account. The repo stores configuration manifests for account-level resources and is shared with other GitOps Runtimes in the same account. See [Shared configuration repository]({{site.baseurl}}/docs/reference/shared-configuration).
+
+
+
+{::nomarkdown}
+
+{:/}
+
+## Minimum system requirements
+
+{: .table .table-bordered .table-hover}
+| Item | Requirement |
+| -------------- | -------------- |
+|Kubernetes cluster | Server version 1.18 and higher, without Argo Project components. {::nomarkdown} Tip: To check the server version, run: kubectl version --short.{:/}|
+| Ingress controller| Configured on Kubernetes cluster and exposed from the cluster. {::nomarkdown} Supported and tested ingress controllers include:
GitHub and GitHub Enterprise: repo, admin-repo.hook
GitLab Cloud and GitLab Server: api, read_repository
Bitbucket Cloud and Server: Permissions: Read, Workspace membership: Read, Webhooks: Read and write, Repositories: Write, Admin
{:/}|
+
+## Ingress controller configuration
+
+You need to configure ingress controllers only if your runtime uses an ingress controller. Codefresh offers tunnel-based runtimes which do not require ingress controllers. See **Access Mode** in [Runtime flags](#runtime-flags) and [Tunnel-based runtime flags](#tunnel-based-runtime-flags).
+
+### Ambassador ingress configuration
+For detailed configuration information, see the [Ambassador ingress controller documentation](https://www.getambassador.io/docs/edge-stack/latest/topics/running/ingress-controller){:target="\_blank"}.
+
+This section lists the specific configuration requirements for Codefresh to be completed _before_ installing the hybrid runtime.
+* Valid external IP address
+* Valid TLS certificate
+* TCP support
+
+{::nomarkdown}
+
+{:/}
+
+#### Valid external IP address
+Run `kubectl get svc -A` to get a list of services and verify that the `EXTERNAL-IP` column for your ingress controller shows a valid hostname.
+ {::nomarkdown}
+
+{:/}
+
+#### Valid TLS certificate
+For secure runtime installation, the ingress controller must have a valid TLS certificate.
+> Use the FQDN (Fully Qualified Domain Name) of the ingress controller for the TLS certificate.
+
+{::nomarkdown}
+
+{:/}
+
+#### TCP support
+Configure the ingress controller to handle TCP requests.
+
+{::nomarkdown}
+
+{:/}
+
+### AWS ALB ingress configuration
+
+For detailed configuration information, see the [ALB AWS ingress controller documentation](https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.4){:target="\_blank"}.
+
+This table lists the specific configuration requirements for Codefresh.
+
+{: .table .table-bordered .table-hover}
+| What to configure | When to configure |
+| -------------- | -------------- |
+|Valid external IP address | _Before_ installing hybrid runtime |
+|Valid TLS certificate | |
+|TCP support| |
+|Controller configuration] | |
+|Alias DNS record in route53 to load balancer | _After_ installing hybrid runtime |
+|(Optional) Git integration registration | |
+
+{::nomarkdown}
+
+{:/}
+
+#### Valid external IP address
+Run `kubectl get svc -A` to get a list of services and verify that the `EXTERNAL-IP` column for your ingress controller shows a valid hostname.
+
+{::nomarkdown}
+
+{:/}
+
+#### Valid TLS certificate
+For secure runtime installation, the ingress controller must have a valid TLS certificate.
+> Use the FQDN (Fully Qualified Domain Name) of the ingress controller for the TLS certificate.
+
+{::nomarkdown}
+
+{:/}
+
+#### TCP support
+Configure the ingress controller to handle TCP requests.
+
+{::nomarkdown}
+
+{:/}
+
+#### Controller configuration
+In the ingress resource file, verify that `spec.controller` is configured as `ingress.k8s.aws/alb`.
+
+```yaml
+apiVersion: networking.k8s.io/v1
+kind: IngressClass
+metadata:
+ name: alb
+spec:
+ controller: ingress.k8s.aws/alb
+```
+
+{::nomarkdown}
+
+{:/}
+
+#### Create an alias to load balancer in route53
+
+> The alias must be configured _after_ installing the hybrid runtime.
+
+1. Make sure a DNS record is available in the correct hosted zone.
+1. _After_ hybrid runtime installation, in Amazon Route 53, create an alias to route traffic to the load balancer that is automatically created during the installation:
+ * **Record name**: Enter the same record name used in the installation.
+ * Toggle **Alias** to **ON**.
+ * From the **Route traffic to** list, select **Alias to Application and Classic Load Balancer**.
+ * From the list of Regions, select the region. For example, **US East**.
+ * From the list of load balancers, select the load balancer that was created during installation.
+
+For more information, see [Creating records by using the Amazon Route 53 console](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-creating.html){:target="\_blank"}.
+
+{% include image.html
+ lightbox="true"
+ file="/images/runtime/post-install-alb-ingress.png"
+ url="/images/runtime/post-install-alb-ingress.png"
+ alt="Route 53 record settings for AWS ALB"
+ caption="Route 53 record settings for AWS ALB"
+ max-width="60%"
+%}
+
+{::nomarkdown}
+
+{:/}
+
+#### (Optional) Git integration registration
+If the installation failed, as can happen if the DNS record was not created within the timeframe, manually create and register Git integrations using these commands:
+ `cf integration git add default --runtime --api-url `
+ `cf integration git register default --runtime --token `
+
+{::nomarkdown}
+
+{:/}
+
+### Istio ingress configuration
+For detailed configuration information, see [Istio ingress controller documentation](https://istio.io/latest/docs/tasks/traffic-management/ingress/kubernetes-ingress){:target="\_blank}.
+
+The table below lists the specific configuration requirements for Codefresh.
+
+{: .table .table-bordered .table-hover}
+| What to configure | When to configure |
+| -------------- | -------------- |
+|Valid external IP address |_Before_ installing hybrid runtime |
+|Valid TLS certificate| |
+|TCP support | |
+|Cluster routing service | _After_ installing hybrid runtime |
+
+{::nomarkdown}
+
+{:/}
+
+#### Valid external IP address
+Run `kubectl get svc -A` to get a list of services and verify that the `EXTERNAL-IP` column for your ingress controller shows a valid hostname.
+
+{::nomarkdown}
+
+{:/}
+
+#### Valid TLS certificate
+For secure runtime installation, the ingress controller must have a valid TLS certificate.
+> Use the FQDN (Fully Qualified Domain Name) of the ingress controller for the TLS certificate.
+
+{::nomarkdown}
+
+{:/}
+
+#### TCP support
+Configure the ingress controller to handle TCP requests.
+
+{::nomarkdown}
+
+{:/}
+
+
+
+#### Cluster routing service
+> The cluster routing service must be configured _after_ installing the hybrid runtime.
+
+Based on the runtime version, you need to configure a single or multiple `VirtualService` resources for the `app-proxy`, `webhook`, and `workflow` services.
+
+##### Runtime version 0.0.543 or higher
+Configure a single `VirtualService` resource to route traffic to the `app-proxy`, `webhook`, and `workflow` services, as in the example below.
+
+```yaml
+apiVersion: networking.istio.io/v1alpha3
+kind: VirtualService
+metadata:
+ namespace: pov-codefresh-istio-runtime # replace with your runtime name
+ name: internal-router
+spec:
+ hosts:
+ - pov-codefresh-istio-runtime.sales-dev.codefresh.io # replace with your host name
+ gateways:
+ - istio-system/internal-router # replace with your gateway name
+ http:
+ - match:
+ - uri:
+ prefix: /webhooks
+ route:
+ - destination:
+ host: internal-router
+ port:
+ number: 80
+ - match:
+ - uri:
+ prefix: /app-proxy
+ route:
+ - destination:
+ host: internal-router
+ port:
+ number: 80
+ - match:
+ - uri:
+ prefix: /workflows
+ route:
+ - destination:
+ host: internal-router
+ port:
+ number: 80
+```
+
+##### Runtime version 0.0.542 or lower
+
+Configure two different `VirtualService` resources, one to route traffic to the `app-proxy`, and the second to route traffic to the `webhook` services, as in the examples below.
+
+{::nomarkdown}
+
+{:/}
+
+**`VirtualService` example for `app-proxy`:**
+
+```yaml
+apiVersion: networking.istio.io/v1alpha3
+kind: VirtualService
+metadata:
+ namespace: test-runtime3 # replace with your runtime name
+ name: cap-app-proxy
+spec:
+ hosts:
+ - my.support.cf-cd.com # replace with your host name
+ gateways:
+ - my-gateway # replace with your host name
+ http:
+ - match:
+ - uri:
+ prefix: /app-proxy
+ route:
+ - destination:
+ host: cap-app-proxy
+ port:
+ number: 3017
+```
+
+**`VirtualService` example for `webhook`:**
+
+> Configure a `uri.prefix` and `destination.host` for each event-source if you have more than one.
+
+```yaml
+apiVersion: networking.istio.io/v1alpha3
+kind: VirtualService
+metadata:
+ namespace: test-runtime3 # replace with your runtime name
+ name: csdp-default-git-source
+spec:
+ hosts:
+ - my.support.cf-cd.com # replace with your host name
+ gateways:
+ - my-gateway # replace with your gateway name
+ http:
+ - match:
+ - uri:
+ prefix: /webhooks/test-runtime3/push-github # replace `test-runtime3` with your runtime name, and `push-github` with the name of your event source
+ route:
+ - destination:
+ host: push-github-eventsource-svc # replace `push-github' with the name of your event source
+ port:
+ number: 80
+ - match:
+ - uri:
+ prefix: /webhooks/test-runtime3/cypress-docker-images-push # replace `test-runtime3` with your runtime name, and `cypress-docker-images-push` with the name of your event source
+ route:
+ - destination:
+ host: cypress-docker-images-push-eventsource-svc # replace `cypress-docker-images-push` with the name of your event source
+ port:
+ number: 80
+```
+
+{::nomarkdown}
+
+{:/}
+
+### NGINX Enterprise ingress configuration
+
+For detailed configuration information, see [NGINX ingress controller documentation](https://docs.nginx.com/nginx-ingress-controller){:target="\_blank}.
+
+The table below lists the specific configuration requirements for Codefresh.
+
+{: .table .table-bordered .table-hover}
+| What to configure | When to configure |
+| -------------- | -------------- |
+|Verify valid external IP address |_Before_ installing hybrid runtime |
+|Valid TLS certificate | |
+|TCP support| |
+|NGINX Ingress: Enable report status to cluster | |
+|NGINX Ingress Operator: Enable report status to cluster| |
+|Patch certificate secret |_After_ installing hybrid runtime
+
+{::nomarkdown}
+
+{:/}
+
+#### Valid external IP address
+Run `kubectl get svc -A` to get a list of services and verify that the `EXTERNAL-IP` column for your ingress controller shows a valid hostname.
+
+{::nomarkdown}
+
+{:/}
+
+#### Valid TLS certificate
+For secure runtime installation, the ingress controller must have a valid TLS certificate.
+> Use the FQDN (Fully Qualified Domain Name) of the ingress controller for the TLS certificate.
+
+{::nomarkdown}
+
+{:/}
+
+#### TCP support
+Configure the ingress controller to handle TCP requests.
+
+{::nomarkdown}
+
+{:/}
+
+#### NGINX Ingress: Enable report status to cluster
+
+If the ingress controller is not configured to report its status to the cluster, Argo’s health check reports the health status as “progressing” resulting in a timeout error during installation.
+
+* Pass `--report-ingress-status` to `deployment`.
+
+```yaml
+spec:
+ containers:
+ - args:
+ - --report-ingress-status
+```
+
+{::nomarkdown}
+
+{:/}
+
+#### NGINX Ingress Operator: Enable report status to cluster
+
+If the ingress controller is not configured to report its status to the cluster, Argo’s health check reports the health status as “progressing” resulting in a timeout error during installation.
+
+1. Add this to the `Nginxingresscontrollers` resource file:
+
+ ```yaml
+ ...
+ spec:
+ reportIngressStatus:
+ enable: true
+ ...
+ ```
+
+1. Make sure you have a certificate secret in the same namespace as the runtime. Copy an existing secret if you don't have one.
+You will need to add this to the `ingress-master` when you have completed runtime installation.
+
+{::nomarkdown}
+
+{:/}
+
+#### Patch certificate secret
+> The certificate secret must be configured _after_ installing the hybrid runtime.
+
+Patch the certificate secret in `spec.tls` of the `ingress-master` resource.
+The secret must be in the same namespace as the runtime.
+
+1. Go to the runtime namespace with the NGINX ingress controller.
+1. In `ingress-master`, add to `spec.tls`:
+
+ ```yaml
+ tls:
+ - hosts:
+ -
+ secretName:
+ ```
+
+{::nomarkdown}
+
+{:/}
+
+### NGINX Community version ingress configuration
+
+Codefresh has been tested with and supports implementations of the major providers. For your convenience, we have provided configuration instructions, both for supported and untested providers in [Provider-specific configuration](#provider-specific-configuration).
+
+
+This section lists the specific configuration requirements for Codefresh to be completed _before_ installing the hybrid runtime.
+* Verify valid external IP address
+* Valid TLS certificate
+* TCP support
+
+{::nomarkdown}
+
+{:/}
+
+#### Valid external IP address
+Run `kubectl get svc -A` to get a list of services, and verify that the `EXTERNAL-IP` column for your ingress controller shows a valid hostname.
+
+{::nomarkdown}
+
+{:/}
+
+#### Valid TLS certificate
+For secure runtime installation, the ingress controller must have a valid TLS certificate.
+> Use the FQDN (Fully Qualified Domain Name) of the ingress controller for the TLS certificate.
+
+{::nomarkdown}
+
+{:/}
+
+#### TCP support
+Configure the ingress controller to handle TCP requests.
+
+Here's an example of TCP configuration for NGINX Community on AWS.
+Verify that the `ingress-nginx-controller` service manifest has either of the following annotations:
+
+`service.beta.kubernetes.io/aws-load-balancer-backend-protocol: "tcp"`
+OR
+`service.beta.kubernetes.io/aws-load-balancer-type: nlb`
+
+{::nomarkdown}
+
+{:/}
+
+#### Provider-specific configuration
+
+> The instructions are valid for `k8s.io/ingress-nginx`, the community version of NGINX.
+
+
+AWS
+
+
Verify a valid external address exists:
+ kubectl get svc ingress-nginx-controller -n ingress-nginx
+
+
+For additional configuration options, see ingress-nginx documentation for Docker Desktop.
+Note: By default, Docker Desktop services will provision with localhost as their external address. Triggers in delivery pipelines cannot reach this instance unless they originate from the same machine where Docker Desktop is being used.
+
+
+
+
+Exoscale
+
+
Verify a valid external address exists:
+ kubectl get svc ingress-nginx-controller -n ingress-nginx
+
+
+For additional configuration options, see ingress-nginx documentation for Exoscale.
+
+
+
+
+
+Google (GKE)
+
+Add firewall rules
+
+GKE by default limits outbound requests from nodes. For the runtime to communicate with the control-plane in Codefresh, add a firewall-specific rule.
+
+
+
Install using Microk8s addon system:
+ microk8s enable ingress
+
+
Verify a valid external address exists:
+ kubectl get svc ingress-nginx-controller -n ingress-nginx
+
+
+MicroK8s has not been tested with Codefresh, and may require additional configuration. For details, see Ingress addon documentation.
+
+
+
+
+
+MiniKube
+
+
Verify a valid external address exists:
+ kubectl get svc ingress-nginx-controller -n ingress-nginx
+
+
+MiniKube has not been tested with Codefresh, and may require additional configuration. For details, see Ingress addon documentation.
+
+
+
+
+
+
+Oracle Cloud Infrastructure
+
+
Verify a valid external address exists:
+ kubectl get svc ingress-nginx-controller -n ingress-nginx
+
+
+For additional configuration options, see ingress-nginx documentation for Scaleway.
+
+
+
+{::nomarkdown}
+
+{:/}
+
+### Traefik ingress configuration
+For detailed configuration information, see [Traefik ingress controller documentation](https://doc.traefik.io/traefik/providers/kubernetes-ingress){:target="\_blank}.
+
+The table below lists the specific configuration requirements for Codefresh.
+
+{: .table .table-bordered .table-hover}
+
+| What to configure | When to configure |
+| -------------- | -------------- |
+|Valid external IP address | _Before_ installing hybrid runtime |
+|Valid SSL certificate | |
+|TCP support | |
+|Enable report status to cluster| |
+
+{::nomarkdown}
+
+{:/}
+
+#### Valid external IP address
+Run `kubectl get svc -A` to get a list of services and verify that the `EXTERNAL-IP` column for your ingress controller shows a valid hostname.
+
+{::nomarkdown}
+
+{:/}
+
+#### Valid TLS certificate
+For secure runtime installation, the ingress controller must have a valid TLS certificate.
+> Use the FQDN (Fully Qualified Domain Name) of the ingress controller for the TLS certificate.
+
+{::nomarkdown}
+
+{:/}
+
+#### TCP support
+Configure the ingress controller to handle TCP requests.
+
+{::nomarkdown}
+
+{:/}
+
+#### Enable report status to cluster
+By default, the Traefik ingress controller is not configured to report its status to the cluster. If not configured, Argo’s health check reports the health status as “progressing”, resulting in a timeout error during installation.
+
+To enable reporting its status, add `publishedService` to `providers.kubernetesIngress.ingressEndpoint`.
+
+The value must be in the format `"/"`, where:
+ `` is the Traefik service from which to copy the status
+
+```yaml
+...
+providers:
+ kubernetesIngress:
+ ingressEndpoint:
+ publishedService: "/" # Example, "codefresh/traefik-default"
+...
+```
+
+{::nomarkdown}
+
+{:/}
+
+## GitOps CLI installation
+
+### GitOps CLI installation modes
+The table lists the modes available to install the Codefresh CLI.
+
+{: .table .table-bordered .table-hover}
+| Install mode | OS | Commands |
+| -------------- | ----------| ----------|
+| `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`|
+
+### Install the GitOps CLI
+Install the GitOps CLI using the option that best suits you: `curl`, `brew`, or standard download.
+If you are not sure which OS to select for `curl`, simply select one, and Codefresh automatically identifies and selects the right OS for the installation.
+
+1. Do one of the following:
+ * For first-time installation, go to the Welcome page, select **+ Install Runtime**.
+ * If you have provisioned a GitOps Runtime, in the Codefresh UI, go to [GitOps Runtimes](https://g.codefresh.io/2.0/account-settings/runtimes){:target="\_blank"}, and select **+ Add Runtime**.
+1. Install the Codefresh CLI:
+ * Select one of the installation modes.
+ * Generate the API key.
+ * Create the authentication context:
+ `cf config create-context codefresh --api-key `
+
+
+ {% 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 CLI to install runtime"
+ caption="Download CLI to install runtime"
+ max-width="30%"
+ %}
+
+
+{::nomarkdown}
+
+{:/}
+
+## Install Hybrid GitOps Runtime
+
+### Before you begin
+* Make sure you meet the [minimum requirements]({{site.baseurl}}/docs/runtime/requirements/#minimum-system-requirements) for installation
+* Make sure you have [Runtime token with the required scopes from your Git provider]({{site.baseurl}}/docs/reference/git-tokens)
+* [Download or upgrade to the latest version of the CLI]({{site.baseurl}}/docs/installation/cli/upgrade-gitops-cli)
+* Review [Hybrid Runtime installation flags](#hybrid-runtime-installation-flags)
+* For ingress-based runtimes, make sure your ingress controller is configured correctly:
+ * [Ambasador ingress configuration]({{site.baseurl}}/docs/runtime/requirements/#ambassador-ingress-configuration)
+ * [AWS ALB ingress configuration]({{site.baseurl}}/docs/runtime/requirements/#alb-aws-ingress-configuration)
+ * [Istio ingress configuration]({{site.baseurl}}/docs/runtime/requirements/#istio-ingress-configuration)
+ * [NGINX Enterprise ingress configuration]({{site.baseurl}}/docs/runtime/requirements/#nginx-enterprise-ingress-configuration)
+ * [NGINX Community ingress configuration]({{site.baseurl}}/docs/runtime/requirements/#nginx-community-version-ingress-configuration)
+ * [Traefik ingress configuration]({{site.baseurl}}/docs/runtime/requirements/#traefik-ingress-configuration)
+
+
+{::nomarkdown}
+
+{:/}
+
+### How to
+
+1. Do one of the following:
+ * If this is your first Hybrid GitOps installation, in the Welcome page, select **+ Install Runtime**.
+ * If you have already provisioned a Hybrid GitOps Runtime, to provision additional runtimes, in the Codefresh UI:
+ On the toolbar, click the **Settings** icon, and expand Runtimes in the sidebar, and select [**GitOps Runtimes**](https://g.codefresh.io/2.0/account-settings/runtimes){:target="\_blank"}.
+1. Click **+ Add Runtimes**, and then select **Hybrid Runtimes**.
+1. Do one of the following:
+ * CLI wizard: Run `cf runtime install`, and follow the prompts to enter the required values.
+ * Silent install: Pass the required flags in the install command:
+ `cf runtime install --repo --git-token --silent`
+ For the list of flags, see [Hybrid runtime installation flags](#hybrid-runtime-installation-flags).
+1. If relevant, complete the configuration for these ingress controllers:
+ * [ALB AWS: Alias DNS record in route53 to load balancer]({{site.baseurl}}/docs/runtime/requirements/#alias-dns-record-in-route53-to-load-balancer)
+ * [Istio: Configure cluster routing service]({{site.baseurl}}/docs/runtime/requirements/#cluster-routing-service)
+ * [NGINX Enterprise ingress controller: Patch certificate secret]({{site.baseurl}}/docs/runtime/requirements/#patch-certificate-secret)
+1. If you bypassed installing ingress resources with the `--skip-ingress` flag for ingress controllers not in the supported list, create and register Git integrations using these commands:
+ `cf integration git add default --runtime --api-url `
+ `cf integration git register default --runtime --token `
+
+
+{::nomarkdown}
+
+{:/}
+
+
+
+## Hybrid GitOps Runtime installation flags
+This section describes the required and optional flags to install a Hybrid GitOps Runtime.
+For documentation purposes, the flags are grouped into:
+* Runtime flags, relating to Runtime, cluster, and namespace requirements
+* Ingress-less flags, for tunnel-based installation
+* Ingress-controller flags, for ingress-based installation
+* Git provider and repo flags
+* Codefresh resource flags
+
+{::nomarkdown}
+
+{:/}
+
+### Runtime flags
+
+**Runtime name**
+Required.
+The Runtime name must start with a lower-case character, and can include up to 62 lower-case characters and numbers.
+* CLI wizard: Add when prompted.
+* Silent install: Add the `--runtime` flag and define the name.
+
+**Namespace resource labels**
+Optional.
+The label of the namespace resource to which you are installing the Hybrid Runtime. Labels are required to identify the networks that need access during installation, as is the case when using services meshes, such as Istio for example.
+
+* CLI wizard and Silent install: Add the `--namespace-labels` flag, and define the labels in `key=value` format. Separate multiple labels with `commas`.
+
+**Kube context**
+Required.
+The cluster defined as the default for `kubectl`. If you have more than one Kube context, the current context is selected by default.
+
+* CLI wizard: Select the Kube context from the list displayed.
+* Silent install: Explicitly specify the Kube context with the `--context` flag.
+
+**Access mode**
+The access mode for the runtime, which can be one of the following:
+* [Tunnel-based]({{site.baseurl}}/docs/installation/runtime-architecture/#tunnel-based-hybrid-gitops-runtime-architecture), for runtimes without ingress controllers. This is the default.
+* [Ingress-based]({{site.baseurl}}/docs/installation/runtime-architecture/#ingress-based-hybrid-gitops-runtime-architecture) for runtimes with ingress contollers.
+
+
+* CLI wizard: Select the access mode from the list displayed.
+* Silent install:
+ * For tunnel-based, see [Tunnel-based runtime flags](#tunnel-based-runtime-flags)
+ * For ingress-based, add the [Ingress controller flags](#ingress-controller-flags)
+
+ >If you don't specify any flags, tunnel-based access is automatically selected.
+
+**Shared configuration repository**
+The Git repository per Runtime account with shared configuration manifests.
+* CLI wizard and Silent install: Add the `--shared-config-repo` flag and define the path to the shared repo.
+
+{::nomarkdown}
+
+{:/}
+
+### Tunnel-based runtime flags
+These flags are required to install tunnel-based Hybrid Runtimes, without an ingress controller.
+
+**IP allowlist**
+
+Optional.
+
+The allowed list of IPs from which to forward requests to the internal customer cluster for ingress-less runtime installations. The allowlist can include IPv4 and IPv6 addresses, with/without subnet and subnet masks. Multiple IPs must be separated by commas.
+
+When omitted, all incoming requests are authenticated regardless of the IPs from which they originated.
+
+* CLI wizard and Silent install: Add the `--ips-allow-list` flag, followed by the IP address, or list of comma-separated IPs to define more than one. For example, `--ips-allow-list 77.126.94.70/16,192.168.0.0`
+
+{::nomarkdown}
+
+{:/}
+
+### Ingress controller flags
+
+
+**Skip ingress**
+Required, if you are using an unsupported ingress controller.
+For unsupported ingress controllers, bypass installing ingress resources with the `--skip-ingress` flag.
+In this case, after completing the installation, manually configure the cluster's routing service, and create and register Git integrations. See the last step in [Install the Hybrid GitOps Runtime](#install-hybrid-gitops-runtime).
+
+**Ingress class**
+Required.
+
+* CLI wizard: Select the ingress class for Runtime installation from the list displayed.
+* Silent install: Explicitly specify the ingress class through the `--ingress-class` flag. Otherwise, Runtime installation fails.
+
+**Ingress host**
+Required.
+The IP address or host name of the ingress controller component.
+
+* CLI wizard: Automatically selects and displays the host, either from the cluster or the ingress controller associated with the **Ingress class**.
+* Silent install: Add the `--ingress-host` flag. If a value is not provided, takes the host from the ingress controller associated with the **Ingress class**.
+ > Important: For AWS ALB, the ingress host is created post-installation. However, when prompted, add the domain name you will create in `Route 53` as the ingress host.
+
+**Insecure ingress hosts**
+TLS certificates for the ingress host:
+If the ingress host does not have a valid TLS certificate, you can continue with the installation in insecure mode, which disables certificate validation.
+
+* CLI wizard: Automatically detects and prompts you to confirm continuing the installation in insecure mode.
+* Silent install: To continue with the installation in insecure mode, add the `--insecure-ingress-host` flag.
+
+**Internal ingress host**
+Optional.
+Enforce separation between internal (app-proxy) and external (webhook) communication by adding an internal ingress host for the app-proxy service in the internal network.
+For both CLI wizard and Silent install:
+
+* For new Runtime installations, add the `--internal-ingress-host` flag pointing to the ingress host for `app-proxy`.
+* For existing installations, commit changes to the installation repository by modifying the `app-proxy ingress` and `.yaml`
+ See [(Optional) Internal ingress host configuration for existing Hybrid Runtimes](#optional-internal-ingress-host-configuration-for-existing-hybrid-runtimes).
+
+{::nomarkdown}
+
+{:/}
+
+
+
+### Git provider and repo flags
+The Git provider defined for the Runtime.
+
+>Because Codefresh creates a [shared configuration repo]({{site.baseurl}}/docs/reference/shared-configuration) for the Runtimes in your account, the Git provider defined for the first Runtime you install in your account is used for all the other Runtimes in the same account.
+
+You can define any of the following Git providers:
+* GitHub:
+ * [GitHub](#github) (the default Git provider)
+ * [GitHub Enterprise](#github-enterprise)
+* GitLab:
+ * [GitLab Cloud](#gitlab-cloud)
+ * [GitLab Server](#gitlab-server)
+* Bitbucket:
+ * [Bitbucket Cloud](#bitbucket-cloud)
+ * [Bitbucket Server](#bitbucket-server)
+
+{::nomarkdown}
+
+{:/}
+
+
+
+#### GitHub
+GitHub is the default Git provider for Hybrid Runtimes. Being the default provider, for both the CLI wizard and Silent install, you need to provide only the repository URL and the Git runtime token.
+
+> For the required scopes, see [GitHub and GitHub Enterprise Runtime token scopes]({{site.baseurl}}/docs/reference/git-tokens/#github-and-github-enterprise-runtime-token-scopes).
+
+`--repo --git-token `
+
+where:
+* `--repo ` (required), is the `HTTPS` clone URL of the Git repository for the Runtime installation, including the `.git` suffix. Copy the clone URL from your GitHub website (see [Cloning with HTTPS URLs](https://docs.github.com/en/get-started/getting-started-with-git/about-remote-repositories#cloning-with-https-urls){:target="\_blank"}).
+ If the repo doesn't exist, copy an existing clone URL and change the name of the repo. Codefresh creates the repository during the installation.
+
+ Repo URL format:
+ `https://github.com//reponame>.git[/subdirectory][?ref=branch]`
+ where:
+ * `/` is your username or organization name, followed by the name of the repo, identical to the HTTPS clone URL. For example, `https://github.com/nr-codefresh/codefresh.io.git`.
+ * `[/subdirectory]` (optional) is the path to a subdirectory within the repo. When omitted, the Runtime is installed in the root of the repository. For example, `/runtimes/defs`.
+ * `[?ref=branch]` (optional) is the `ref` queryParam to select a specific branch. When omitted, the Runtime is installed in the default branch. For example, `codefresh-prod`.
+
+ Example:
+ `https://github.com/nr-codefresh/codefresh.io.git/runtimes/defs?ref=codefresh-prod`
+* `--git-token ` (required), is the Git token authenticating access to the Runtime installation repository (see [GitHub runtime token scopes]({{site.baseurl}}/docs/reference/git-tokens/#github-and-github-enterprise-runtime-token-scopes)).
+
+{::nomarkdown}
+
+{:/}
+
+#### GitHub Enterprise
+
+> For the required scopes, see [GitHub and GitHub Enterprise runtime token scopes]({{site.baseurl}}/docs/reference/git-tokens/#github-and-github-enterprise-runtime-token-scopes).
+
+
+`--provider github --repo --git-token `
+
+where:
+* `--provider github` (required), defines GitHub Enterprise as the Git provider for the Runtime and the account.
+* `--repo ` (required), is the `HTTPS` clone URL of the Git repository for the Runtime installation, including the `.git` suffix. Copy the clone URL for HTTPS from your GitHub Enterprise website (see [Cloning with HTTPS URLs](https://docs.github.com/en/get-started/getting-started-with-git/about-remote-repositories#cloning-with-https-urls){:target="\_blank"}).
+ If the repo doesn't exist, copy an existing clone URL and change the name of the repo. Codefresh creates the repository during the installation.
+ Repo URL format:
+
+ `https://ghe-trial.devops.cf-cd.com//.git[/subdirectory][?ref=branch]`
+ where:
+ * `/` is your username or organization name, followed by the name of the repo. For example, `codefresh-io/codefresh.io.git`.
+ * `[/subdirectory]` (optional) is the path to a subdirectory within the repo. When omitted, the Runtime is installed in the root of the repository. For example, `/runtimes/defs`.
+ * `[?ref=branch]` (optional) is the `ref` queryParam to select a specific branch. When omitted, the Runtime is installed in the default branch. For example, `codefresh-prod`.
+
+ Example:
+ `https://ghe-trial.devops.cf-cd.com/codefresh-io/codefresh.io.git/runtimes/defs?ref=codefresh-prod`
+* `--git-token ` (required), is the Git token authenticating access to the Runtime installation repository (see [GitHub runtime token scopes]({{site.baseurl}}/docs/reference/git-tokens/#github-and-github-enterprise-runtime-token-scopes)).
+
+
+{::nomarkdown}
+
+{:/}
+
+#### GitLab Cloud
+> For the required scopes, see [GitLab Cloud and GitLab Server runtime token scopes]({{site.baseurl}}/docs/reference/git-tokens/#gitlab-cloud-and-gitlab-server-runtime-token-scopes).
+
+
+`--provider gitlab --repo --git-token `
+
+where:
+* `--provider gitlab` (required), defines GitLab Cloud as the Git provider for the Runtime and the account.
+* `--repo ` (required), is the `HTTPS` clone URL of the Git project for the Runtime installation, including the `.git` suffix. Copy the clone URL for HTTPS from your GitLab website.
+ If the repo doesn't exist, copy an existing clone URL and change the name of the repo. Codefresh creates the repository during the installation.
+
+ > Important: You must create the group with access to the project prior to the installation.
+
+ Repo URL format:
+
+ `https://gitlab.com//.git[/subdirectory][?ref=branch]`
+ where:
+ * `` is either your username, or if your project is within a group, the front-slash separated path to the project. For example, `nr-codefresh` (owner), or `parent-group/child-group` (group hierarchy)
+ * `` is the name of the project. For example, `codefresh`.
+ * `[/subdirectory]` (optional) is the path to a subdirectory within the repo. When omitted, the Runtime is installed in the root of the repository. For example, `/runtimes/defs`.
+ * `[?ref=branch]` (optional) is the `ref` queryParam to select a specific branch. When omitted, the Runtime is installed in the default branch. For example, `codefresh-prod`.
+
+ Examples:
+ `https://gitlab.com/nr-codefresh/codefresh.git/runtimes/defs?ref=codefresh-prod` (owner)
+
+ `https://gitlab.com/parent-group/child-group/codefresh.git/runtimes/defs?ref=codefresh-prod` (group hierarchy)
+
+* `--git-token ` (required), is the Git token authenticating access to the Runtime installation repository (see [GitLab runtime token scopes]({{site.baseurl}}/docs/reference/git-tokens/#gitlab-cloud-and-gitlab-server-runtime-token-scopes)).
+
+
+{::nomarkdown}
+
+{:/}
+
+
+#### GitLab Server
+
+> For the required scopes, see [GitLab Cloud and GitLab Server runtime token scopes]({{site.baseurl}}/docs/reference/git-tokens/#gitlab-cloud-and-gitlab-server-runtime-token-scopes).
+
+`--provider gitlab --repo --git-token `
+
+where:
+* `--provider gitlab` (required), defines GitLab Server as the Git provider for the Runtime and the account.
+* `--repo ` (required), is the `HTTPS` clone URL of the Git repository for the Runtime installation, including the `.git` suffix.
+ If the project doesn't exist, copy an existing clone URL and change the name of the project. Codefresh creates the project during the installation.
+
+ > Important: You must create the group with access to the project prior to the installation.
+
+ Repo URL format:
+ `https://gitlab-onprem.devops.cf-cd.com//.git[/subdirectory][?ref=branch]`
+ where:
+ * `` is your username, or if the project is within a group or groups, the name of the group. For example, `nr-codefresh` (owner), or `parent-group/child-group` (group hierarchy)
+ * `` is the name of the project. For example, `codefresh`.
+ * `[/subdirectory]` (optional) is the path to a subdirectory within the repo. When omitted, the Runtime is installed in the root of the repository. For example, `/runtimes/defs`.
+ * `[?ref=branch]` (optional) is the `ref` queryParam to select a specific branch. When omitted, the Runtime is installed in the default branch. For example, `codefresh-prod`.
+
+ Examples:
+ `https://gitlab-onprem.devops.cf-cd.com/nr-codefresh/codefresh.git/runtimes/defs?ref=codefresh-prod` (owner)
+
+ `https://gitlab-onprem.devops.cf-cd.com/parent-group/child-group/codefresh.git/runtimes/defs?ref=codefresh-prod` (group hierarchy)
+
+* `--git-token ` (required), is the Git token authenticating access to the Runtime installation repository (see [GitLab runtime token scopes]({{site.baseurl}}/docs/reference/git-tokens/#gitlab-cloud-and-gitlab-server-runtime-token-scopes)).
+
+
+{::nomarkdown}
+
+{:/}
+
+#### Bitbucket Cloud
+> For the required scopes, see [Bitbucket runtime token scopes]({{site.baseurl}}/docs/reference/git-tokens/#bitbucket-cloud-and-bitbucket-server-runtime-token-scopes).
+
+
+`--provider bitbucket --repo --git-user --git-token `
+
+where:
+* `--provider gitlab` (required), defines Bitbucket Cloud as the Git provider for the Runtime and the account.
+* `--repo ` (required), is the `HTTPS` clone URL of the Git repository for the Runtime installation, including the `.git` suffix.
+ If the project doesn't exist, copy an existing clone URL and change the name of the project. Codefresh creates the project during Runtime installation.
+ >Important: Remove the username, including @ from the copied URL.
+
+ Repo URL format:
+
+ `https://bitbucket.org.git[/subdirectory][?ref=branch]`
+ where:
+ * `` is your workspace ID. For example, `nr-codefresh`.
+ * `` is the name of the repository. For example, `codefresh`.
+ * `[/subdirectory]` (optional) is the path to a subdirectory within the repo. When omitted, the Runtime is installed in the root of the repository. For example, `/runtimes/defs`.
+ * `[?ref=branch]` (optional) is the `ref` queryParam to select a specific branch. When omitted, the Runtime is installed in the default branch. For example, `codefresh-prod`.
+
+ Example:
+ `https://bitbucket.org/nr-codefresh/codefresh.git/runtimes/defs?ref=codefresh-prod`
+* `--git-user ` (required), is your username for the Bitbucket Cloud account.
+* `--git-token ` (required), is the Git token authenticating access to the runtime installation repository (see [Bitbucket runtime token scopes]({{site.baseurl}}/docs/reference/git-tokens/#bitbucket-cloud-and-bitbucket-server-runtime-token-scopes)).
+
+
+{::nomarkdown}
+
+{:/}
+
+#### Bitbucket Server
+
+> For the required scopes, see [Bitbucket runtime token scopes]({{site.baseurl}}/docs/reference/git-tokens/#bitbucket-cloud-and-bitbucket-server-runtime-token-scopes).
+
+
+`--provider bitbucket-server --repo --git-user --git-token `
+
+where:
+* `--provider gitlab` (required), defines Bitbucket Cloud as the Git provider for the Runtime and the account.
+* `--repo ` (required), is the `HTTPS` clone URL of the Git repository for the Runtime installation, including the `.git` suffix.
+ If the project doesn't exist, copy an existing clone URL and change the name of the project. Codefresh then creates the project during the installation.
+ >Important: Remove the username, including @ from the copied URL.
+
+ Repo URL format:
+
+ `https://bitbucket-server-8.2.devops.cf-cd.com:7990/scm//.git[/subdirectory][?ref=branch]`
+ where:
+ * `` is your username or organization name. For example, `codefresh-io.`.
+ * `` is the name of the repo. For example, `codefresh`.
+ * `[/subdirectory]` (optional) is the path to a subdirectory within the repo. When omitted, the Runtime is installed in the root of the repository. For example, `/runtimes/defs`.
+ * `[?ref=branch]` (optional) is the `ref` queryParam to select a specific branch. When omitted, the Runtime is installed in the default branch. For example, `codefresh-prod`.
+
+ Example:
+ `https://bitbucket-server-8.2.devops.cf-cd.com:7990/scm/codefresh-io/codefresh.git/runtimes/defs?ref=codefresh-prod`
+* `--git-user ` (required), is your username for the Bitbucket Server account.
+* `--git-token ` (required), is the Git token authenticating access to the Runtime installation repository (see [Bitbucket runtime token scopes]({{site.baseurl}}/docs/reference/git-tokens/#bitbucket-cloud-and-bitbucket-server-runtime-token-scopes)).
+
+{::nomarkdown}
+
+{:/}
+
+### Codefresh resource flags
+**Codefresh demo resources**
+Optional.
+Install demo pipelines to use as a starting point to create your own GitOps pipelines. We recommend installing the demo resources as these are used in our quick start tutorials.
+
+* Silent install: Add the `--demo-resources` flag, and define its value as `true` (default), or `false`. For example, `--demo-resources=true`
+
+**Insecure flag**
+For _on-premises installations_, if the Ingress controller does not have a valid SSL certificate, to continue with the installation, add the `--insecure` flag to the installation command.
+
+{::nomarkdown}
+
+{:/}
+
+
+
+
+
+
+
+## (Optional) Internal ingress host configuration for existing Hybrid GitOps Runtimes
+If you already have provisioned Hybrid GitOps Runtimes, to use an internal ingress host for app-proxy communication and an external ingress host to handle webhooks, change the specs for the `Ingress` and `Runtime` resources in the Runtime installation repository. Use the examples as guidelines.
+
+`/apps/app-proxy/overlays//ingress.yaml`: change `host`
+
+```yaml
+apiVersion: networking.k8s.io/v1
+kind: Ingress
+metadata:
+ name: codefresh-cap-app-proxy
+ namespace: codefresh #replace with your runtime name
+spec:
+ ingressClassName: nginx
+ rules:
+ - host: my-internal-ingress-host # replace with the internal ingress host for app-proxy
+ http:
+ paths:
+ - backend:
+ service:
+ name: cap-app-proxy
+ port:
+ number: 3017
+ path: /app-proxy/
+ pathType: Prefix
+```
+
+`..//bootstrap/.yaml`: add `internalIngressHost`
+
+```yaml
+apiVersion: v1
+data:
+ base-url: https://g.codefresh.io
+ runtime: |
+ apiVersion: codefresh.io/v1alpha1
+ kind: Runtime
+ metadata:
+ creationTimestamp: null
+ name: codefresh #replace with your runtime name
+ namespace: codefresh #replace with your runtime name
+ spec:
+ bootstrapSpecifier: github.com/codefresh-io/cli-v2/manifests/argo-cd
+ cluster: https://7DD8390300DCEFDAF87DC5C587EC388C.gr7.us-east-1.eks.amazonaws.com
+ components:
+ - isInternal: false
+ name: events
+ type: kustomize
+ url: github.com/codefresh-io/cli-v2/manifests/argo-events
+ wait: true
+ - isInternal: false
+ name: rollouts
+ type: kustomize
+ url: github.com/codefresh-io/cli-v2/manifests/argo-rollouts
+ wait: false
+ - isInternal: false
+ name: workflows
+ type: kustomize
+ url: github.com/codefresh-io/cli-v2/manifests/argo-workflows
+ wait: false
+ - isInternal: false
+ name: app-proxy
+ type: kustomize
+ url: github.com/codefresh-io/cli-v2/manifests/app-proxy
+ wait: false
+ defVersion: 1.0.1
+ ingressClassName: nginx
+ ingressController: k8s.io/ingress-nginx
+ ingressHost: https://support.cf.com/
+ internalIngressHost: https://my-internal-ingress-host # add this line and replace my-internal-ingress-host with your internal ingress host
+ repo: https://github.com/NimRegev/my-codefresh.git
+ version: 99.99.99
+```
+
+
+## Related articles
+[Add external clusters to Hybrid and Hosted Runtimes]({{site.baseurl}}/docs/installation/gitops/managed-cluster/)
+[Monitoring & managing GitOps Runtimes]({{site.baseurl}}/docs/installation/gitops/monitor-manage-runtimes/)
+[Add Git Sources to runtimes]({{site.baseurl}}/docs/installation/gitops/git-sources/)
+[Shared configuration repo]({{site.baseurl}}/docs/reference/shared-configuration)
+[Troubleshoot Hybrid Runtime installation]({{site.baseurl}}/docs/troubleshooting/runtime-issues/)
diff --git a/_docs/installation/gitops/managed-cluster.md b/_docs/installation/gitops/managed-cluster.md
new file mode 100644
index 000000000..737567ae3
--- /dev/null
+++ b/_docs/installation/gitops/managed-cluster.md
@@ -0,0 +1,290 @@
+---
+title: "Add external clusters to GitOps Runtimes"
+description: "Manage multiple remote clusters with single GitOps Runtime"
+group: installation
+sub_group: gitops
+toc: true
+---
+
+Register external clusters to provisioned Hybrid or Hosted GitOps Runtimes in Codefresh. Once you add an external cluster, you can deploy applications to that cluster without having to install Argo CD on the clusters in order to do so. Manage multiple external clusters through a single Runtime.
+
+When you add an external cluster to a provisioned GitOps Runtime, the cluster is registered as a managed cluster. A managed cluster is treated as any other managed K8s resource, meaning that you can monitor its health and sync status, deploy applications to it, view information in the Applications dashboard, and remove the cluster from the Runtime's managed list.
+
+Add managed clusters through:
+* GitOps CLI
+* Kustomize
+
+Adding a managed cluster via Codefresh ensures that Codefresh applies the required RBAC resources (`ServiceAccount`, `ClusterRole` and `ClusterRoleBinding`) to the target cluster, creates a `Job` that updates the selected Runtime with the information, registers the cluster in Argo CD as a managed cluster, and updates the platform with the new cluster information.
+
+
+## Add a managed cluster with GitOps CLI
+Add an external cluster to a provisioned GitOps Runtime through the GitOps CLI. When adding the cluster, you can also add labels and annotations to the cluster, which are added to the cluster secret created by Argo CD.
+Optionally, to first generate the YAML manifests, and then manually apply them, use the `dry-run` flag in the CLI.
+
+**Before you begin**
+
+* For _Hosted GitOps_ Runtimes: [Configure access to these IP addresses]({{site.baseurl}}/docs/administration/platform-ip-addresses/)
+* Verify that:
+ * Your Git personal access token is valid and has the [required scopes]({{site.baseurl}}/docs/reference/git-tokens)
+ * You have the [latest version of the Codefresh CLI]({{site.baseurl}}/docs/installation/gitops/upgrade-gitops-cli/)
+
+**How to**
+
+1. In the Codefresh UI, on the toolbar, click the **Settings** icon.
+1. From Runtimes in the sidebar, select [**GitOps Runtimes**](https://g.codefresh.io/2.0/account-settings/runtimes){:target="\_blank"}.
+1. From either the **Topology** or **List** views, select the Runtime to which to add the cluster.
+1. Topology View: Select {::nomarkdown}{:/}.
+ List View: Select the **Managed Clusters** tab, and then select **+ Add Cluster**.
+1. In the Add Managed Cluster panel, copy and run the command:
+ `cf cluster add [runtime-name] [--labels label-key=label-value] [--annotations annotation-key=annotation-value][--dry-run]`
+ where:
+ * `runtime-name` is the name of the Runtime to which to add the cluster.
+ * `--labels` is optional, and required to add labels to the cluster. When defined, add a label in the format `label-key=label-value`. Separate multiple labels with `commas`.
+ * `--annotations` is optional, and required to add annotations to the cluster. When defined, add an annotation in the format `annotation-key=annotation-value`. Separate multiple annotations with `commas`.
+ * `--dry-run` is optional, and required if you want to generate a list of YAML manifests that you can redirect and apply manually with `kubectl`.
+
+
+ {% include
+ image.html
+ lightbox="true"
+ file="/images/runtime/managed-cluster-add-panel.png"
+ url="/images/runtime/managed-cluster-add-panel.png"
+ alt="Add Managed Cluster panel"
+ caption="Add Managed Cluster panel"
+ max-width="40%"
+%}
+
+{:start="5"}
+1. If you used `dry-run`, apply the generated manifests to the same target cluster on which you ran the command.
+ Here is an example of the YAML manifest generated with the `--dry-run` flag. Note that the example has placeholders, which are replaced with the actual values during the `--dry-run`.
+
+
+```yaml
+apiVersion: v1
+kind: ServiceAccount
+metadata:
+ name: argocd-manager
+ namespace: kube-system
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+ name: argocd-manager-role
+rules:
+- apiGroups:
+ - '*'
+ resources:
+ - '*'
+ verbs:
+ - '*'
+- nonResourceURLs:
+ - '*'
+ verbs:
+ - '*'
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRoleBinding
+metadata:
+ name: argocd-manager-role-binding
+roleRef:
+ apiGroup: rbac.authorization.k8s.io
+ kind: ClusterRole
+ name: argocd-manager-role
+subjects:
+- kind: ServiceAccount
+ name: argocd-manager
+ namespace: kube-system
+---
+apiVersion: v1
+data:
+ contextName:
+ ingressUrl:
+ server:
+kind: ConfigMap
+metadata:
+ name: csdp-add-cluster-cm
+ namespace: kube-system
+---
+apiVersion: v1
+data:
+ annotations: |
+ :
+ :
+ contextName:
+ ingressUrl: ingressurl.com
+ labels: |
+ :
+ :
+ server: https://.gr7.us-east-1.eks.amazonaws.com/
+ csdpToken:
+kind: Secret
+metadata:
+ name: csdp-add-cluster-secret
+ namespace: kube-system
+type: Opaque
+---
+apiVersion: batch/v1
+kind: Job
+metadata:
+ name: csdp-add-cluster-job
+ namespace: kube-system
+spec:
+ template:
+ metadata:
+ name: csdp-add-cluster-pod
+ spec:
+ containers:
+ - args:
+ - ./add-cluster.sh
+ command:
+ - bash
+ env:
+ - name: SERVICE_ACCOUNT_NAME
+ valueFrom:
+ fieldRef:
+ fieldPath: spec.serviceAccountName
+ - name: INGRESS_URL
+ valueFrom:
+ configMapKeyRef:
+ key: ingressUrl
+ name: csdp-add-cluster-cm
+ - name: CSDP_TOKEN
+ valueFrom:
+ secretKeyRef:
+ key: csdpToken
+ name: csdp-add-cluster-secret
+ - name: CONTEXT_NAME
+ valueFrom:
+ configMapKeyRef:
+ key: contextName
+ name: csdp-add-cluster-cm
+ - name: SERVER
+ valueFrom:
+ configMapKeyRef:
+ key: server
+ name: csdp-add-cluster-cm
+ image: quay.io/codefresh/csdp-add-cluster:0.1.0
+ imagePullPolicy: Always
+ name: main
+ resources:
+ limits:
+ cpu: "1"
+ memory: 512Mi
+ requests:
+ cpu: "0.2"
+ memory: 256Mi
+ restartPolicy: Never
+ serviceAccount: argocd-manager
+ ttlSecondsAfterFinished: 600
+
+```
+
+The new cluster is registered to the GitOps Runtime as a managed cluster.
+
+## Add a managed cluster with Kustomize
+Create a `kustomization.yaml` file with the information shown in the example below, and run `kustomize build` on it.
+
+```yaml
+apiVersion: kustomize.config.k8s.io/v1beta1
+kind: Kustomization
+namespace: kube-system
+
+configMapGenerator:
+ - name: csdp-add-cluster-cm
+ namespace: kube-system
+ behavior: merge
+ literals:
+ # contextName is the name of the kube context (in the local kubeconfig file) that connects to the target cluster
+ - "contextName="
+ # ingressUrl is the url used to access the Codefresh runtime
+ # example https://some.domain.name
+ - "ingressUrl="
+ # server is the k8s cluster API endpoint url
+ # can be obtained by
+ # CONTEXT_NAME=
+ # CLUSTER_NAME=$(kubectl config view --raw --flatten -o jsonpath='{.contexts[?(@.name == "'"${CONTEXT_NAME}"'")].context.cluster}')
+ # kubectl config view --raw --flatten -o jsonpath='{.clusters[?(@.name == "'"${CLUSTER_NAME}"'")].cluster.server}'
+ - "server=https://.gr7.us-east-1.eks.amazonaws.com/"
+ - |
+ annotations=
+
+ - |
+ labels=
+
+
+secretGenerator:
+- behavior: merge
+ literals:
+ - csdpToken=
+ name: csdp-add-cluster-secret
+ namespace: kube-system
+
+resources:
+ - https://github.com/codefresh-io/cli-v2/manifests/add-cluster/kustomize?ref=
+```
+
+
+## Work with managed clusters
+Work with managed clusters in either the Topology or List Runtime views. For information on Runtime views, see [Runtime views]({{site.baseurl}}/docs/installation/monitor-manage-runtimes/#gitops-runtime-views).
+As the cluster is managed through the Runtime, updates to the Runtime automatically updates the components on all the managed clusters that include it.
+
+View connection status for the managed cluster, and health and sync errors. Health and sync errors are flagged by the error notification in the toolbar, and visually flagged in the List and Topology views.
+
+### Install Argo Rollouts
+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.
+If Argo Rollouts has not been installed on the target cluster, it displays **Install Argo Rollouts** button.
+
+Install Argo Rollouts with a single click to execute rollout instructions, deploy the application, and visualize rollout progress in the [Applications dashboard]({{site.baseurl}}/docs/deployments/gitops/applications-dashboard/).
+
+
+1. In the Codefresh UI, on the toolbar, click the **Settings** icon, expand Runtimes in the sidebar, and select [**GitOps Runtimes**](https://g.codefresh.io/2.0/account-settings/runtimes){:target="\_blank"}.
+1. Select **Topology View**.
+1. Select the target cluster, and then select **+ Install Argo Rollouts**.
+
+{% include
+ image.html
+ lightbox="true"
+ file="/images/runtime/cluster-install-rollout.png"
+ url="/images/runtime/cluster-install-rollout.png"
+ alt="Install Argo Rollouts"
+ caption="Install Argo Rollouts"
+ max-width="40%"
+%}
+
+
+### Remove a managed cluster from the Codefresh UI
+Remove a cluster from the Runtime's list of managed clusters from the Codefresh UI.
+
+> You can also remove it through the CLI.
+
+In the Codefresh UI, on the toolbar, click the **Settings** icon, expand Runtimes in the sidebar, and select [**GitOps Runtimes**](https://g.codefresh.io/2.0/account-settings/runtimes){:target="\_blank"}.
+1. Select either the **Topology View** or the **List View** tabs.
+1. Do one of the following:
+ * In the Topology View, select the cluster node from the Runtime it is registered to.
+ * In the List View, select the Runtime, and then select the **Managed Clusters** tab.
+1. Select the three dots next to the cluster name, and then select **Uninstall** (Topology View) or **Remove** (List View).
+
+{% include
+ image.html
+ lightbox="true"
+ file="/images/runtime/managed-cluster-remove-single.png"
+ url="/images/runtime/managed-cluster-remove-single.png"
+ alt="Remove a managed cluster from runtime (List View)"
+ caption="Remove a managed cluster from runtime (List View)"
+ max-width="50%"
+%}
+
+
+### Remove a managed cluster through the GitOps CLI
+Remove a cluster from the list managed by the GitOps Runtime, through the GitOps CLI.
+
+* Run:
+ `cf cluster remove --server-url `
+ where:
+ `` is the name of the runtime that the managed cluster is registered to.
+ `` is the URL of the server on which the managed cluster is installed.
+
+
+## Related articles
+[Add Git Sources to GitOps Runtimes]({{site.baseurl}}/docs/installation/gitops/git-sources/)
+[Monitoring & managing GitOps Runtimes]({{site.baseurl}}/docs/installation/gitops/monitor-manage-runtimes/)
diff --git a/_docs/installation/gitops/monitor-manage-runtimes.md b/_docs/installation/gitops/monitor-manage-runtimes.md
new file mode 100644
index 000000000..04b598062
--- /dev/null
+++ b/_docs/installation/gitops/monitor-manage-runtimes.md
@@ -0,0 +1,629 @@
+---
+title: "Monitoring & managing GitOps Runtimes"
+description: "Optimize GitOps Runtimes"
+group: runtime
+sub_group: gitops
+redirect_from:
+ - /monitor-manage-runtimes/
+ - /monitor-manage-runtimes
+toc: true
+---
+
+
+The **Runtimes** page displays the provisioned GitOps Runtimes in your account, both Hybrid, and the Hosted Runtime if you have one.
+
+View Runtime components and information in List or Topology view formats to manage and monitor them.
+
+{% include
+ image.html
+ lightbox="true"
+ file="/images/runtime/runtime-list-view.png"
+ url="/images/runtime/runtime-list-view.png"
+ alt="Runtime List View"
+ caption="Runtime List View"
+ max-width="70%"
+%}
+
+Manage provisioned GitOps Runtimes:
+* [Add managed clusters to GitOps Runtimes]({{site.baseurl}}/docs/installation/gitops/managed-cluster/)
+* [Add and manage Git Sources for GitOps Runtimes]({{site.baseurl}}/docs/installation/gitops/git-sources/)
+* [Upgrade GitOps CLI]({{site.baseurl}}/docs/installation/gitops/upgrade-gitops-cli/)
+* Upgrade Hybrid GitOps Runtimes
+* Uninstall GitOps Runtimes
+
+
+
+Monitor provisioned GitOps Runtimes for security, health, and sync errors:
+
+* (Hybrid and Hosted) View/download logs for Runtimes and for Runtime components
+* (Hybrid) Restore provisioned Runtimes
+* (Hybrid) Configure browsers to allow access to insecure Runtimes
+* (Hybrid) Monitor notifications in the Activity Log
+
+
+> Unless specified otherwise, all options are common to both types of GitOps Runtimes. If an option is valid only for Hybrid GitOps, it is indicated as such.
+
+
+## GitOps Runtime views
+
+View provisioned GitOps Runtimes in List or Topology view formats.
+
+* List view: The default view, displays the list of provisioned Runtimes, the clusters managed by them, and Git Sources associated with them.
+* Topology view: Displays a hierarchical view of Runtimes and the clusters managed by them, with health and sync status of each cluster.
+
+### List view
+
+The List view is a grid-view of the provisioned Runtimes.
+
+Here is an example of the List view for runtimes.
+{% include
+ image.html
+ lightbox="true"
+ file="/images/runtime/runtime-list-view.png"
+ url="/images/runtime/runtime-list-view.png"
+ alt="Runtime List View"
+ caption="Runtime List View"
+ max-width="70%"
+%}
+
+Here is a description of the information in the List View.
+
+{: .table .table-bordered .table-hover}
+| List View Item| Description |
+| -------------- | ---------------- |
+|**Name**| The name of the provisioned GitOps Runtime. |
+|**Type**| The type of GitOps Runtime provisioned, and can be **Hybrid** or **Hosted**. |
+|**Cluster/Namespace**| The K8s API server endpoint, as well as the namespace with the cluster. |
+|**Modules**| The modules installed based on the type of provisioned Runtime. Hybrid Runtimes include CI amnd CD Ops modules. Hosted runtimes include CD Ops. |
+|**Managed Cluster**| The number of managed clusters if any, for the runtime. To view list of managed clusters, select the runtime, and then the **Managed Clusters** tab. To work with managed clusters, see [Adding external clusters to runtimes]({{site.baseurl}}/docs/installation/gitops/managed-cluster/).|
+|**Version**| The version of the runtime currently installed. **Update Available!** indicates there are later versions of the runtime. To see all the commits to the runtime, mouse over **Update Available!**, and select **View Complete Change Log**.
+|**Last Updated**| The most recent update information from the runtime to the Codefresh platform. Updates are sent to the platform typically every few minutes. Longer update intervals may indicate networking issues.|
+|**Sync Status**| The health and sync status of the runtime or cluster. {::nomarkdown}
indicates health or sync errors in the runtime, or a managed cluster if one was added to the runtime. The runtime name is colored red.
indicates that the runtime is being synced to the cluster on which it is provisioned.
{:/} |
+
+### Topology view
+
+A hierachical visualization of the provisioned Runtimes. The Topology view makes it easy to identify key information such as versions, health and sync status, for both the provisioned Runtime and the clusters managed by it.
+Here is an example of the Topology view for Runtimes.
+ {% include
+ image.html
+ lightbox="true"
+ file="/images/runtime/runtime-topology-view.png"
+ url="/images/runtime/runtime-topology-view.png"
+ alt="Runtime Topology View"
+ caption="Runtime Topology View"
+ max-width="60%"
+%}
+
+Here is a description of the information in the Topology view.
+
+{: .table .table-bordered .table-hover}
+| Topology View Item | Description |
+| ------------------------| ---------------- |
+|**Runtime** |  the provisioned Runtime. Hybrid Runtimes display the name of the K8s API server endpoint with the cluster. Hosted Runtimes display 'hosted'. |
+|**Cluster** | The local, and managed clusters if any, for the Runtime. {::nomarkdown}
indicates the local cluster, always displayed as `in-cluster`. The in-cluster server URL is always set to `https://kubernetes.default.svc/`.
indicates a managed cluster.
select to add a new managed cluster.
{:/} To view cluster components, select the cluster. To add and work with managed clusters, see [Adding external clusters to runtimes]({{site.baseurl}}/docs/installation/gitops/managed-cluster). |
+|**Health/Sync status** |The health and sync status of the Runtime or cluster. {::nomarkdown}
indicates health or sync errors in the Runtime, or a managed cluster if one was added to the runtime. The runtime or cluster node is bordered in red and the name is colored red.
indicates that the Runtime is being synced to the cluster on which it is provisioned.
{:/} |
+|**Search and View options** | {::nomarkdown}
Find a Runtime or its clusters by typing part of the Runtime/cluster name, and then navigate to the entries found.
Topology view options: Resize to window, zoom in, zoom out, full screen view.
{:/}|
+
+## Managing provisioned GitOps Runtimes
+* [Reset shared configuration repository for GitOps Runtimes](#reset-shared-configuration-repository-for-gitops-runtimes)
+* [(Hybrid GitOps) Upgrade provisioned Runtimes](#hybrid-gitops-upgrade-provisioned-runtimes)
+* [Uninstall provisioned GitOps Runtimes](#uninstall-provisioned-gitops-runtimes)
+* [Update Git tokens for Runtimes](#update-git-tokens-for-runtimes)
+
+### Reset shared configuration repository for GitOps Runtimes
+Codefresh creates the [shared configuration repository]({{site.baseurl}}/docs/reference/shared-configuration) when you install the first hybrid or hosted GitOps runtime for your account, and uses it for all runtimes you add to the same account.
+
+If needed, you can reset the location of the shared configuration repository in your account and re-initialize it. For example, when moving from evaluation to production.
+Uninstall all the existing runtimes in your account, and then run the reset command. On the next installation, Codefresh re-initializes the shared configuration repo.
+
+**Before you begin**
+[Uninstall every runtime in the account](#uninstall-provisioned-gitops-runtimes)
+
+**How to**
+* Run:
+ `cf config --reset-shared-config-repo`
+
+
+### (Hybrid GitOps) Upgrade provisioned Runtimes
+
+Upgrade provisioned Hybrid Runtimes to install critical security updates or the latest versions of all components. Upgrade a provisioned Hybrid Runtime by running a silent upgrade or through the GitOps CLI wizard.
+If you have managed clusters for Hybrid GitOps, upgrading the Runtime automatically updates runtime components within the managed cluster as well.
+
+> When there are security updates, the UI displays the alert, _At least one runtime requires a security update_. The Version column displays an _Update Required!_ notification.
+
+> If you have older Hybrid Runtime versions, upgrade to manually define or create the shared configuration repo for your account. See [Shared configuration repo]({{site.baseurl}}/docs/reference/shared-configuration/).
+
+
+**Before you begin**
+For both silent or CLI-wizard based upgrades, make sure you have:
+
+* The latest version of the Codefresh CLI
+* A valid Git token with [the required scopes]({{site.baseurl}}/docs/reference/git-tokens)
+
+**Silent upgrade**
+
+* Pass the mandatory flags in the upgrade command:
+
+ `cf runtime upgrade --git-token --silent`
+ where:
+ `` is a valid Git token with the correct scopes.
+
+**CLI wizard-based upgrade**
+
+1. In the Codefresh UI, on the toolbar, click the **Settings** icon, expand Runtimes in the sidebar, and select [**GitOps Runtimes**](https://g.codefresh.io/2.0/account-settings/runtimes){:target="\_blank"}.
+1. Switch to either the **List View** or to the **Topology View**.
+1. **List view**:
+ * Select the Runtime name.
+ * To see all the commits to the Runtime, in the Version column, mouse over **Update Available!**, and select **View Complete Change Log**.
+ * On the top-right, select **Upgrade**.
+
+ {% include
+ image.html
+ lightbox="true"
+ file="/images/runtime/runtime-list-view-upgrade.png"
+ url="/images/runtime/runtime-list-view-upgrade.png"
+ alt="List View: Upgrade runtime option"
+ caption="List View: Upgrade runtime option"
+ max-width="30%"
+ %}
+
+ **Topology view**:
+ Select the Runtime cluster, and from the panel, select the three dots and then select **Upgrade Runtime**.
+ {% include
+ image.html
+ lightbox="true"
+ file="/images/runtime/runtiime-topology-upgrade.png"
+ url="/images/runtime/runtiime-topology-upgrade.png"
+ alt="Topology View: Upgrade runtime option"
+ caption="Topology View: Upgrade runtime option"
+ max-width="30%"
+%}
+
+{:start="4"}
+
+1. If you have already installed the GitOps CLI, in the Install Upgrades panel, copy the upgrade command.
+
+ {% include
+ image.html
+ lightbox="true"
+ file="/images/runtime/install-upgrades.png"
+ url="/images/runtime/install-upgrades.png"
+ alt="Upgrade runtime"
+ caption="Upgrade runtime panel"
+ max-width="30%"
+%}
+
+{:start="5"}
+1. In your terminal, paste the command, and do the following:
+ * Update the Git token value.
+ * To manually define the shared configuration repo, add the `--shared-config-repo` flag with the path to the repo.
+1. Confirm to start the upgrade.
+
+
+
+
+
+
+### Uninstall provisioned GitOps Runtimes
+
+Uninstall provisioned GitOps Runtimes that are not in use, through a silent uninstall or through the GitOps CLI wizard.
+> Uninstalling a Runtime removes the Git Sources and managed clusters associated with it.
+
+**Before you begin**
+For both types of uninstalls, make sure you have:
+
+* The latest version of the GitOps CLI
+* A valid runtime Git token
+* The Kube context from which to uninstall the provisioned Runtime
+
+**Silent uninstall**
+Pass the mandatory flags in the uninstall command:
+ `cf runtime uninstall --git-token --silent`
+ where:
+ `--git-token` is a valid runtime token with the `repo` and `admin-repo.hook` scopes.
+
+**GitOps CLI wizard uninstall**
+
+1. In the Codefresh UI, on the toolbar, click the **Settings** icon.
+1. From Runtimes in the sidebar, select [**GitOps Runtimes**](https://g.codefresh.io/2.0/account-settings/runtimes){:target="\_blank"}.
+1. Switch to either the **List View** or to the **Topology View**.
+1. **List view**: To the right of the runtime to delete, select the three dots and then select **Uninstall**.
+
+ {% include
+ image.html
+ lightbox="true"
+ file="/images/runtime/uninstall-location.png"
+ url="/images/runtime/uninstall-location.png"
+ alt="List View: Uninstall runtime option"
+ caption="List View: Uninstall runtime option"
+ max-width="30%"
+%}
+
+**Topology view**: Select the Runtime node, and from the panel, select the three dots and then select **Uninstall Runtime**.
+ {% include
+ image.html
+ lightbox="true"
+ file="/images/runtime/runtime-topology-uninstall.png"
+ url="/images/runtime/runtime-topology-uninstall.png"
+ alt="Topology View: Uninstall runtime option"
+ caption="Topology View: Uninstall runtime option"
+ max-width="30%"
+%}
+
+{:start="4"}
+
+1. If you already have the latest version of the GitOps CLI, in the Uninstall Codefresh Runtime panel, copy the uninstall command.
+
+ {% include
+ image.html
+ lightbox="true"
+ file="/images/runtime/uninstall.png"
+ url="/images/runtime/uninstall.png"
+ alt="Uninstall Codefresh runtime"
+ caption="Uninstall Codefresh runtime"
+ max-width="40%"
+%}
+
+{:start="5"}
+
+1. In your terminal, paste the command, and update the Git token value.
+1. Select the Kube context from which to uninstall the Runtime, and then confirm the uninstall.
+1. If you get errors, run the uninstall command again, with the `--force` flag.
+
+
+
+### Update Git tokens for Runtimes
+
+Provisioned Runtimes require valid Git tokens at all times to authenticate Git actions by you as a user.
+>These tokens are specific to the user, and the same can be used for multiple runtimes.
+
+There are two different situations when you need to update Git tokens:
+* Invalid, revoked, or expired tokens: Codefresh automatically flags Runtimes with such tokens. It is mandatory to update the Git tokens to continue working with the platform.
+* Valid tokens: Optional. You may want to update Git tokens, even valid ones, by deleting the existing token and replacing it with a new token.
+
+The methods for updating any Git token are the same regardless of the reason for the update:
+* OAuth2 authorization, if your admin has registered an OAuth Application for Codefresh
+* Git access token authentication, by generating a personal access token in your Git provider account with the correct scopes
+
+**Before you begin**
+* To authenticate through a Git access token, make sure your token is valid and has [the required scopes]({{site.baseurl}}/docs/reference/git-tokens)
+
+**How to**
+1. Do one of the following:
+ * If you see a notification in the Codefresh UI about invalid Runtime tokens, click **[Update Token]**.
+ The GitOps Runtimes page shows runtimes with invalid tokens prefixed by the key icon. Mouse over shows invalid token.
+ * To update an existing token, go to [GitOps Runtimes](https://g.codefresh.io/2.0/account-settings/runtimes){:target="\_blank"}.
+1. Select the GitOps Runtime for which to update the Git token.
+1. From the context menu at the right, select **Update Git Runtime Credentials**.
+
+ {% include
+ image.html
+ lightbox="true"
+ file="/images/runtime/update-git-runtime-token.png"
+ url="/images/runtime/update-git-runtime-token.png"
+ alt="Update Git runtime token option"
+ caption="Update Git runtime token option"
+ max-width="40%"
+%}
+
+{:start="4"}
+1. Do one of the following:
+ * If your admin has set up OAuth access, click **Authorize Access to Git Provider**. Go to _step 5_.
+ * Alternatively, authenticate with an access token from your Git provider. Go to _step 6_.
+
+{:start="5"}
+1. For OAuth2 authorization:
+ > If the application is not registered, you get an error. Contact your admin for help.
+ * Enter your credentials, and select **Sign In**.
+ * If required, as for example if two-factor authentication is configured, complete the verification.
+
+ {% include
+ image.html
+ lightbox="true"
+ file="/images/administration/user-settings/oauth-user-authentication.png"
+ url="/images/administration/user-settings/oauth-user-authentication.png"
+ alt="Authorizing access with OAuth2"
+ caption="Authorizing access with OAuth2"
+ max-width="30%"
+ %}
+
+{:start="6"}
+1. For Git token authentication, expand **Advanced authorization options**, and then paste the generated token in the **Git runtime token** field.
+
+1. Click **Update Token**.
+
+## Monitoring GitOps Runtimes
+* [View/download logs to troubleshoot Runtimes](#viewdownload-logs-to-troubleshoot-runtimes)
+* [(Hybrid GitOps) Restoring provisioned Runtimes](#hybrid-gitops-restoring-provisioned-runtimes)
+* [(Hybrid GitOps) Configure browser to allow insecure Runtimes](#hybrid-gitops-configure-browser-to-allow-insecure-runtimes)
+* [(Hybrid GitOps) View notifications in Activity Log](#hybrid-gitops-view-notifications-in-activity-log)
+* [(Hybrid GitOps) Troubleshoot health and sync errors for Runtimes](#hybrid-gitops-troubleshoot-health-and-sync-errors-for-runtimes)
+
+### View/download logs to troubleshoot GitOps Runtimes
+Logs are available for completed Runtimes, both for the runtime and for individual runtime components. Download log files for offline viewing and analysis, or view online logs for a Runtime component, and download if needed for offline analysis. Online logs support free-text search, search-result navigation, and line-wrap for enhanced readability.
+
+Log files include events from the date of the application launch, with the newest events listed first.
+
+{::nomarkdown}
+
+{:/}
+
+#### Download logs for GitOps Runtimes
+Download the log file for a Runtime. The Runtime log is downloaded as a `.tar.gz` file, which contains the individual log files for each runtime component.
+
+1. In the Codefresh UI, on the toolbar, click the **Settings** icon, expand Runtimes in the sidebar, and select [**GitOps Runtimes**](https://g.codefresh.io/2.0/account-settings/runtimes){:target="\_blank"}.
+1. If needed, switch to **List View**, and then select the runtime for which to download logs.
+1. From the context menu, select **Download All Logs**.
+ The log file is downloaded to the Downloads folder or the folder designated for downloads, with the filename, `.tar.gz`. For example, `codefreshv2-production2.tar.gz`.
+
+
+ {% include
+ image.html
+ lightbox="true"
+ file="/images/runtime/runtime-logs-download-all.png"
+ url="/images/runtime/runtime-logs-download-all.png"
+ alt="Download logs for selected runtime"
+ caption="Download logs for selected runtime"
+ max-width="40%"
+%}
+
+
+{:start="4"}
+1. To view the log files of the individual components, unzip the file.
+ Here is an example of the folder with the individual logs.
+
+ {% include
+ image.html
+ lightbox="true"
+ file="/images/runtime/runtime-logs-folder-view.png"
+ url="/images/runtime/runtime-logs-folder-view.png"
+ alt="Individual log files in folder"
+ caption="Individual log files in folder"
+ max-width="50%"
+%}
+
+{:start="5"}
+1. Open a log file with the text editor of your choice.
+
+{::nomarkdown}
+
+{:/}
+
+#### View/download logs for Runtime components
+View online logs for any Runtime component, and if needed, download the log file for offline viewing and analysis.
+
+Online logs show up to 1000 of the most recent events (lines), updated in real time. Downloaded logs include all the events, from the application launch to the date and time of download.
+
+1. In the Codefresh UI, on the toolbar, click the **Settings** icon, expand Runtimes in the sidebar, and select [**GitOps Runtimes**](https://g.codefresh.io/2.0/account-settings/runtimes){:target="\_blank"}.
+1. If needed, switch to **List View**, and then select the Runtime.
+1. Select the Runtime component and then select **View Logs**.
+
+ {% include
+ image.html
+ lightbox="true"
+ file="/images/runtime/runtime-logs-view-component.png"
+ url="/images/runtime/runtime-logs-view-component.png"
+ alt="View log option for individual runtime component"
+ caption="View log option for individual runtime component"
+ max-width="40%"
+%}
+
+
+{:start="4"}
+1. Do the following:
+ * Search by free-text for any string, and click the next and previous buttons to navigate between the search results.
+ * To switch on line-wrap for readability, click **Wrap**.
+
+ {% include
+ image.html
+ lightbox="true"
+ file="/images/runtime/runtime-logs-screen-view.png"
+ url="/images/runtime/runtime-logs-screen-view.png"
+ alt="Online log example for runtime component"
+ caption="Online log example for runtime component"
+ max-width="50%"
+%}
+
+{:start="5"}
+1. To download the log, click **Download**.
+ The file is downloaded as `.log`.
+
+### (Hybrid GitOps) Restoring provisioned Runtimes
+
+In case of cluster failure, restore the provisioned Hybrid Runtime from the existing runtime installation repository.
+For partial or complete cluster failures, you can restore the Runtime to either the failed cluster or to a different cluster.
+Restoring the provisioned Runtime reinstalls it, leveraging the resources in the existing Runtime repo.
+
+Restoring the runtime:
+* Applies `argo-cd` from the installation manifests in your repo to your cluster
+* Associates `argo-cd` with the existing installation repo
+* Applies the Runtime and `argo-cd` secrets to the cluster
+* Updates the Runtime config map (`.yaml` in the `bootstrap` directory) with the new cluster configuration for these fields:
+ `cluster`
+ `ingressClassName`
+ `ingressController`
+ `ingressHost`
+
+{::nomarkdown}
+
+{:/}
+
+#### Restore a Hybrid Runtime
+Reinstall the Hybrid Runtime from the existing installation repository to restore it to the same or a different cluster.
+
+**Before you begin**
+
+* Have the following information handy:
+ > All values must be the identical to the Runtime to be restored.
+ * Runtime name
+ * Repository URL
+ * Codefresh context
+ * Kube context: Required if you are restoring to the same cluster
+
+**How to**
+
+1. Run:
+ `cf runtime install --from-repo`
+1. Provide the relevant values when prompted.
+1. If you are performing the runtime recovery in a different cluster, verify the ingress resource configuration for `app-proxy`, `workflows`, and `default-git-source`.
+ If the health status remains as `Progressing`, do the following:
+
+ * In the Runtime installation repo, check if the `ingress.yaml` files for the `app-proxy` and `workflows` are configured with the correct `host` and `ingressClassName`:
+
+ `apps/app-proxy/overlays//ingress.yaml`
+ `apps/workflows/overlays//ingress.yaml`
+
+ * In the Git Source repository, check the `host` and `ingressClassName` in `cdp-default-git-source.ingress.yaml`:
+
+ `resources_/cdp-default-git-source.ingress.yaml`
+
+ See the [example](#ingress-example) below.
+
+{:start="4"}
+1. If you have managed clusters registered to the hybrid runtime you are restoring, reconnect them.
+ Run the command and follow the instructions in the wizard:
+ `cf cluster add`
+
+1. Verify that you have a registered Git integration:
+ `cf integration git list --runtime `
+
+1. If needed, create a new Git integration:
+ `cf integration git add default --runtime --provider github --api-url https://api.github.com`
+
+{::nomarkdown}
+
+{:/}
+
+#### Ingress example
+This is an example of the `ingress.yaml` for `workflows`.
+
+ ```yaml
+apiVersion: networking.k8s.io/v1
+kind: Ingress
+metadata:
+ annotations:
+ ingress.kubernetes.io/protocol: https
+ ingress.kubernetes.io/rewrite-target: /$2
+ nginx.ingress.kubernetes.io/backend-protocol: https
+ nginx.ingress.kubernetes.io/rewrite-target: /$2
+ creationTimestamp: null
+ name: runtime-name-workflows-ingress
+ namespace: runtime-name
+spec:
+ ingressClassName: nginx
+ rules:
+ - host: your-ingress-host.com
+ http:
+ paths:
+ - backend:
+ service:
+ name: argo-server
+ port:
+ number: 2746
+ path: /workflows(/|$)(.*)
+ pathType: ImplementationSpecific
+status:
+ loadBalancer: {}
+```
+
+
+### (Hybrid GitOps) Configure browser to allow insecure Runtimes
+
+If at least one of your Hybrid Runtimes was installed in insecure mode (without an SSL certificate for the ingress controller from a CA), the UI alerts you that _At least one runtime was installed in insecure mode_.
+{% include
+ image.html
+ lightbox="true"
+ file="/images/runtime/runtime-insecure-alert.png"
+ url="/images/runtime/runtime-insecure-alert.png"
+ alt="Insecure runtime installation alert"
+ caption="Insecure runtime installation alert"
+ max-width="100%"
+%}
+
+All you need to do is to configure the browser to trust the URL and receive content.
+
+1. Select **View Runtimes** to the right of the alert.
+ You are taken to the Runtimes page, where you can see insecure Runtimes tagged as **Allow Insecure**.
+
+ {% include
+ image.html
+ lightbox="true"
+ file="/images/runtime/runtime-insecure-steps.png"
+ url="/images/runtime/runtime-insecure-steps.png"
+ alt="Insecure runtimes in Runtime page"
+ caption="Insecure runtimes in Runtime page"
+ max-width="40%"
+%}
+{:start="2"}
+1. For _every_ insecure Runtime, select **Allow Insecure**, and when the browser prompts you to allow access, do as relevant:
+
+* Chrome: Click **Advanced** and then **Proceed to site**.
+* Firefox: Click **Advanced** and then **Accept the risk and continue**.
+* Safari: Click **Show Certificate**, and then select **Always allow content from site**.
+* Edge: Click **Advanced**, and then select **Continue to site(unsafe)**.
+
+### (Hybrid GitOps) View notifications in Activity Log
+
+The Activity Log is a quick way to monitor notifications for Runtime events such as upgrades. A pull-down panel in the Codefresh toolbar, the Activity Log shows ongoing, success, and error notifications, sorted by date, starting with today's date.
+
+1. In the Codefresh UI, on the top-right of the toolbar, select **Activity Log**.
+1. To see notifications for provisioned Runtimes, filter by **Runtime**.
+
+
+
+ {% include image.html
+ lightbox="true"
+ file="/images/runtime/runtime-activity-log.png"
+ url="/images/runtime/runtime-activity-log.png"
+ alt="Activity Log filtered by Runtime events"
+ caption="Activity Log filtered by Runtime events"
+ max-width="30%"
+ %}
+
+{:start="3"}
+
+1. To see more information on an error, select the **+** sign.
+
+### (Hybrid GitOps) Troubleshoot health and sync errors for Runtimes
+The  icon with the Runtime in red indicates either health or sync errors.
+
+**Health errors**
+Health errors are generated by Argo CD and by Codefresh for Runtime components.
+
+**Sync errors**
+Runtimes with sync errors display an **Out of sync** status in Sync Status column. They are related to discrepancies between the desired and actual state of a Runtime component or one of the Git sources associated with the Runtime.
+
+**View errors**
+For both views, select the Runtime, and then select **Errors Detected**.
+Here is an example of health errors for a Runtime.
+
+ {% include image.html
+ lightbox="true"
+ file="/images/runtime/runtime-health-sync-errors.png"
+ url="/images/runtime/runtime-health-sync-errors.png"
+ alt="Health errors for runtime example"
+ caption="Health errors for runtime example"
+ max-width="30%"
+ %}
+
+
+## Related articles
+[Add Git Sources to GitOps Runtimes]({{site.baseurl}}/docs/installation/gitops/git-sources/)
+[Add external clusters to GitOps Runtimes]({{site.baseurl}}/docs/installation/gitops/managed-cluster/)
+[Shared configuration repo for GitOps Runtimes]({{site.baseurl}}/docs/reference/shared-configuration)
+
+
diff --git a/_docs/installation/gitops/upgrade-gitops-cli.md b/_docs/installation/gitops/upgrade-gitops-cli.md
new file mode 100644
index 000000000..5d565bb35
--- /dev/null
+++ b/_docs/installation/gitops/upgrade-gitops-cli.md
@@ -0,0 +1,88 @@
+---
+title: "Download/upgrade GitOps CLI"
+description: "Have the latest version of the GitOps CLI"
+group: installation
+sub_group: gitops
+toc: true
+---
+
+You need the Codefresh CLI to install and upgrade Hybrid GitOps Runtimes, and get access to all the newest features.
+For the initial download, you need to generate an API key and create the API authentication context, which you do from the UI.
+When newer versions are available, the CLI automatically notifies you through a banner that an upgrade is required. You can use the existing API credentials for the upgrade.
+
+
+## GitOps CLI installation modes
+The table lists the modes available to install the GitOps CLI.
+
+{: .table .table-bordered .table-hover}
+| Install mode | OS | Commands |
+| -------------- | ----------| ----------|
+| `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`|````
+
+## Download the GitOps CLI
+Download the GitOps CLI using the option that best suits you: `curl`, `brew`, or standard download.
+If you are not sure which OS to select for `curl`, simply select one, and Codefresh automatically identifies and selects the right OS for CLI installation.
+
+1. Do one of the following:
+ * For first-time installation, go to the Welcome page, select **+ Install Runtime**.
+ * If you have provisioned a GitOps Runtime, in the Codefresh UI, go to [GitOps Runtimes](https://g.codefresh.io/2.0/account-settings/runtimes){:target="\_blank"}, and select **+ Add Runtime**.
+1. Install the Codefresh CLI:
+ * Select one of the installation modes.
+ * Generate the API key.
+ * Create the authentication context:
+ `cf config create-context codefresh --api-key `
+
+
+ {% include
+ image.html
+ lightbox="true"
+ file="/images/runtime/gitops-cli-download.png"
+ url="/images/runtime/gitops-cli-download.png"
+ alt="Download GitOps CLI"
+ caption="Download GitOps CLIe"
+ max-width="30%"
+ %}
+
+
+{::nomarkdown}
+
+{:/}
+
+
+## Upgrade the GitOps CLI
+
+The GitOps CLI automatically self-checks its version, and if a newer version is available, prints a banner with the notification that upgrade is required.
+
+ {% include
+ image.html
+ lightbox="true"
+ file="/images/runtime/cli-upgrade-banner.png"
+ url="/images/runtime/cli-upgrade-banner.png"
+ alt="Upgrade banner for GitOps CLI"
+ caption="Upgrade banner for GitOps CLI"
+ max-width="40%"
+ %}
+
+
+You can upgrade to a specific version if you so require, or download the latest version to an output folder to upgrade at your convenience.
+
+
+* Do any of the following:
+ * To upgrade to the latest version, run:
+ `cf upgrade`
+ * To upgrade to a specific version, even an older version, run:
+ `cf upgrade --version v`
+ where:
+ `
{:/} in DORA metrics, displays DORA 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 are key to performance insights with DORA metrics. The metrics are 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
+
+>Tip:
+ Remember that the graphs for the DORA metrics reflect metrics of application deployments, not workflows.
+
+### Deployment Frequency
+ The frequency at which applications are deployed to production, including both successful (Healthy) and failed (Degraded), deployments. A deployment is considered an Argo CD sync where there was a change in the application source code that resulted in a new deployment of the application to production.
+
+ The X-axis charts the time based on the granularity selected, and the Y-axis charts the number of deployments. The number shown on the top right is the average deployment frequency based on granularity.
+
+### Lead Time for Changes
+ The average number of days from the first commit for a PR (pull request) until the deployment date for the same PR. The key term here is _deployment_. Lead Time for Changes considers only those changes to workflows that result in a deployment. Making a change to a repo that does not result in a deployment is not included when calculating Lead Time for Changes.
+
+ The X-axis charts the time based on the granularity selected, 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.
+
+### Change Failure Rate
+ The failure or rollback rate in percentage for applications whose health status changed to Degraded on deployment. The key term here is _on deployment_. For example, bumping an image tag with one that does not exist, results in the application being Degraded on deployment, and designated as failed.
+
+
+ The Change Failure Rate is derived by dividing the number of Degraded (failed/rollback) deployments with the total number of deployments.
+ The X-axis charts the time based on the granularity selected, 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.
+
+### Time to Restore Service
+ The average number of hours taken for the status of Degraded deployments to return to Healthy. Again, similar to the Change Failure Rate, Time to Restore Service includes only deployments that became Degraded. It is derived by dividing the total number of hours for all Degraded deployments to return to Healthy by the total number of Degraded deployments.
+
+ 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.
+
+## Related articles
+[GitOps Overview dashboard]({{site.baseurl}}/docs/dashboards/home-dashboard)
+[Monitoring applications]({{site.baseurl}}/docs/deployments/gitops/applications-dashboard/)
+
diff --git a/_docs/dashboards/home-dashboard.md b/_docs/dashboards/home-dashboard.md
new file mode 100644
index 000000000..ba618ab85
--- /dev/null
+++ b/_docs/dashboards/home-dashboard.md
@@ -0,0 +1,118 @@
+---
+title: "GitOps Overview dashboard"
+description: ""
+group: dashboards
+toc: true
+---
+
+Get a global picture of runtimes, managed clusters, deployments, and applications in the GitOps Overview dashboard. Get system-wide visualization in real-time for GitOps.
+
+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/gitops-overview-dashboard.png"
+ url="/images/reporting/gitops-overview-dashboard.png"
+ alt="GitOps Overview dashboard: Global enterprise analytics for GitOps"
+ caption="GitOps Overview dashboard: Global enterprise analytics for GitOps"
+ max-width="70%"
+ %}
+
+### Global filters
+Filter the view in the GitOps Overview dashboard by runtimes and date range.
+
+{% include
+ image.html
+ lightbox="true"
+ file="/images/reporting/global-filters.png"
+ url="/images/reporting/global-filters.png"
+ alt="GitOps Overview dashboard: Global filters"
+ caption="GitOps Overview 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 GitOps Overview dashboard"
+ caption="Runtimes and Managed Clusters in the GitOps Overview dashboard"
+ max-width="80%"
+ %}
+
+{: .table .table-bordered .table-hover}
+| Item | Description |
+| ------------------------| ---------------- |
+|**Runtimes** | Identify failed runtimes.|
+|**Managed Clusters** |{::nomarkdown} 
{:/}| Star applications as favorites and view only the starred applications.{::nomarkdown}
.
{:/} |
+| **Progressing** | Resource is not healthy but can become healthy before the timeout occurs.| {::nomarkdown}
{:/} |
+| **Suspended** | Resource is not functioning, and is either suspended or paused. For example, Cron job or a canary rollout.| {::nomarkdown}
{:/} |
+| **Missing** | Resource is not present on the cluster. |{::nomarkdown}
{:/} |
+| **Degraded** | Resource is not healthy, or a timeout occurred before it could reach a healthy status.| {::nomarkdown}
{:/} |
+| **Unknown** | Resource does not have a health status, or the health status is not tracked in Argo CD. For example,`ConfigMaps` resource types. | {::nomarkdown}
{:/} |
+
+
+See also [Argo CD's set of health checks](https://argo-cd.readthedocs.io/en/stable/operator-manual/health/){:target="\_blank"}.
+
+
+
+### 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).
+
+The table describes the possible sync statuses for an application resource, and its representation in the Tree view.
+
+{: .table .table-bordered .table-hover}
+| Sync state | Description |Display in Tree view |
+| -------------- | ---------- | ---------- |
+| **Synced** | The live state of the resource on the cluster is identical to the desired state in Git.| {::nomarkdown}
{:/} |
+| **Syncing** | The live state of the resource was not identical to the desired state, and is currently being synced.| {::nomarkdown}
{:/} |
+| **Out-of-Sync** | {::nomarkdown}The live state is not identical to the desired state.
{:/} |
+| **Unknown** | The sync status could not be determined. | {::nomarkdown}
{:/} |
+
+
+> 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
+
+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.
+
+> To view information for the application resource, select the application node in Tree View. See [Application information](#view-deployment-and-configuration-info-for-selected-application).
+
+
+{% include
+image.html
+lightbox="true"
+file="/images/applications/current-state-resource-summary.png"
+url="/images/applications/current-state-resource-summary.png"
+alt="Current State Tree view: Resource tooltip"
+caption="Current State Tree view: Resource tooltip"
+max-width="50%"
+%}
+
+Here's what you can see and do in the Summary tab:
+> Press Ctrl/Command F to search for strings in the manifest.
+
+* Desired and Live states of the resource manifest:
+ * Managed resources, stored in Git repositories and using Git as the single source of truth, show both the Desired (Git) and the Live (cluster) states.
+ If there are discrepancies between them, the Diff view is displayed, highlighting the differences in both versions for comparison.
+ * Resources that are not stored in Git but live in the cluster, show only the Live state.
+* Share resource details: Copy the URL and send to others in your organization to share the resource details for collaborative review and analysis. Pasting the URL in a browser opens to the same view of the resource.
+* Hide Managed Fields: In the Live state version of the manifest, you can hide managed-field information from the manifest. Managed-fields show information on which field manager manages the field, after Kubernetes introduced `Server Side Apply`. For more information, see [Field Management](https://kubernetes.io/docs/reference/using-api/server-side-apply/#field-management){:target="\_blank"}.
+
+{::nomarkdown}
+
{:/}| Resume a step that has been paused indefinitely. |
+| **Skip step** {::nomarkdown}
{:/} | Skip execution of current step. Such steps are marked as Skipped in the rollout visualization. |
+| **Promote full rollout** {::nomarkdown}
{:/} | Skip remaining pause, traffic routing, and analysis steps, and deploy the current release. |
+
+
+
+#### 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"}.
+
+If you are running Background Analysis for example, the first step shows the list of analysis metrics.
+
+{% include
+image.html
+lightbox="true"
+file="/images/applications/app-rollout-analysis-template-step.png"
+url="/images/applications/app-rollout-analysis-template-step.png"
+alt="Rollout: Analysis Metrics in Background Analysis"
+caption="Analysis Template: Analysis Metrics in Background Analysis"
+max-width="50%"
+%}
+
+Click the metric link in the step.
+
+{% include
+image.html
+lightbox="true"
+file="/images/applications/app-rollout-run-results-manifest.png"
+url="/images/applications/app-rollout-run-results-manifest.png"
+alt="Analysis Template: Run Results and Manifest for Analysis Metric"
+caption="Analysis Template: Run Results and Manifest for Analysis Metric"
+max-width="50%"
+%}
+
+
+## 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.
+
+For more information, see the official documentation on [Services](https://kubernetes.io/docs/concepts/services-networking/service/){:target="\_blank"}.
+
+{% include
+image.html
+lightbox="true"
+file="/images/applications/apps-dashboard-services.png"
+url="/images/applications/apps-dashboard-services.png"
+alt="GitOps Apps dashboard: Services tab"
+caption="GitOps Apps 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-application)
+[GitOps Overview dashboard]({{site.baseurl}}/docs/dashboards/home-dashboard)
+[DORA metrics]({{site.baseurl}}/docs/dashboards/dora-metrics/)
+
+
diff --git a/_docs/deployments/gitops/create-application.md b/_docs/deployments/gitops/create-application.md
new file mode 100644
index 000000000..b028f438c
--- /dev/null
+++ b/_docs/deployments/gitops/create-application.md
@@ -0,0 +1,258 @@
+---
+title: "Creating GitOps applications"
+description: ""
+group: deployments
+sub_group: gitops
+toc: true
+---
+
+
+
+Codefresh provides all the options and functionality to create and manage Argo CD applications in the Codefresh UI.
+* Create Argo CD applications that are fully GitOps compliant, from generating the application configuration manifest, committing it to Git, and syncing and deploying to the cluster.
+ Creating an application in Codefresh includes:
+ * Application definitions
+ * General configuration settings
+ * Advanced configuration settings
+
+ The Create application wizard guides you through the process of creating an application. For how-to information, see [Create an application](#create-an-application).
+ For example Argo CD applications, see this [repo](https://github.com/oleksandr-codefresh/argocd-example-apps){:target="_blank"}.
+
+* Edit and delete applications
+ Once the application is created and synced to the cluster, it is displayed in the GitOps Apps 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 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.
+
+{% include
+ image.html
+ lightbox="true"
+ file="/images/applications/add-app-definitions.png"
+ url="/images/applications/add-app-definitions.png"
+ alt="Application definitions"
+ caption="Application definitions"
+ max-width="50%"
+ %}
+
+
+## Application: General configuration settings
+
+General configuration settings define the source, destination, and sync policies for the application.
+
+{% include
+ image.html
+ lightbox="true"
+ file="/images/applications/add-app-general-settings.png"
+ url="/images/applications/add-app-general-settings.png"
+ alt="General configuration settings"
+ caption="General configuration settings"
+ max-width="70%"
+ %}
+
+### Source
+The Git repository to be tracked for changes to the application's source code.
+{::nomarkdown}
{:/}.
+ List View: Select the **Managed Clusters** tab, and then select **+ Add Cluster**.
+1. In the Add Managed Cluster panel, copy and run the command:
+ `cf cluster add [runtime-name] [--labels label-key=label-value] [--annotations annotation-key=annotation-value][--dry-run]`
+ where:
+ * `runtime-name` is the name of the Runtime to which to add the cluster.
+ * `--labels` is optional, and required to add labels to the cluster. When defined, add a label in the format `label-key=label-value`. Separate multiple labels with `commas`.
+ * `--annotations` is optional, and required to add annotations to the cluster. When defined, add an annotation in the format `annotation-key=annotation-value`. Separate multiple annotations with `commas`.
+ * `--dry-run` is optional, and required if you want to generate a list of YAML manifests that you can redirect and apply manually with `kubectl`.
+
+
+ {% include
+ image.html
+ lightbox="true"
+ file="/images/runtime/managed-cluster-add-panel.png"
+ url="/images/runtime/managed-cluster-add-panel.png"
+ alt="Add Managed Cluster panel"
+ caption="Add Managed Cluster panel"
+ max-width="40%"
+%}
+
+{:start="5"}
+1. If you used `dry-run`, apply the generated manifests to the same target cluster on which you ran the command.
+ Here is an example of the YAML manifest generated with the `--dry-run` flag. Note that the example has placeholders, which are replaced with the actual values during the `--dry-run`.
+
+
+```yaml
+apiVersion: v1
+kind: ServiceAccount
+metadata:
+ name: argocd-manager
+ namespace: kube-system
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+ name: argocd-manager-role
+rules:
+- apiGroups:
+ - '*'
+ resources:
+ - '*'
+ verbs:
+ - '*'
+- nonResourceURLs:
+ - '*'
+ verbs:
+ - '*'
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRoleBinding
+metadata:
+ name: argocd-manager-role-binding
+roleRef:
+ apiGroup: rbac.authorization.k8s.io
+ kind: ClusterRole
+ name: argocd-manager-role
+subjects:
+- kind: ServiceAccount
+ name: argocd-manager
+ namespace: kube-system
+---
+apiVersion: v1
+data:
+ contextName: 
indicates health or sync errors in the runtime, or a managed cluster if one was added to the runtime. The runtime name is colored red.
indicates that the runtime is being synced to the cluster on which it is provisioned.
indicates the local cluster, always displayed as `in-cluster`. The in-cluster server URL is always set to `https://kubernetes.default.svc/`.
indicates a managed cluster.
select to add a new managed cluster.