The alicloud provider move from to aliyun/alicloud, update to the latest
version.
Also introduct `deleteVendor` in `buildWithGoModule`, the vendor of
alicloud needs to be cleared due to openapiv2 API rename, or the
following error appears when building in case sensitive filesystems:
```
vendor/k8s.io/client-go/discovery/discovery_client.go:30:2: cannot find package "." in:
/build/source/vendor/github.com/googleapis/gnostic/openapiv2
```
Expose how the providers are being created. That way, users can more
easily extend or override the list of providers that they want to use.
For example, you need a new AWS provider version:
```nix
terraform.withPlugins (p: [
(p.mkProvider rec {
owner = "hashicorp";
provider-source-address = "registry.terraform.io/hashicorp/aws";
repo = "terraform-provider-aws";
rev = "v${version}";
sha256 = "0fa61i172maanxmxz28mj7mkgrs9a5bs61mlvb0d5y97lv6pm2xg";
vendorSha256 ="1s22k4b2zq5n0pz6iqbqsf6f7chsbvkpdn432rvyshcryxlklfvl";
version = "3.56.0";
})
])
```
This has graduated to beta, and the kubernetes_manifest resource has
moved into terraform-provider-kubernetes.
To use it, you must be enabled in the provider block:
```hcl
provider "kubernetes" {
experiments {
manifest_resource = true
}
config_path = "~/.kube/config"
}
```
Move the providerSourceAddress fallback to the terraform.withPlugins
function. Since plugins can be arbitrary derivations, there is no
guarantee that this attribute will be exposed.
While doing that I also cleaned the toDrv function to only pass
attributes to the builder which are required by the build.
The Terraform 0.13 fallback slug has changed from
`nixpkgs/<provider-owner>/<provider-name>` to `nixpkgs/<provider-name>`
as the owner is also not always available. As a nixpkgs user, all I know
is that the provider is in nixpkgs and his name, the owner information
is not necessarily easy to get by.
Add version to binaries produced via patchGoModVendor to allow run-time provider
version validation by terraform.
This was initially introduced in 4e63119c54 (terraform: add the version component to terraform provider paths (#34497), 2018-02-06)
but broken in 3e5149a79a (terraform-providers: fix the google and google-beta providers, 2020-03-24)
for terraform-providers.google and terraform-providers.google-beta, and in 20f55a9fc0 (terraform-providers.ibm: move to update-all script, 2020-04-26)
for terraform-providers.ibm.
This bumps the terraform provider to their latest version.
Hashicorp moved yet another provider to their organization
(`terraform-provider-helm`), so we need patch URLs in there as well.
The following proviers were not bumped:
- `google[-beta]`: It seems something changed again here with how
dependencies are provided.
- `nomad`: fails to build
- `lacework`: This one appeared fresh at `terraform-providers`, and
doesn't build (yet?)
I interpreted the purpose of stripping the first character from the 'version'
argument as an attempt to remove a prefixed 'v' (e.g. 'v1.0.0') from a version
tag. This works if the tag actually has a 'v' prefix, but also removes the first
character if version tags are not prefixed (e.g. '1.0.0').
Additionally, the 'v' was added again when specifying the `rev` for
`fetchFromGitHub` in default.nix. As described above, this did also not work
when provider repos did not prefix their version tags with 'v'.
I changed the implementation as follows:
- `version` and `rev` are stored inside data.nix
- `version` is used to declare the nix package version
- `rev` is used to fetch the proper git ref when building the package
- for determining `version`, an optional leading 'v' is trimmed from the tag
name
Now this has the implication that the latest tag must always be a release tag
when using the `update-all` script, but as the result of running `update-all`
should always be reviewed before submission, makes this appear a manageable
tradeoff to me.
