The Random provider supports the use of randomness within Terraform configurations. The provider resources can be used to generate a random id, integer, password, pet, shuffle (random permutation of a list of strings), string or uuid.
Documentation, questions and discussionsOfficial documentation on how to use this provider can be found on the Terraform Registry. In case of specific questions or discussions, please use the HashiCorp Terraform Providers Discuss forums, in accordance with HashiCorp Community Guidelines.
We also provide:
The remainder of this document will focus on the development aspects of the provider.
git clone this repository and cd into its directorymake build will trigger the Golang buildThe 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.
In order to test the provider, you can run
make test to run provider testsmake testacc to run provider acceptance testsIt's important to note that acceptance tests (testacc) will actually spawn terraform and the provider. Read more about they work on the official page.
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, in your ${HOME}/.terraformrc (Unix) / %APPDATA%\terraform.rc (Windows), a provider_installation that contains the following dev_overrides:
provider_installation {
dev_overrides {
"hashicorp/random" = "${GOBIN}" //< replace `${GOBIN}` with the actual path on your system
}
direct {}
}
Note that it's also possible to use a dedicated Terraform configuration file and invoke terraform while setting the environment variable TF_CLI_CONFIG_FILE=my_terraform_config_file.
Once the dev_overrides are in place, any local execution of terraform plan and terraform apply will use the version of the provider found in the given ${GOBIN} directory, instead of the one indicated in your terraform configuration.
This project uses GitHub Actions to realize its CI.
Sometimes it might be helpful to locally reproduce the behaviour of those actions, 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
The releasable builds are generated from the build GH workflow and the release/promotion process is completed via internal HashiCorp deployment tooling. Prior to release, the changelog should be updated in main with the changie tool, example:
changie batch 3.7.2 && changie merge
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4