has joined #terraform

has joined #terraform

:wave:

This is awesome, thanks for creating the channel!

I've been toying with the TF module recently, it's going to be great for managing the tool and approvals via PRs. I've got a few questions about it though

I had a few issues with state; I couldn't really sync the remote state even using the `refresh` command, and ended up importing resources one by one until I got things in line. If not in sync, TF tries to create existing resources and fails when applying. Do you know of any known issues there?

I can reproduce it consistently by removing the `tfstate` file (which would be a similar case to running this in a CI setting, as we shouldn't be committing state files to source control).

Interesting. If the resources already exist, by default the provider will error unless they are imported. Once you have a correct state file, presumably you can use the remote state management features - is that your plan?

I think we could enhance the refresh capabilities though, which might simplify your use case?

Thanks - Yeah, you're right, I should just use remote state and go with that for CI. I thought refresh would sync everything up but it only does it for resources that are already bound in the state file, so that was just a misunderstanding on my part.

Cool np, let me know if you have other questions!

Hi again - Noob question regarding https://www.terraform.io/docs/language/modules/develop/providers.html#implicit-provider-inheritance. I'd like to start separating my resources into modules (e.g: users, teams, etc) so that I don't have all the config in a single file. I did a quick test creating a module for teams, but I'm getting this error when trying to run it: ```Error: Failed to query available provider packages Could not retrieve the list of available versions for provider hashicorp/pact: provider registry http://registry.terraform.io does not have a provider named http://registry.terraform.io/hashicorp/pact Did you intend to use pactflow/pact? If so, you must specify that source address in each module which requires that provider. To see which modules are currently depending on hashicorp/pact, run the following command: terraform providers```

A simplified version of what I've got in my main file is: ```terraform { required_providers { pact = { source = "pactflow/pact" version = "0.2.0" } } } variable "ACCESS_TOKEN" { type = string sensitive = true } provider "pact" { host = "(my host url)" access_token = var.ACCESS_TOKEN } ... module "teams" { source = "./modules/teams" }``` And the module just: ```resource "pact_team" "tomato" { name = "Tomato" users = [] }``` I would've expected that the module would inherit the provider, but the error is telling me otherwise. Any ideas?

^ I think I'll just create separate files for the different resources at the top level instead of creating modules which in retrospect seems like a bad idea for this use case.

Sorry, it's been a while since I've used terraform in a bigger project where that's be needed

Hi team - Happy new year! I've been troubleshooting a few issues I had and found a few odd things, I'd appreciate some help (and yeah, sorry for bringing the first problems of the year to this channel :grimacing:)

In both of the issues I'll describe the problem is that `terraform apply` reports changes that are not actually applied.

The first change is changing the `repository_url` of one of the applications. `terraform apply` shows: ``` # pact_application.fruit will be updated in-place ~ resource "pact_application" "fruit" { id = "Fruit" name = "Fruit" ~ repository_url = "https://github.com/company/admin" -> "https://github.dev.xero.com/Xero/QE-Pactflow-Management" }``` After reporting a successful apply command, the resource still has the old url. Looking at the audit events, I found that for some reason the PATCH request has the wrong path, looks like an escaped formatting sequence issue maybe (`%25s`)? ```{ "uuid": "O2VY9vwUAaOBDJMDuOrLmg", "timestamp": "2021-12-10T00:52:32.201+00:00", "type": "pacticipant", "userUUID": "56b15671-a578-4bc6-a858-b4792433ba3e", "name": "Jonatan Jaworski", "tokenUUID": "FqhmJO3ulus-mJ99hGSdKA", "payload": { "path": "/pacticipants/%25s", "queryString": "", "method": "PATCH", "userAgent": "go-pact/0.0.1", "referer": null, "remoteHost": null, "remoteAddress": "10.2.1.48", "requestId": "03c91bf3e3345c024129f7d057d7fe28" }, "response": { "status": 200 } }``` As a result, I get a new application created ("%25s") instead of updating the existing one. I don't really know when it goes wrong like that. I also found a log that goes: ```2022-01-10T11:55:37.780+1300 [WARN] Provider "http://registry.terraform.io/pactflow/pact" produced an unexpected new value for pact_application.fruit during refresh. - .repository_url: was cty.StringVal("https://github.dev.xero.com/Xero/QE-Pactflow-Management"), but now cty.StringVal("https://github.com/company/admin")``` Which to me confirms that TF was expecting the change to be applied when refreshing state but it wasn't.

The second change was to add a role to an existing user. The delta is reported correctly: ```# pact_user.liam_scott will be updated in-place ~ resource "pact_user" "liam_scott" { id = "e9fb21e1-d84c-45b4-88fe-d2f30d08cebe" name = "Liam Scott" ~ roles = [ "e9282e22-416b-11ea-a16e-57ee1bb61d18", + "d635f960-88f2-4f13-8043-4641a02dffa0", ] # (4 unchanged attributes hidden) }``` But then there's no audit entry for that update, all the requests concerning that user are GET. Looking at the logs, I found this: ```2022-01-10T11:55:37.780+1300 [WARN] Provider "http://registry.terraform.io/pactflow/pact" produced an unexpected new value for pact_user.liam_scott during refresh. - .roles: element 1 has vanished``` I don't know what's going on there.

I also found a couple of minor things that I don't think are having any effect in my project, but probably worth looking at: Possible issue with optional arguments that are not provided (not sure if this is just user error, it goes away when providing a value - an empty string in this case): ```2022-01-10T11:55:37.775+1300 [WARN] Provider "http://registry.terraform.io/pactflow/pact" produced an invalid plan for pact_application.fruit_salad, but we are tolerating it because it is using the legacy plugin SDK. The following problems may be the cause of any confusing errors from downstream operations: - .repository_url: planned value cty.StringVal("") for a non-computed attribute``` Possible issue with empty arrays: ```2022-01-10T14:18:48.629+1300 [WARN] Provider "http://registry.terraform.io/pactflow/pact" produced an invalid plan for pact_team.scallops, but we are tolerating it because it is using the legacy plugin SDK. The following problems may be the cause of any confusing errors from downstream operations: - .pacticipants: planned value cty.NullVal(cty.List(cty.String)) does not match config value cty.ListValEmpty(cty.String)```

Thanks Jonatan. I?ll raise this on Github and get them looked into.

The role one isn?t immediately obvious to me what?s happening, but the repository URL looks like it just needs some better URL escaping

Thanks a lot Matt - Let me know if you need any more info.

Raised https://github.com/pactflow/terraform-provider-pact/issues/18 and https://github.com/pactflow/terraform-provider-pact/issues/19

Hi Jonatan, I was looking at this issue today and I can?t seem to replicate it (I used the `pactflow-acceptance` suite in the github repository to test setting it up and then changing it)

Ah, I see. You?re example above has `Fruit` as the resource name, but I suspect the resource name has the space (not the repository URL)

Yes, I believe as we move to a later version of the API we?ll need to deal with those.

I?ve released a new version that should fix the above issue (URL escaping was indeed the problem)

I had a look at the roles, but with the existing detail I can?t quite work out the problem. I can add/remove them running it against our tf-acceptance account, so I suspect it will be some set of circumstances causing the issue. I?ll look at the roles one in the next day or so if you could share any logs / more detail?

Thanks a lot Matt - I'll gather some info later today, and try a few things out to see if this can be narrowed down.

thanks, that?d be great

has joined #terraform

has joined #terraform

has joined #terraform

Hi team - Any chance we can either persist changes when the order of elements change in an array, or ignore the order altogether? Things like this create a loop where `terraform plan` always displays this change, and apparently nothing happens after doing `terraform apply`, so the only way of fixing it is manually changing the order in the tf files to match it, which is not practical when using references instead of the plain uuids (i.e, going: `pact_user.john_doe.uuid`) ```# pact_team.myTeam will be updated in-place ~ resource "pact_team" "myTeam" { id = "b3a82ec1-a34e-4f82-845f-e41f9de3da78" name = "MyTeam" ~ users = [ "967155a1-29a7-4aa3-8520-7bad949abad8", - "1e8c0d39-7937-4647-8886-9e40690e6886", "4e161b2b-b07a-4979-a69e-f5ed2727bfa4", - "50011c55-2fa0-4e70-b5e5-9592fc38e36a", "781a1bf2-9723-40c8-9cee-69ff9515c7f6", + "50011c55-2fa0-4e70-b5e5-9592fc38e36a", + "1e8c0d39-7937-4647-8886-9e40690e6886", ] # (2 unchanged attributes hidden) }```

Good idea. I think the issue is that the api can return items in different sort orders, which triggers the change

I think storing the items in a sorted array will address it

has joined #terraform

Hello Everyone, We are trying to implement Contract testing and have almost completed the setup manually. Right now we are in the process of migrating our webhook setup into Terraform. But it seems like the new event `contract_requiring_verification_published` is not supported yet. ```Error: "events.0" must be one of the allowed events [contract_content_changed contract_published provider_verification_failed provider_verification_published provider_verification_succeeded], got contract_requiring_verification_published``` I am using `version = "0.4.3"` of the TF provider for Pact. Is there any plan in your roadmap to support it or any workaround? Thanks in advance :slightly_smiling_face:

Release on the way out: https://github.com/pactflow/terraform-provider-pact/releases/tag/v0.5.0

Awesome! :raised_hands: Thanks Matt!

Gah, build failed! I think the GH runtime has changed (or version of go) and arm is failins for unrelated reasons.

I?ll have t olook tomorrow

OK I had a late call and I think the issue is it was running the release on an older Golang version and somethnig about the GH actions environment has recently changed (because I released last week just fine). Anywho, `0.5.1` is out with your update!

Wow! Thank you so much :raised_hands:

Hi, I have hit another brick wall. I need to pass the Webhook parameters as `query parameters` and not `request body` . However, I could not find the relevant information in the https://registry.terraform.io/providers/pactflow/pact/latest/docs/resources/webhook#request and seems `body` is a required field. Therefore, this is how my tried to write the request: ``` request { url = "https://<jenkins-url>/generic-webhook-trigger/invoke?token=<token>&consumerName=CustomerWeb&monolithEnv=DOCKER&consumerPactUrl=$${pactbroker.pactUrl}&providerVersion=$${pactbroker.providerVersionNumber}&providerBranch=$${pactbroker.providerVersionBranch}" method = "GET" headers = { "X-Content-Type" = "application/json" } body = <<EOF { "pact": "$${pactbroker.pactUrl}" }``` With the above configuration, I am getting the following error: ```? Error: "request.0.url" must be a valid URL, got: parse " \"https://********/generic-webhook-trigger/invoke?token=**********&consumerName=CustomerWeb&monolithEnv=DOCKER&consumerPactUrl=${pactbroker.pactUrl}&providerVersion=${pactbroker.providerVersionNumber}&providerBranch=${pactbroker.providerVersionBranch}\"\n": net/url: invalid control character in URL``` Is there a way to pass query params instead of request body?

Hi Rupam, apologies I missed this. Can you please raise an issue? We can get that supported

Sure! at the moment we resolved it by updating our job to accept request body instead of query parameters it is working. I will raise an issue to add support for query params.

Ah good to hear, thanks!

Hi team - I don't seem to be able to assign the Team Administrator role via Terraform, are you aware of any limitations there? What I'm doing at the moment is getting all the roles that are already defined in Pactflow (like User, Viewer, Team Administrator, Guest, etc) into a dictionary that I can then reference elsewhere. Like this: ```variable "pactflow_roles" { type = map(any) description = "Roles defined by Pactflow" default = { administrator = "cf75d7c2-416b-11ea-af5e-53c3b1a4efd8", ci_cd = "c1878b8e-d09e-11ea-8fde-af02c4677eb7", guest = "d6938de2-e37c-11eb-b80e-3f68328092ca", team_administrator = "d635f960-88f2-4f13-8043-4641a02dffa0", user = "e9282e22-416b-11ea-a16e-57ee1bb61d18", viewer = "9fa50562-a42b-4771-aa8e-4bb3d623ae60" } }``` So that then I can go: ```resource "pact_user" "john_doe" { name = "John Doe" email = "" active = true type = "user" roles = [ var.pactflow_roles["team_administrator"], var.pactflow_roles["user"] ] }``` But only the `user` role gets persisted, no the team administrator one.

Not sure if this is related, but I can't edit the team administrator or guest roles in the UI (I'm an admin btw)

