The future

[mrolla]

Continuing the discussion started at #37 about merging efforts.

How do you suggest we proceed @TomTucka?

[bendrucker]

Notable differences, this project has:

• Tests
• Context support

tomtucka's adds:

• An env_vars map in circleci_project, which would conflict with circleci_environment_variable. The docs incorrectly show this as a block, FYI.

And removes:

• The ability to specify the organization in the resource, relying only on the provider config (I'm 👍🏻 to this)

So it seems to me this project is further along, with a decent number of users.

The poor support from CircleCI, both for their API itself and clients, is the biggest issue facing any/all providers here. Using multiple API clients in a single provider as part of a migration, e.g. community and official or multiple majors, is reasonably common, see one example:

https://github.com/DataDog/terraform-provider-datadog/blob/master/datadog/provider.go#L96-L98

I'm curious what actual features users want, and am inclined to work backwards to any gaps in the various API clients. I can see room for:

• circleci_project, as in tomtucka's provider, to "activate" (follow)
• circleci_checkout_key
• circleci_ssh_key

I don't have a burning need for the *_key resources right now, but it can make for some nice integrations, e.g. the ability to create a tls_private_key, pass the private side to CircleCI, and pass the public side to github_repository_deploy_key to set up write access for Circle -> GitHub.

[crisp2u]

Guys, following this with interest. I'm using now @TomTucka's provider for now but I would like to start using contexts also. Not trying to make things worse but there is also https://github.com/edahlseng/terraform-provider-circleci :)

[TomTucka]

Heya Folks 👋🏻 ,

Works been super busy, sorry for the late response!

I'd prefer to move forward with my version of the provider. Contexts are not yet supported via a go client which is why my project doesn't incorporate them as the Provider developer guide states that you should only use one library.

I've also now started using the v2 API. Hopefully, CircleCI will add support for contexts soon and we can then add these into the go-circleci library.

I'm currently backfilling the tests, hoping to have this done by Christmas. @bendrucker circleci_environment_variable is a separate resource it doesn't really conflict IMO. You can either specify env_vars in the circleci_project resource or have a resource per variable using circleci_environment_variable.

If all parties want to move forward with this, I'm happy to give @bendrucker and @mrolla contributor status on the repo

[bendrucker]

Contexts are not yet supported via a go client which is why my project doesn't incorporate them as the Provider developer guide states that you should only use one library.

As mentioned above, that's a reasonable default, but not a universally observed rule. Popular providers undergo transitions where certain resources adopt new API client functionality often.

I've also now started using the v2 API. Hopefully, CircleCI will add support for contexts soon and we can then add these into the go-circleci library.

https://circleci.com/docs/api/v2/#tag/Context

In "preview" but a complete API!

circleci_environment_variable is a separate resource it doesn't really conflict IMO. You can either specify env_vars in the circleci_project resource or have a resource per variable using circleci_environment_variable.

Terraform configuration strives to be a declarative representation of the remote resource. If you set env_vars to some map, that semantically means "these and only these are the env vars for this project." If you manually added an environment variable to the project in the UI, Terraform should prompt to remove it, converging the resource back to the declared state. The actual implementation is only capable of adding environment variables, and Read isn't implemented:

https://github.com/TomTucka/terraform-provider-circleci/blob/master/circleci/resource_circleci_project.go#L46-L49

Terraform does allow for the idea that you'd have an attribute and a discrete resource, but they should conflict such that you might have the following:

resource "circleci_project" "foo" {
  lifecycle {
    ignore_changes = [env_vars]
  }
}

resource "circleci_environment_variable" "foo" {
  project = circleci_project.foo.id
  name = "foo"
  value = "bar"
}

A common example of this is aws_security_group, which can specify inline ingress and egress blocks and aws_security_group_rule which can append individual rules to a security group but conflicts with ingress and egress blocks if that SG is defined in Terraform.

In any case, more than happy to help. My work uses this provider for contexts and their environment variables so that feature is the most important to me directly. But happy to do some general work as well for complete coverage. I think there's a good opportunity to make some breaking changes and release a new major version for your provider before we look at deprecating this one.