Contributing
Refer to CONTRIBUTING.md.
Context
Terraform best practices suggest using an existing API client library rather than commingling client logic with Terraform provider logic. At this time, there does not appear to be a CircleCI v2 API client library. Fortunately, CircleCI publishes their OpenAPI v3 spec. This allows for the generation of client libraries. Although the resulting client code is included in this repository, such an approach seems spiritually consistent with the principle of separating the client logic from the provider. Of course, an official API client library would be better. If you want to see this happen, please upvote this item on CircleCI's ideas board.
As of this writing, CircleCI's OpenAPI spec needs cleansing before generating the client:
- removing preview paths
- making accommodation for the missing, non-preview
Project
tag
- removing
anyOf
from the spec because it leads to invalid go code GitHub issue
Prerequisites
- GNUmake 4.1 or greater- in order to use any make targets provided for convenience.
- jq- used while cleansing CircleCI's OpenAPI spec.
- docker or podman- used in the make recipes which validate the cleansed OpenAPI spec and generate go code from it.
- go 1.15
Refresh the Spec and Client
$ make generate_spec
$ make generate_client
Or if you use podman rather than docker:
$ make generate_spec container_runtime=podman
$ make generate_client container_runtime=podman
Build the provider
$ make build
Test the provider
Unit Tests
$ make test
Acceptance Tests
$ make acceptance_test
Note that the tests will fail unless you have set the environment variable CIRCLECI_API_KEY
with a valid API key. Additionally, this defaults to target a specific CircleCI project for testing. Unless you have access to that project, the tests will fail. You can override the target project like so:
$ make acceptance_test target="<a valid CircleCI project slug for a project to which you have access>"