Skip to main content

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: java.util.concurrent.loc[email protected][Locked by thread MvcAsync3]

Recently Published Posts

Welcoming 2022: Reflecting and looking forward

Dec 22, 2021
by Jim Douglas

Nearly all cultures globally have some form of celebration marking the Winter Solstice. Common threads found in most observances of the annual event are celebration of family and friends (living and past), reflection of the past year, and some form of giving thanks for continued health and sustenance. Exiting 2021, said celebrations would seem especially […]

Read more

Resiliency and Load distribution

Dec 16, 2021
by Daniel Gonzalez

Introduction When scaling a network service, there are always two concerns: resiliency and load distribution, to understand these concepts let us first understand the broader term “Redundancy”. Redundancy is the duplication of a component to increase reliability of the system, usually in the form of a backup, fail-safe, or to improve actual system performance. Resiliency […]

Read more

CVE-2021-44228 – log4j (Log4Shell) – an analysis

Dec 10, 2021
by Jason McIntosh

Today marked a 0-day disclosure of a rather nasty vulnerability in one of the most commonly used frameworks for logging – log4j.  This one is nasty on multiple levels.  Note that Armory Enterprise is NOT affected by this vulnerability.  The impact on this vulnerability is likely huge and is already being exploited.  Additionally it can […]

Read more