- 44.228.66.171

- 44.238.167.159

- 44.237.63.217

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

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

%}

{% endraw %}

{% endhighlight %}

For production environments, create a service account and/or role for Codefresh access.

Codefresh needs these minimum permissions to work with the cluster:

{% 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.

{% 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 %}

<br />

1. Select the appropriate cluster if you have more than one:

{% highlight shell %}

{% raw %}

kubectl config use-context <my-cluster-name>

{% endraw %}

{% endhighlight %}

1. Create the Codefresh user/role:

{% highlight shell %}

{% raw %}

kubectl apply -f codefresh-role-sa-bind.yml

{% endraw %}

{% endhighlight %}

1. Finally run the following commands, and copy-paste the results to the respective Codefresh field in the UI:

{% 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 %}

{% highlight shell %}

{% raw %}

echo $(kubectl get secret -n kube-system -o go-template=‘{{index .data “ca.crt” }}’ codefresh-user-token)

{% endraw %}

{% endhighlight %}

{% highlight shell %}

{% raw %}

echo $(kubectl get secret -n kube-system -o go-template=‘{{index .data “token” }}’ codefresh-user-token)

{% endraw %}

{% endhighlight %}

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

Codefresh offers several metrics for pipelinesteps that allow you to get a better overviewon the resources

Codefresh offers several metrics forthepipeline, and forstepsin the pipeline,that allow you to get a better overviewof the resources

consumed by your pipeline.

At the most basic level Codefresh will show some quick metrics while the pipeline is running that include

**Pipeline metrics**

At the most basic level, Codefresh displays quick metrics while the pipeline is running that include

memory consumed and size of logs:

{% include

image.html

lightbox="true"

file="/images/pipeline/monitoring/quick-pipeline-metrics.png"

url="/images/pipeline/monitoring/quick-pipeline-metrics.png"

alt="Pipelinerunningmetrics"

caption="Pipelinerunningmetrics"

alt="Metrics forrunningpipeline"

caption="Metrics forrunningpipeline"

max-width="70%"

%}

You can then get the memory usage for the whole pipeline by clicking on the metrics tab at the bottom of the screen.

* To view memory and disk usage for running or completed pipeline builds, click the**Metrics** tab at the bottom of the Build page.

* Memory usage: View memory usage (Y-axis) by time (X-axis) for the duration of the build.

* Disk usage: View disk usage (Y-axis) by time (X-axis) for the duration of the build. The red line is set at 90% of the maximum disk space.

To see the precise usage at different points in time, mouse over the dots.

Viewing the actual disk usage for a build during its run allows you to better gauge and define the[minimum disk space required for the build volume]({{site.baseurl}}/docs/pipelines/pipelines/#runtime).

{% include

image.html

lightbox="true"

file="/images/pipeline/monitoring/pipeline-metrics.png"

url="/images/pipeline/monitoring/pipeline-metrics.png"

alt="Pipeline detailedmetrics"

caption="Pipeline detailedmetrics"

alt="Detailedmetrics for pipelines"

caption="Detailedmetrics for pipelines"

max-width="70%"

%}

If you click on an individual step before clicking the*Metrics* tab you will get metrics for that specific step only.

**Pipeline-step metrics**

For step-specific metrics, first select the step, and then click the**Metrics** tab.

Step metrics are available for memory and CPU usage (not disk space).

{% include

- 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/pipelines/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/pipelines/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**Settings**, and then**Runtime**.

max-width="60%"

%}

|`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|

|`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|