Git Pull Support in Spinnaker

Aug 31, 2021 by German Muzquiz


Imagine you have a git repository where you store helm charts, kustomization files, and other files that Spinnaker uses to make deployments. Git repositories are usually small in size because only source code is stored in them, right?

The reality is that we often don’t have control over what is stored in a git repository, and they can grow pretty big. Maybe they contain several years of history. All of that makes cloning them a time-consuming operation. In Spinnaker versions prior to 1.26, every time a pipeline with a Bake (Manifest) stage that uses a gitrepo artifact to fetch files to deploy (either helm charts or kustomization files) runs, the following occurs:

  1. The Clouddriver service clones the git repository.
  2. The repo is packaged as a tarball and sent to the Rosco service
  3. The clone is deleted immediately.

Imagine git repositories that are several megabytes in size and the performance hit, leading to slow or failed deployments (because of timeouts).

User-uploaded Image


In Spinnaker 1.26, there’s a new feature that supports git pull behavior, so that the repository only gets cloned the first time (on demand). Subsequent requests for the same artifact just pull the latest changes from the git server. This feature improves performance dramatically for pipelines that reference large git repositories because Clouddriver no longer clones repositories every time it gets referenced. This feature is disabled by default.

To use the feature, you need to provide the following configuration in clouddriver-local.yml (Halyard) or in spec.spinnakerConfig.profiles.clouddriver (Operator):

    clone-retention-minutes: 10          # (Default: 0). How much time to keep clones. 0: no retention, -1: retain forever.
    clone-retention-max-bytes: 104857600 # (Default: 100 MB). Maximum amount of disk space to use for clones.
    clone-wait-lock-timeout-sec: 60      # (Default: 60). How long to wait for other threads to unlock the clone if several threads try to access it at the same time.
    clone-retention-check-ms: 60000      # (Default: 60000). How often to check if there are expired cloned that should be deleted.

Internally, clones are stored under /tmp with a folder name created by the SHA256 hash of this string: <repository-url>:<branch>. This makes it possible to locate existing clones for the same artifact since the name is composed of the URL and branch. If the branch is changed to something different, a new clone with a new hash gets created the first time that repo is used.

2021-08-17 17:04:59.022 DEBUG 1 --- [      MvcAsync3] c.n.s.c.a.gitRepo.GitRepoFileSystem      : Trying filesystem timed lock for (branch master), hash: 52d32666691e5ed374c4672bb46f95b528c27cbc2f8a37010ba919090c16004c for 60 seconds
2021-08-17 17:04:59.023 DEBUG 1 --- [      MvcAsync3] c.n.s.c.a.gitRepo.GitRepoFileSystem      : Lock  acquired for (branch master), hash 52d32666691e5ed374c4672bb46f95b528c27cbc2f8a37010ba919090c16004c, lock instance: [email protected][Locked by thread MvcAsync3]
2021-08-17 17:04:59.023 DEBUG 1 --- [      MvcAsync3] c.n.s.c.a.gitRepo.GitJobExecutor         : Executing command: "sh -c git symbolic-ref HEAD"
2021-08-17 17:04:59.032  INFO 1 --- [      MvcAsync3] c.n.s.c.a.gitRepo.GitJobExecutor         : Pulling git/repo into /tmp/gitrepos/52d32666691e5ed374c4672bb46f95b528c27cbc2f8a37010ba919090c16004c/spinnaker-scratchpad
2021-08-17 17:04:59.033 DEBUG 1 --- [      MvcAsync3] c.n.s.c.a.gitRepo.GitJobExecutor         : Executing command: "sh -c git pull"
2021-08-17 17:04:59.773  INFO 1 --- [      MvcAsync3] c.n.s.c.a.g.GitRepoArtifactCredentials   : Creating archive for git/repo
2021-08-17 17:04:59.773 DEBUG 1 --- [      MvcAsync3] c.n.s.c.a.gitRepo.GitJobExecutor         : Executing command: "sh -c git archive --format tgz --output /tmp/gitrepos/52d32666691e5ed374c4672bb46f95b528c27cbc2f8a37010ba919090c16004c/spinnaker-scratchpad.tgz master kustomize"
2021-08-17 17:04:59.782 DEBUG 1 --- [      MvcAsync3] c.n.s.c.a.gitRepo.GitRepoFileSystem      : Unlocking filesystem for (branch master), hash: 52d32666691e5ed374c4672bb46f95b528c27cbc2f8a37010ba919090c16004c
2021-08-17 17:04:59.783 DEBUG 1 --- [      MvcAsync3] c.n.s.c.a.gitRepo.GitRepoFileSystem      : Unlocking filesystem for hash 52d32666691e5ed374c4672bb46f95b528c27cbc2f8a37010ba919090c16004c, lock instance: [email protected][Locked by thread MvcAsync3]

Recently Published Posts

How Armory Uses Makelog to Drive New Feature Adoption from Day One

Jun 23, 2022

original post For teams that practice CI/CD and ship multiple times a day, waiting weeks to communicate these updates to customers defeats the purpose. After all, if a feature ships and nobody knows about it, did it really ship? You miss out on delivering value to customers sooner, learning which features they’re most excited about, […]

Read more

Armory Continuous Deployment-as-a-Service is Now Available

Jun 6, 2022

Over the last two years, our customers and prospects have said one thing: everyone wants Continuous Deployment, but adopting CD to production is too hard for many companies. Today we’re excited to announce that Armory is making production-grade continuous deployment available to all users of Kubernetes, regardless of size. Armory Continuous Deployment-as-a-Service has been in […]

Read more

Introducing OpenCost—An Open Source Project for Monitoring Kubernetes Spend

Jun 2, 2022

We are excited to share the launch of OpenCost, an open source project that provides real-time cost monitoring for teams running Kubernetes workloads.   As container and Kubernetes adoption continues to grow, navigating the complexities around measuring and allocating cost is becoming a business-critical challenge. A recent CNCF survey showed overspend is increasingly a problem for […]

Read more