Closed raihle closed 1 year ago
@raihle I believe create_selector = "0"
is the right usage for your case. Whilst I'm not sure why it failed with an inconsistent result. Would you mind sniffer the api sequences to see what's actually happening (e.g. via mitmproxy
)?
These are the relevant flows:
If I terraform destroy
before apply
, the initial GET and DELETE are omitted, but the PUT and final GET look the same.
The bodies look like I expect:
{
"connectionId": 3,
"fullName": "xxx/yyy",
"githubId": 123456789,
"name": "xxx/yyy",
"scopeConfig": {
// Omitted for readability
},
"scopeConfigId": 23
}
{
"success": true,
"message": "success",
"causes": null,
"data": null
}
{
"data": [
{
"fullName": "xxx/yyy",
"githubId": 123456789,
"name": "xxx/yyy",
"scopeConfigId": 23
}
]
}
[
{
"connectionId": 3,
"fullName": "xxx/yyy",
"githubId": 123456789,
"name": "xxx/yyy",
"scopeConfig": {
// Omitted for readability
},
"scopeConfigId": 23
}
]
{
"connectionId": 3,
"fullName": "xxx/yyy",
"githubId": 123456789,
"name": "xxx/yyy",
"scopeConfig": {
// Omitted for readability
},
"scopeConfigId": 23
}
(123456789
in my examples is 659690394
in my actual config - that's just too much work to fix in a screenshot...)
The create_selector
works as expected. The issue resides in the mismatch between the PUT
request body and GET
response body.
Using create_selector
doesn't violate the expectation that the body
match both the request/response body.
Is there a way to bypass that expectation/check? Every other API resource seems to work "normally" so this provider has been a big help so far.
You can try write_only_attrs, but in that case, terraform
has no way to keep track of this resource at all..
Oh, yeah, if I say all of data
is write-only...
This particular resource is effectively immutable so that should be good enough, thanks!
I'm trying to use
create_selector
in restful_resource to work with an awkward API. Most of the resources work "normally", but this specific one requires create via PUT (rather than POST) with a "data" property containing an array containing the object I want to create, and creation returns an array with the object created. The API also embeds the "scopeConfig" in its response (identified by the "scopeConfigId" in the POST data).An example of using the API via curl
```bash DEVLAKE="***" AUTH="***" echo "CREATE" curl -X PUT "${DEVLAKE}/api/plugins/github/connections/3/scopes" \ -H "Authorization: Bearer ${AUTH}" \ -d '{ "data": [{ "githubId": 123456789, "scopeConfigId": 22, "name": "telia-company/fft-devlake-projects", "fullName": "telia-company/fft-devlake-projects" }] }' echo "GET" curl -X GET "${DEVLAKE}/api/plugins/github/connections/3/scopes/123456789" \ -H "Authorization: Bearer ${AUTH}" \ echo "DELETE" curl -X DELETE "${DEVLAKE}/api/plugins/github/connections/3/scopes/123456789" \ -H "Authorization: Bearer ${AUTH}" \ ```And the output (formatted for readability)
CREATE ```json [ { "connectionId": 3, "fullName": "xxx/yyy", "githubId": 123456789, "name": "xxx/yyy", "scopeConfig": { // Omitted for readability }, "scopeConfigId": 22 } ] ``` GET ```json { "connectionId": 3, "fullName": "xxx/yyy", "githubId": 123456789, "name": "xxx/yyy", "scopeConfig": { // Omitted for readability (same as above) }, "scopeConfigId": 22 } ``` DELETE ```json { "success": true, "message": "success", "causes": null, "data": null } ```I have tried to accommodate this by using
create_selector
(and various shots in the dark) as follow:When I run
terraform apply
, the module consistently fails (although all resources were successfully created in the system):It seems to me that the response body was not successfully extracted. It's quite possible that I'm just misusing gjson query syntax - I have never used it before, and every example seems to assume that the "root" data is an object, not an array.