1. Introduction to Argo Argo is an open source project that provides a set of tools on Kubernetes for building and running applications. The core components of Argo mainly include the following: Argo CD Argo CD is a GitOps-based continuous delivery tool that allows users to declaratively manage the deployment of applications in a Kubernetes cluster.

In the client, we have already seen the Docker CLI passing credentials to the Docker Daemon via X-Registry-Config when sending the build context. But recent build feedback still shows some phenomena that cannot be explained. This post mainly runs some basic tests to make troubleshooting easier. 1. Building under host Docker The Docker Daemon is started with root privileges.

1. A Constrained Build Environment Cannot Meet Build Requirements Tekton is a CICD engine based on a Kubernetes cluster, and it is more cloud-native than Jenkins. In plain terms, that means it is easier to develop plugins for, easier to scale, easier to observe, and more fun. Because code can only be stored on the company intranet, the build cluster can only be deployed on the office intranet.

1. Symptom - Tekton’s Clone Task Is Slow When running the clone task, Tekton is very time-consuming; with multiple repositories it generally takes around 2 minutes 30 seconds. As shown below: A pipeline that only clones takes 2 minutes 16 seconds to run, while the clone script itself actually runs for only 1-3 seconds.

In a non-staged build scenario, when we use a container to build, we can mount the cache directory inside the container onto the build host, run the build task, and then copy the artifacts into the runtime image to produce the application image. But with a staged build, the build image and the runtime image live in the same Dockerfile, which makes it harder to optimize the caching of third-party dependencies.