![Terraform Terraform logo](https://raw.githubusercontent.com/argoproj-labs/terraform-provider-argocd/master/.github/tf.png)
![Terraform Terraform logo](https://raw.githubusercontent.com/argoproj-labs/terraform-provider-argocd/master/.github/argo-cd.png)
The ArgoCD Terraform Provider provides lifecycle management of ArgoCD resources.
NB: The provider is not concerned with the installation/configuration of ArgoCD itself. To make use of the provider, you will need to have an existing ArgoCD deployment and, the ArgoCD API server must be accessible from where you are running Terraform.
Official documentation on how to use this provider can be found on the Terraform Registry.
This provider is compatible with at least the last 2 minor releases of ArgoCD
(e.g, ranging from 1.(n).m, to 1.(n-1).0, where n
is the latest available
minor version).
Older releases are not supported and some resources may not work as expected.
While that is true through the use of ArgoCD Kubernetes Custom Resources, there are some resources that simply cannot be managed using Kubernetes manifests, such as project roles JWTs whose respective lifecycles are better handled by a tool like Terraform. Even more so when you need to export these JWTs to another external system using Terraform, like a CI platform.
Existing Kubernetes providers do not patch arrays of objects, losing project role JWTs when doing small project changes just happen.
ArgoCD Kubernetes admission webhook controller is not as exhaustive as ArgoCD API validation, this can be seen with RBAC policies, where no validation occur when creating/patching a project.
Using Terraform to manage Kubernetes Custom Resource becomes increasingly difficult the further you use HCL2 DSL to merge different data structures and want to preserve type safety.
Whatever the Kubernetes CRD provider you are using, you will probably end up
using locals
and the yamlencode
function which does not preserve the
values' type. In these cases, not only the readability of your Terraform plan
will worsen, but you will also be losing some safeties that Terraform provides
in the process.
- Terraform (>= 1.0)
- Go (1.19)
- GNU Make
- golangci-lint (optional)
Contributions are welcome!
git clone
this repository andcd
into its directorymake build
will trigger the Golang build
The provided GNUmakefile
defines additional commands generally useful during
development, like for running tests, generating documentation, code formatting
and linting. Taking a look at it's content is recommended.
The acceptance tests run against a disposable ArgoCD installation within a Kind cluster. Other requirements are having a Docker daemon running and Kustomize installed.
make testacc_prepare_env
make testacc
make testacc_clean_env
This provider uses terraform-plugin-docs
to generate documentation and store it in the docs/
directory.
Once a release is cut, the Terraform Registry will download the documentation from docs/
and associate it with the release version. Read more about how this works on the
official page.
Use make generate
to ensure the documentation is regenerated with any changes.
If running tests and acceptance tests isn't enough, it's possible to set up a local terraform configuration to use a development builds of the provider. This can be achieved by leveraging the Terraform CLI configuration file development overrides.
First, use make install
to place a fresh development build of the provider in
your
${GOBIN}
(defaults to ${GOPATH}/bin
or ${HOME}/go/bin
if ${GOPATH}
is not set).
Repeat this every time you make changes to the provider locally.
Then, setup your environment following these instructions to make your local terraform use your local build.
- "too many open files": Running all acceptance tests in parallel (the default) may open a lot of files and sockets, therefore ensure your local workstation open files/sockets limits are tuned accordingly.