How to build / test local changes to the provider.

[bradenwright-opunai]

I've run into this issue: https://github.com/Mastercard/terraform-provider-restapi/issues/178#issuecomment-1696624995 and there is a fix for it but it hasn't been released: https://github.com/Mastercard/terraform-provider-restapi/pull/226

I was trying to test the change locally b/c if the fix works I was going to publish my own version of the provider to Terraform Cloud/Enterprise and reference that. I'd really like to use this provider and this fix will allow me to do so.

I was able to get it to build on my mac and using the docker image / run command listed https://github.com/Mastercard/terraform-provider-restapi#development-environment-requirements

I'm building using go buiild from the top directory (I also tried go install). I was able to setup the binary for example, the test I was doing on my mac I was using ls ~/.terraform.d/plugins/example.com/test/restapi/1.18.2/darwin_arm64/terraform-provider-restapi I know its not the best name but I can alway update that later.

Here's my provider setup:

terraform {
  required_version = "1.2.4"

  required_providers {
    restapi = {
      version = "~> 1.18.2"
      source = "example.com/test/restapi"
    }
  }
}

provider "restapi" {
 uri = "http://localhost:53049" 
 write_returns_object = false
 create_returns_object = false
 debug = true
 headers = {
 "Authorization" = "Bearer ${local.auth_token}",
 "Content-Type" = "application/json"
 }
 create_method = "PUT"
 update_method = "PUT"
 destroy_method = "PUT"
}

and the resource / api call is:

resource "restapi_object" "system_settings_setup" {
  object_id = "systemsettingsetupid"
  path = "/api/v1/settings/system/system"
  data = file("${path.root}/files/system_settings.json")
  debug = true
}

When I try to apply the restapi_object I get the following error. Its worth noting when I ran go build locally it created the binary but it didn't see any output to STDOUT, I also tested I ran go build from the container (after cloning that get repo bc go get didn't work). Both created a binary even though there wasn't output. I was just first testing with the one I can run locally on my laptop (mac).

The error I'm getting when applying is:

restapi_object.system_settings_setup: Creating...
╷
│ Error: Provider produced inconsistent result after apply
│ 
│ When applying changes to restapi_object.system_settings_setup, provider "provider[\"example.com/test/restapi\"]" produced an unexpected new value: Root resource was present, but now absent.
│ 
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.

Any advice on how to build this module and test changes locally would be great. I did look over the README and search the issues, there was a reference to build.sh script, https://github.com/Mastercard/terraform-provider-restapi/issues/70#issuecomment-573181027 but I wasn't able to find the script. I looked around places like, https://github.com/Mastercard/terraform-provider-restapi/tree/master/scripts

I was going to test by building on my mac but ultimately I'll need to build this for linux as well. So I planed on building a binary locally on my mac and testing and then from there building in the docker linux container provided in the readme and using that to deploy via our GitLab-CI pipeline.

[bradenwright-opunai]

Any update on this, or anyone who can help out?

[bradenwright]

Any updates? It would be great to be able to move forward with this, since there was recently a release that didn't include the MR being merged/included

[arajitsamanta]

@bradenwright-opunai I could locally build and test changes to the provider by following steps

• Build and generate the binary by running go build in project root directory. This generates the binary terraform-provider-restapi
• Create a directory structure in ~/.terraform.d/plugins with pattern as ${host_name}/${namespace}/${type}/${version}/${os_arch}. For your example it would be something like

  example.com/test/restapi/1.8.2/darwin_arm64

• Copy the generated binary into ${host_name}/${namespace}/${type}/${version}/${os_arch}

I was able to build and test via this method in a linux vm by running fakeserver as backend.