Direct upgrade will most likely fail with:

`helm.go:84:[debug] cannot patch "cf-nats" with kind StatefulSet: StatefulSet.apps "cf-nats" is invalid: spec: Forbidden: updates to statefulset spec for fields other than 'replicas', 'template', 'updateStrategy' and 'minReadySeconds' are forbidden`

* Saves all the Kubernetes manifests used by the installer locally in the folder`./codefresh_manifests`.

* Installs the Agent and YAML file describing the runtime.

1. Reply to the prompts as needed:

{% include image.html

- 107.21.238.215

- 18.209.185.91

- 44.228.66.171

- 44.238.167.159

- 44.237.63.217

- 52.6.148.44

- 52.73.90.9

- 52.72.0.154

- 52.73.76.60

- 3.228.62.77

- 44.205.132.73

- 34.235.30.144

- 54.160.88.80

All the IPs are NAT gateways, and therefore you only need to enable specific IPs instead of ranges.

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.

{% endraw %}

{% endhighlight %}

Note: we do recommend you only use this option as a last resort. You should not hardcode "localhost" as a requirement in your services as

it adds extra constraints with integration tests (and especially with dynamic test environments).

*[Integration tests]({{site.baseurl}}/docs/testing/integration-tests/)

*[Integration test with database]({{site.baseurl}}/docs/yaml-examples/examples/integration-tests-with-database/)

*[Creating Compositions]({{site.baseurl}}/docs/on-demand-test-environment/create-composition/)

Clones a Git repository to the filesystem.

A pipeline can have any number of git clone steps (even none). You cancheckout 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.

A pipeline can have any number of git clone steps (even none). You cancheck 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.

description: Step description

working_directory: /path

repo: owner/repo

depth: 3

git: my-git-provider

revision: abcdef12345'

use_proxy: false

{: .table .table-bordered .table-hover}

| Field| Description| Required/Optional/Default|

| ------------------------------------------| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -------------------------|

|`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`| path of the repository without the domain name in the form of`my_username/my_repo`| Required|

|`repo`|Thepath of the repository without the domain name in the form of`my_username/my_repo`. {::nomarkdown} <br>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|

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%"

%}

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.

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="60%"

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 public URL. Notice that a raw URL is needed in the case of GitHub.

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 Concurrency**: the maximum number of concurrent builds (0-14 or unlimited) -- set this when your pipeline has only one trigger

-**Pipeline Concurrency**: the maximum number of concurrent builds (0-30 or unlimited) -- set this when your pipeline has only one trigger

-**Trigger Concurrency**: the maximum number of concurrent builds per trigger (1-15 or unlimited) -- set this when your pipeline has multiple triggers

-**Branch Concurrency**: the maximum number of concurrent builds per branch (1-15 or unlimited) -- set this when your pipeline can build different branches

-**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)

- Medium (recommended 3-4 steps)

- Large (recommended 5-6 steps)

Set the disk space you need for the pipeline's build volume. Configuring the disk space per pipeline build volume prevents out-of-space scenarios that lead to failed builds. The disk space set for the pipeline is inherited by all the builds run for the pipeline.

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.

Codefresh calculates the available range according tothe disk size, and automatically sets the disk space for the build volume to 70% ofthetotal disk space. You caneitherretain the default allocationorchange as needed.

To prevent out-of-space scenarios that lead tofailed builds, you can set theminimumdisk spaceyou needfor thepipeline'sbuild volume. Definingtheminimum disk space ensures that Codefresh assignseithera cached disk with sufficient disk spaceora 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 disk space.

1. Select the pipeline for which to set theminimumdisk space.

1. Select**Settings**, and then**Runtime**.

1. Enable**Set minimum required disk space** and either retain the default displayed or change as needed.

1. Enable**Set minimum required disk space**, and either retain the default displayed or change as needed.

{% include

image.html

max-width="60%"

%}

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.

To create an effective CI/CD process, it should be possible to triggeraCodefreshpipeline execution not only on code repository events (like`push` or`PR`), but also on any "interesting" CD-related event, coming from some external system.

To create an effective CI/CD process, it should be possible to trigger Codefreshpipelines 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 butitalso offers you the capability to trigger them with completely separate mechanisms.

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.

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"

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.

*[Creating pipelines]({{site.baseurl}}/docs/configure-ci-cd-pipeline/pipelines/)