The Guance Provider provides resources to manage Guance Cloud resources.

Documentation, questions, and discussions
Official documentation on how to use this provider can be found on the Terraform Registry.
The remainder of this document will focus on the development aspects of the provider.
The resource supports as follows:
- pipeline
- member group
- black list
- role
The data source supports as follows:
The region supports as follows:
- hangzhou
- ningxia
- guangzhou
- vnet
- hongkong
- oregon
- frankfurt
- singapore
If there are more resources you need, create an issue for free.
Compatibility
Compatibility table between this provider, the Terraform Plugin Protocol
version it implements, and Terraform:
Guance Provider |
Terraform Plugin Protocol |
Terraform |
>= 0.x |
6 |
>= 1.0 |
Details can be found by querying the Registry API
that return all the details about which versions are currently available for a particular provider.
Here are the details.
Requirements
Development
Generating documentation
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 ./hack/make gen:doc
to ensure the documentation is regenerated with any changes.
Using a development build
If running tests and acceptance tests aren't enough, it's possible to set up a local terraform configuration
to use a development build of the provider. This can be achieved by leveraging the Terraform CLI
configuration file development overrides.
First, use ./hack/make build: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 is every time you make changes to the provider locally.
Then, set up your environment following these instructions
to make you're local terraform use your local build.
Testing GitHub Actions
This project uses GitHub Actions to realize its CI.
Sometimes it might be helpful to reproduce the behavior of those actions locally,
and for this, we use act. Once installed, you can simulate the actions executed
when opening a PR with:
# List of workflows for the 'pull_request' action
$ act -l pull_request
# Execute the workflows associated with the `pull_request' action
$ act pull_request
Releasing
The release process is automated via GitHub Actions, and it's defined in the Workflow
release.yml.
Each release is cut by pushing a semantically versioned tag to the default branch.
License
Mozilla Public License v2.0