localurl:/docs/dashboards/home-dashboard/

-title:DORA metrics

localurl:/docs/dashboards/dora-metrics/

-title:Images

localurl:/docs/dashboards/images/

-title:Helm best practices

localurl:/docs/ci-cd-guides/helm-best-practices/

-title:Templating for Kubernetes

localurl:/docs/ci-cd-guides/kubernetes-templating/

localurl:/docs/ci-cd-guides/kubernetes-templating/

-title:Image enrichment

localurl:/docs/ci-cd-guides/image-enrichment/

url:"/home-dashboard"

-title:DORA metrics

url:"/dora-metrics"

-title:Images

url:"/images"

url:"/helm-best-practices"

-title:Kubernetes templating

url:"/kubernetes-templating"

-title:Image enrichment

url:"/image-enrichment"

url:"/manage-application"

-title:Progressive delivery with GitOps

url:"/install-argo-rollouts"

-title:Images for GitOps

url:"/images"

-title:Pipelines

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 (timestamp, hash, size etc.)

With Codefresh you can enrich the basic information reported with the image with issue-tracking metadata and annotations.

For example you can mark images with 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)

Complete these steps to see images in the Images dashboard.

1. (Mandatory) Build and push the Docker image

* Codefresh pipelines

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

{:start="2"}

1. (Mandatory) GitOps: 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).

{:start="3"}

1. (Mandatory) GitOps: Report image information to Codefresh

This is the equivalent to pushing the image in Codefresh pipelines.

{:start="4"}

1. (Optional) Enrich image with annotations and metadata

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.

* Codefresh pipelines

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.

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.

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.

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.

The Git repository to be tracked for changes to the application's source code.

{::nomarkdown}<ul> <li><b>ArgoCD Project</b>: 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 <span style="font-family: var(--font-family-monospace); font-size: 87.5%; color: #ad6800; background-color: #fffbe6">default</span> project, which is created automatically by Argo CD and has no restrictions. </br>For more information, see Argo CD's documentation on <a href="https://argo-cd.readthedocs.io/en/stable/user-guide/projects/#projects" target="\_blank">Projects</a>.</li> <li><b>Repository URL</b>: 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 <span style="font-family: var(--font-family-monospace); font-size: 87.5%; color: #ad6800; background-color: #fffbe6">default</span> project, make sure that the repo has the correct access roles for your application.<ul><li><b>Revision and Path</b>: Applies to Git repositories. </li><li><b>Chart</b>: Applies to Helm repositories. The name of the Helm package with all the resource definitions for the application, and the version. </li></ul>For more information, see <a href="https://argo-cd.readthedocs.io/en/stable/user-guide/tracking_strategies/" target="\_blank">Tracking and Deployment Strategies</a>.</li></ul> {:/}

{::nomarkdown}<ul> <li><b>Repository URL</b>: 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 <spanstyle="font-family:var(--font-family-monospace);font-size:87.5%;color:#ad6800;background-color:#fffbe6">default</span> project, make sure that the repo has the correct access roles for your application.<ul><li><b>Revision and Path</b>: Applies to Git repositories. </li><li><b>Chart</b>: Applies to Helm repositories. The name of the Helm package with all the resource definitions for the application, and the version. </li></ul>For more information, see <ahref="https://argo-cd.readthedocs.io/en/stable/user-guide/tracking_strategies/"target="\_blank">Tracking and Deployment Strategies</a>.</li></ul> {:/}

{::nomarkdown}

<br>

max-width="70%"

%}

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"}.

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"}.<!---(https://kubernetes.io/docs/concepts/architecture/garbage-collection/#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.

***Non-cascading**

When selected, Kubernetes deletes only the application and not its resources.

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"}.