hmm I?m definitely not aware of not being able to assign the team admin

Let me take a look

as for why you can?t edit them, it?s because they are system roles and have specific meanings.

TIL: https://docs.pactflow.io/docs/permissions/predefined-roles#team-administrator

Oh, I should've read that first. Considering that, are you planning to add it to the https://registry.terraform.io/providers/pactflow/pact/latest/docs/resources/team then instead? It would be handy to be able to set up all at once rather than doing it manually later.

Oh, as in, adding the admin on the Team resource itself? Yes, I have a WIP branch for that

I?ll see if I can get that to you this morning Jonatan

Awesome, thanks a lot! :party_parrot:

release v0.7.0 headed out, should now have the ability to set the team administrator

Nice!! Thanks!

Let me know how you go!

Just got to test in now, works like a charm! :raised_hands:

The only thing to keep in mind is that even though the team administrator role can't be _assigned_ via the `users` resource, you may want to have it declared anyway so that it doesn't show up as a change in subsequent runs.

I noticed that https://github.com/pactflow/terraform-provider-pact/commit/e3894e44ab810df2fd2e8b1ade2b2a3538617f0a was merged in https://github.com/pactflow/terraform-provider-pact/releases/tag/v0.7.0, but I can still reproduce the issue.

bugger, I?ll have to setup an explicit test case for it

