0.6.0 added support for Fedora CoreOS Config v1.1.0.
- Add Fedora CoreOS Config v1.1.0 support (#63)
- - Accept FCC v1.1.0 and output Ignition v3.1.0
- - Continue to support FCC v1.0.0 and output Ignition v3.0.0
- - Support merging FCC snippets into v1.0.0 or v1.1.0 FCC content
- - Note: Version skew among snippets and content is not supported
- Change Container Linux Config to render Ignition v2.3.0 (#60)
- Add zip archive format with signed checksum
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?)
Some terraform providers were moved to the `hashicorp` organization,
some are still in the `terraform-providers` organization.
GitHub doesn't show moved repositories when querying via the API (only
on the web interface). In addition, if there are more than 100 results
(there still are), we'd need to implement paging, which is cubersome in curl.
In addition to that, to look up tags, we used to creating a HTTP request
for each and every provider, which caused us to easily get blocked by
GitHubs rate-limiting.
Instead of all that, let's use `hub` (which implements paging) and the
GitHub's GraphQL endpoint to get a list all repositories for a given
organization AND the latest tag for each of them.
We post-process the output with `jq`.
This also removes the providers.txt and folds the data into the script.
The blacklist was becoming too annoying to handle as a config file.
For the whitelist, we still need to individually fetch tags.
Fixes#83215
Co-Authored-By: zimbatm <zimbatm@zimbatm.com>
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.
There ver very many conflicts, basically all due to
name -> pname+version. Fortunately, almost everything was auto-resolved
by kdiff3, and for now I just fixed up a couple evaluation problems,
as verified by the tarball job. There might be some fallback to these
conflicts, but I believe it should be minimal.
Hydra nixpkgs: ?compare=1538299
