Experiment: CAS

[yhakbar]

Share your feedback on the cas experiment.

If you believe that we're ready to end the experiment, and support the feature by default, share that opinion!

[FlorinAndrei]

How does CAS interact with parallel runs? I assume the cache is shared somehow, but what if two parallel runs want to create the same entry?

How are repo tag versions handled? E.g. I might use this block for some resource:

terraform {
  source = "${include.compcommon.locals.base_source_url}?ref=v5.21.0"
}

But I might use this block for some other resource:

terraform {
  source = "${include.compcommon.locals.base_source_url}?ref=v5.20.0"
}

[yhakbar]

How does CAS interact with parallel runs? I assume the cache is shared somehow, but what if two parallel runs want to create the same entry?

It's designed to be safe to run concurrently. The CAS store gets populated with every unique file cloned from Git for all runs being performed, and each unit gets an independent directory created with files that are hard links to the shared CAS store.

How are repo tag versions handled?

If you only change one file between version v5.20.0 and v5.21.0, then you'll have a copy of every file in v5.20.0 and an extra copy of the file that changed between them in your store.

[wjam]

How are SSH credentials picked up by the CAS experiment? I ask because attempting to run with --experiment cas added to the plan command line ends up with this comment for each unit:

CAS download failed: git_ls_remote: no matching references: no matching reference. Falling back to standard getter.

[yhakbar]

Hmmm... It should just be using the native git binary installed on your system to perform git ls-remote there. Is there any way you could provide a way to reproduce the error you're experiencing in a test repo referenced in an issue?

[wjam]

It's a private repository, so it'll take a bit to get a test repository.

But looking at the Terragrunt code, I think the issue is that the ref part of the module URL is a commit SHA rather than a branch or a tag. This'd cause issues if the SHA isn't at the HEAD of a branch. I'll need to be on my work laptop to confirm it, but I'm guessing this command doesn't include the SHA it's expecting to download.

terragrunt/internal/cas/git.go

Line 75 in 0b18393

cmd := g.prepareCommand(ctx, "ls-remote", args...)

[wjam]

This does appear to be the issue (again without having got round to creating a minimal test case).

If ref in the source URL was main, then the ls-remote command would be this, which succeeds:

$ git ls-remote [email protected]:Ortus-Telematics-Ltd/terraform-database-module.git main
ed89dc01d8c34c41e0abe72aacd1c6a7f592ba78        refs/heads/main

If the ref in the source URL was a specific SHA, then the ls-remote command will return this (note that Git doesn't error out, just returns nothing):

$ git ls-remote [email protected]:gruntwork-io/terragrunt.git 4d7bb3816c0dae06e7eee6541cecbd2a49d3c7c3

[atheiman]

Is this supported on Windows? Running w/ git-bash and the below terragrunt/terraform versions:

terragrunt version v0.92.1
Terraform v1.13.3
on windows_amd64

Running terragrunt run --experiment cas --all -- version to generate units and stacks and run terraform version in units below my current directory. This isnt speeding anything up compared to without --experiment cas. There are 3 units below $PWD, including stack { } and unit { } declarations all pulling from different paths within the same source git repo. I have unset any TG_ and TF_ env vars I typically use for this testing. Im also not seeing ~/.cache/terragrunt/cas generate, and dont see any mention of cas in the logs w/ --log-level debug.

Maybe there is more setup needed beyond just adding --experiment cas to my run --all command?