Ah, interesting.

Good point. I?m wondering if it makes sense to explicitly exclude it in the terraform client. I?m assuming you need to add the role to the user _and_ add the user to the team administrators property, to avoid the ?argh there?s an extra role on this user and we?re going to delete it? terraform plan output?

Yeah, exactly. And I agree that having it excluded from the roles could be more clear when setting things up.

Not sure if that would cause a mismatch with the UI though. And I don't know what happens when a user is a member of multiple teams but only the team administrator of one of these, for example.

I?ll check with the team

The team administrator has special uuid based scopes: ``` { "uuid": "d635f960-88f2-4f13-8043-4641a02dffa0", "name": "Team Administrator", "permissions": [ { "uuid": "066e1800-d462-4a3e-a117-5c42b299d67d", "scope": "team:manage:5b7cd177-0dd9-49da-8ff2-d6a92bda49ab", "label": "Manage team", "description": "Can manage a specific team (add users and applications to the team).", "group": "Team" } ], "_links": { "self": { "title": "User Role", "name": "Team Administrator", "href": "https://test.test.pactflow.io/admin/users/f2ca543f-a181-4695-b6c0-bf43794b86d3/roles/d635f960-88f2-4f13-8043-4641a02dffa0" } } }, { "uuid": "d635f960-88f2-4f13-8043-4641a02dffa0", "name": "Team Administrator", "permissions": [ { "uuid": "066e1800-d462-4a3e-a117-5c42b299d67d", "scope": "team:manage:3eea19ed-1994-444f-90e0-10475e882694", "label": "Manage team", "description": "Can manage a specific team (add users and applications to the team).", "group": "Team" } ], "_links": { "self": { "title": "User Role", "name": "Team Administrator", "href": "https://test.test.pactflow.io/admin/users/f2ca543f-a181-4695-b6c0-bf43794b86d3/roles/d635f960-88f2-4f13-8043-4641a02dffa0" } } }``` Note the `team:manage:uuid` scope - so the role only applies to the specific team scope. Above, one of the scopes is `team:manage:3eea19ed-1994-444f-90e0-10475e882694` which says that I can manage the team with uuid `3eea19ed-1994-444f-90e0-10475e882694`

