-
Notifications
You must be signed in to change notification settings - Fork 389
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update go client, use new synthetics target #571
Conversation
2447693
to
b3a56a0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this 🙇 Did a high level review, i'll spend some time next week playing around with test scenarios since we're modifying schema types. Left a couple questions/comments inline.
} else if assertionTarget.GetOperator() == datadogV1.SYNTHETICSASSERTIONOPERATOR_VALIDATES { | ||
assertionTarget.SetTarget(v.(string)) | ||
} else { | ||
assertionTarget.SetTarget(v.(string)) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this just be one else
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah most likely.
assertionMap := attr.(map[string]interface{}) | ||
if v, ok := assertionMap["type"]; ok { | ||
assertionType := v.(string) | ||
assertion.SetType(datadogV1.SyntheticsAssertionType(assertionType)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any reason to change this logic if we're deprecating it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's because of the api client change I believe.
@@ -466,20 +562,48 @@ func updateSyntheticsTestLocalState(d *schema.ResourceData, syntheticsTest *data | |||
d.Set("request_headers", actualRequest.Headers) | |||
|
|||
actualAssertions := syntheticsTest.GetConfig().Assertions | |||
var localAssertions []map[string]string |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to keep any of the existing logic for users that still use assertions
for a bit?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I think I found what was needed there.
Imports don't work properly just yet. |
OK I believe I found a correct path forward. The trick is to keep using the old field if it's referenced in the current state, otherwise use the new field everywhere. AFAIU it just a bit weird if you use import with the old schema. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@therve can you bump the version of datadog-api-client-go in separate PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I apologize I haven't done a full manual test with this yet, but I did take a deeper look and left another review with some followup questions
Type: schema.TypeString, | ||
Optional: true, | ||
}, | ||
"targetjsonpath": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we have this conflictsWith target
? They seem mutually exclusive
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It doesn't work with nested fields unfortunately.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we try to bump the SDK version to https://github.com/hashicorp/terraform-plugin-sdk/releases/tag/v1.15.0
if v, ok := assertionMap["operator"]; ok { | ||
assertionOperator := v.(string) | ||
assertion.SetOperator(datadogV1.SyntheticsAssertionOperator(assertionOperator)) | ||
if v, ok := assertionMap["operator"]; ok { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like this code path is pretty much the same as before, but some is further indented now. From the schema aren't type
and operator
siblings? Do the operator
and target
checks need to happen inside the type
check?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They are now required, so it's indented because we only create the structure when we already have the previous fields.
@@ -49,6 +73,8 @@ func TestAccDatadogSyntheticsSSLTest_importBasic(t *testing.T) { | |||
ResourceName: "datadog_synthetics_test.ssl", | |||
ImportState: true, | |||
ImportStateVerify: true, | |||
// Assertions will be imported into the new schema by default, but we can ignore them as users need to update the local config in this case | |||
ImportStateVerifyIgnore: []string{"assertions", "assertion"}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the issue here that on import we will have both assertions
and assertion
in the state? Is this going to cause an unempty diff on future apply
s?
Actually, re-reading some of the code above, it looks like you check for the config before saving this field, in updateSyntheticsTestLocalState
, so is this ignore still a requirement?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I check the config before saving the field, but it only works if I already have state. IIUC, the ImportStateVerify
compares to a plain import, which doesn't compare to anything locally.
localAssertion["target"] = convertToString(target) | ||
localAssertions[i] = localAssertion | ||
} | ||
// If the config still uses assertions, keep using that in the state to not generate useless diffs |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd have to test around with this a bit more, but I'm not sure if d
is always from the config. I think depending on which lifecycle piece we're in, d
can reflect the object from the state instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah it mostly comes from the state, but that's what I care about here.
It needs a code change so I'd rather merge that one if we're close. |
This updates the go client to the latest version to be able to use the new
SyntheticsTest model, in particular the validatesJSONPath operator.
Closes ##545, #566