Comments (9)
I confirm that this is working thanks :)
steps:
...
- uses: actions/cache@v2
name: cache plugins
with:
path: ${{ runner.temp }}/_github_home/.terraform.d/plugin-cache
key: ${{ runner.os }}-tf-${{ hashFiles('somepath/.terraform.lock.hcl') }}
...
Terraform init correctly shows that it is using the shared cache.
One note for cross-platform (mac/linux/windows) users though: you have to invoke a cross-platform providers lock command everytime you update your providers, as the .terraform.lock.hcl
is not cross-platform yet : terraform providers lock -platform=linux_amd64 -platform=darwin_amd64
from terraform-github-actions.
Provider caching should work automatically within the same job, using the shared docker action $HOME. This should have the same lifetime as the github.workspace
. Have you got an example where that doesn't work?
from terraform-github-actions.
Thanks for your quick reply, indeed I do, this does not seem to work:
steps:
- name: Checkout
uses: actions/checkout@v2
- uses: actions/cache@v2
name: cache plugins
with:
path: |
somepath/.terraform/modules
somepath/.terraform/providers
key: ${{ runner.os }}-tf-${{ hashFiles('somepath/.terraform.lock.hcl') }}
- name: terraform plan
uses: dflook/terraform-plan@v1
with:
path: somepath
Resulting cache size is always ~0 bytes.
from terraform-github-actions.
Using the non-docker, javascript hashicorp/setup-terraform@v1
action and running terraform init
results in a populated cache. I'm guessing this has to do with docker mounts.
from terraform-github-actions.
You see an empty cache because the terraform data directory is not at the path .terraform
- it's not in the workspace at all.
I don't think the cache action can be used with these actions.
The terraform binary and any providers are cached for the duration of a job run but there's no functionality to persist the cache between jobs.
from terraform-github-actions.
it actually is located at the path .terraform
if there is no explicit cache directory (env var or cli arg), the setup-terraform
javascript action not leveraging docker (with the same cache actions args) is caching providers and modules after a terraform init
run call.
I am not trying to persist the cache between jobs, but to use the cache persisted in a previous step of a same job in subsequent steps. I guess this is indeed not possible due to how docker mounts are shared with the host/runner. That's too bad!
from terraform-github-actions.
I think we might be talking about different things. You don't need to use the cache
action or setup-terraform
action with these actions. I don't know anything about setup-terraform
.
In these actions, the plug-in cache directory should be shared between steps of the same job. This only caches providers. It's not stored in the workspace.
The .terraform
directory is not shared between steps of the same job. It's not stored in the workspace, so can't be cached with thecache
action.
The .terraform
directory is initialised fresh by every action. It will use the plug-in cache for providers, but modules must be downloaded again.
from terraform-github-actions.
Thanks for the time you are spending on this issue, I appreciate it.
hashicorp/setup-terraform
is a js action meant to install Terraform binary onto the current runner's workspace and modify the environment PATH
so you can run terraform within the context of a runner (as in, not a docker container context), therefore you can leverage the cache
action.
What I mean by caching is to be able to use the providers and/or modules previously downloaded in another workflow instance of the same workflow definition. If the plug-in cache is indeed shared between subsequent steps of the same job within a single workflow instance, then the directory used within the container has to be mounted on the github runner, I would just need to find its path to leverage the cache
action I think.
from terraform-github-actions.
I think the cache directory will be at ${{ runner.temp }}/_github_home/.terraform.d/plugin-cache
in the runner filesystem, at least on github hosted runners. The /_github_home
part does not appear to be specified anywhere.
from terraform-github-actions.
Related Issues (20)
- Cannot run plan with S3 backend HOT 4
- Inability to trigger the action due to an alleged missing file HOT 5
- Terraform Plan action fails due to Unknown token: 15:19 IDENT confluent_service_account.app-producer.id error HOT 10
- "terraform-plan" fails with an error while using "terraform plan" succeeds HOT 2
- backend_config read as file in apply
- Ability to Share Plan Outputs Between Runs HOT 6
- Resources are not removed despite the action claiming otherwise HOT 2
- Issues in terraform version 1.6.0 HOT 1
- Support for Terraform 1.6 test framework HOT 1
- Terraform Cloud deploy with hard-coded workspace fails
- Add option to create new comments on following execution of a terraform operation HOT 3
- OpenTofu support HOT 5
- Terraform Plan Action failing on tf version 1.6.x showing S3 403 permission error
- terraform-plan error: The process '/usr/bin/git' failed with exit code 128 HOT 2
- Terraform Plan Fails on self-hosted runner - ls: cannot access '/github/home': No such file or directory HOT 12
- .tool-versions at workspace level doesn't work HOT 1
- Terraform Cloud backend requires manual "Confirm & Apply" for Terraform >= 1.6.0 HOT 6
- Add option for multiple SSH keys (GH deploy keys)
- auto apply if no resources changed HOT 1
- Impossible to update to a newer terraform version if only the GitHub Action is allowed to execute terraform HOT 8
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from terraform-github-actions.