Oh, yes, awesome.

I?m advised we could filter out the team administrator role, so i?ll create an issue to track that

thanks for raising

Excellent, thanks again for looking into this!

has joined #terraform

has joined #terraform

Hi team - Does anyone know how to create system accounts via TF? I see that the `user` resource https://github.com/pactflow/terraform-provider-pact/blob/master/resource_user.go#L62 "user" and "system" as values for the `type` property (which by the way should probably https://registry.terraform.io/providers/pactflow/pact/latest/docs/resources/user), but the `email` is still required and the result is the creation of a regular user, not a system account.

I think it just needs to be properly supported and tested. The type is there but as you say hasn?t been exposed (for this reason).

It should be straightforward, i?ll see if I can squeeze it in today

Thanks a lot Matt!

has joined #terraform

has joined #terraform

has joined #terraform

has joined #terraform

Hi! Any updates on this? Thanks!

Hi Jonatan - apologies, I haven?t had a chance on this one just yet. I?ve just re-opened it though to reflect that it doesn?t appear to be working

Hi @matt.fellows - Is there a ticket for this? Thanks!

Hi Jonatan - apologies, I don?t think I created one. I?ll do that now

No worries, thanks!

I?ll add detail to it. I remember now why I didn?t create it. I thought ?it should be easy?, but it?s actually a different API (hence why it?s not exposed in the docs)

