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.

1. The Problem Project details: File size 5.6 GB File count 529352 Dockerfile 1 2 3 FROM golang:1.13 COPY ./ /go/src/code The build command and its output are as follows: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 time DOCKER_BUILDKIT=1 docker build --no-cache -t test:v3 -f Dockerfile .

Unlike on CentOS or Ubuntu, where we feel that mv is faster than cp, when you build an image with a Dockerfile, using Run cp is faster than Run mv. This post presents the test and verification data behind that. 1. Test Setup Machine environment Ubuntu 20.04.1 LTS 32C

1. Purpose of the Test Tune the parameters of the build cluster Probe the upper limit on the number of concurrent Tekton pipelines Give the optimal concurrency limit for a single cluster 2. Related Components and Machine Configuration Kubernetes version v1.21.4 Tekton version v0.24.1, kept consistent with production OpenEBS version localpv version 3.