I see. All good, thanks again for looking into it, much appreciated

@jonatan.jaworski FYI `v0.0.8` of the terraform provider is https://registry.terraform.io/providers/pactflow/pact/latest. It should now support system user, and hopefully address the ordering issues from before

In my testing, it did require a couple of pass throughs to update the internal state when applying to an existing state file (the types of values have changed), so just be aware

What a legend, thank you! I'll give it a go today

Let me know how you go! There is an acceptance suite, but of course there are always other variables in play

This went very well, thanks again for looking into it! The only gotcha for people upgrading is that importing an existing system account to be managed via TF actually forces the creation of a new system account, because the `type` property, so you may as well just create new ones and update the references rather than importing existing resources. Totally expected though. ``` # pact_user.sa-test must be replaced -/+ resource "pact_user" "sa-test" { ~ id = "72f60011-5992-40c7-b55f-d81b608bdbfe" -> (known after apply) name = "TestSystemAccount" + roles = [ + "c1878b8e-d09e-11ea-8fde-af02c4677eb7", ] + type = "system" # forces replacement ~ uuid = "72f60011-5992-40c7-b55f-d81b608bdbfe" -> (known after apply) }```

Ah, good spot. This might be fixable in TF side, but if you?re past that point it?s probably not urgent

Hmmm, I might have found something that is probably worth looking into. It's not a problem to recreate system accounts, but if I want to import a user with a different identity provider (SAML in my case), I can't, because it always will try to create another user, and in this case it'll use Pactflow as identity provider by default.

For example, once I had a user created with SAML as provider, I disabled the one with Pactflow as identity provider, and then tried to replace the reference in my TF file as I've been doing so far, like: ```terraform state rm pact_user.john_doe; terraform import pact_user.john_doe df33f287-4cd2-4469-943b-ccb0edc2f3bd``` And then running changes on top of that, which was ok for me before. Now it always tries to re-create the user as mentioned, so I get: ``` # pact_user.john_doe must be replaced -/+ resource "pact_user" "john_doe" { ~ active = false -> true ~ id = "d97a9d4d-89cc-4337-8dcf-5517a34312e7" -> (known after apply) name = "John Doe" + roles = [ + "d635f960-88f2-4f13-8043-4641a02dffa0" ] + type = "user" # forces replacement ~ uuid = "d97a9d4d-89cc-4337-8dcf-5517a34312e7" -> (known after apply) # (1 unchanged attribute hidden) }```

Ah yes, this is definitely not possible until we build the SCIM API we discussed

I'll make it clearer that terraform doesn't (and can't) support this.

Oh, but I was able to import this resource before without forcing re-creation.

Ahh. Interesting. I think you're right in that you could import it but not create. It was probably an accidental feature but that indicates it just might work. I'll take a quick look when back in front of the desk. Sorry for that, I'll see about getting a test to cover that situation if I can

No worries at all, thanks for persevering!

And I certainly can stop using TF for users if this is not supported, until that API is in place. I was just wondering if there is anything cheeky I can do in the meantime :sweat_smile:.

Let's see if we make it work first. There is a bigger issue we need to solve, but this doesn't take us off that path or create a maintenance burden we'll need to carry forward

Thanks Matt

Just created https://github.com/pactflow/terraform-provider-pact/issues/25 to track

has joined #terraform

Hi :wave: I was going through https://registry.terraform.io/providers/pactflow/pact/latest/docs/resources/application terraform resource and it seems that it does not support the `display_name` property which is available as a part of pact docker cli. We are auto generating the consumer names and in some case we would like to update the display name, and in order to make it maintainable, we would like to use this Terraform to do that. Is it possible to add support for the `display-name` as well as a part of this resource? Thanks :slightly_smiling_face:

Sure, can you please raise a feature request on the terraform repo? Should be easy

Sure, Thanks :slightly_smiling_face:

I have raised a feature request here:https://pact.canny.io/feature-requests/p/add-support-for-display-name-in-pactapplication-tf-resource

Should I also raise it as an issue in the Github repo?

That?s fine, I?ll point to that

thanks

Thanks :slightly_smiling_face:

OK had an hour or so this afternoon to poke at this. I think the main issue is just the way it wants to force the creation of a new resource on import. I think it?s sorted, I managed to test this on an existing google authenticated user in an acceptance test account.

v0.9.0 should be out any minute now with a fix (and a minor new requested feature). If you are creating `applications` resources with terraform, you?ll see a new property `display_name` available. As the broker automatically populates this, you?ll start seeing changes wanting to be applied. Should be a minor update on your end, but it?s just the way the broker API works and there?s no good way I know of in terraform to not import a value if it?s defined as configurable.

Thanks heaps!!! I'll have a go at it today.

This worked really well for me. I ended up adding the `display_name` to my TF and matching whatever it had previously. Is that something that can/should be changed via TF at all?

Also, I'm not sure where the `main_branch` property comes from. It picked this up in only two of my applications. I don't know the relevance of this or how to remove the value (it keeps coming up if I apply this change). Any advice? Happy for this to be a separate thread. ```Terraform will perform the following actions: # pact_application.buyflow_smb_checkout_bff will be updated in-place ~ resource "pact_application" "buyflow_smb_checkout_bff" { id = "Buyflow.Smb.Checkout.Bff" - main_branch = "main" -> null name = "Buyflow.Smb.Checkout.Bff" # (2 unchanged attributes hidden) } # pact_application.manual_upload_bff will be updated in-place ~ resource "pact_application" "manual_upload_bff" { id = "ManualUpload.BFF" - main_branch = "master" -> null name = "ManualUpload.BFF" # (2 unchanged attributes hidden) } Plan: 0 to add, 2 to change, 0 to destroy.```

> This worked really well for me. I ended up adding the `display_name` to my TF and matching whatever it had previously. Is that something that can/should be changed via TF at all? The system defaults to camel casing and adding hyphens I think to whatever the given name is - something to that effect anyway. The human readible descriptions will be more useful over time for sure

`main_branch` I think is also auto-populated from the broker. Once you start publishing branches there is some logic in there to detect the main branch (based on popular naming conventions).

It?s one of those tricky things with IAC providers. There is always going to be remote activity that works against it. In this case, I?d update your TF and ensure they stay in sync

Sweet. Is that something that can be added at creation time too? Most teams coming into Pact will have their repos ready at that point, so they'll know their default branch name.

Absolutely!

That's the most ideal, rather than Pactflow guessing

Cool, I'll update my instructions then. Thanks again for you hard work, really appreciate it!

has joined #terraform

has joined #terraform

has joined #terraform

has joined #terraform

has joined #terraform