-
Notifications
You must be signed in to change notification settings - Fork 160
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
Add tfe_team_notification_configuration resource #1540
base: main
Are you sure you want to change the base?
Conversation
…ication-cfg-resource
…ication-cfg-resource
New tests are passing when run against local env
|
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.
Tested with generic and email notifications. Small questions on validation
name = "my-test-email-notification-configuration" | ||
enabled = true | ||
destination_type = "email" | ||
email_user_ids = [tfe_organization_membership.test.user_id] |
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.
this supposedly doesn't work on non-TFE
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.
what part doesn't work?
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 thought you mentioned that emailing specific users was only on TFE, I may have misunderstood?
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 updated the example add the user to the team, not sure if that's the part that was failing for you or if it was something 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.
the email_addresses
will only work for TFE (there's an example for that one below this as well). but email_user_ids
should work fine for both.
Computed: true, | ||
ElementType: types.StringType, | ||
Validators: []validator.Set{ | ||
validators.AttributeValueConflictSetValidator( |
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'm wondering when we would opt for attribute required
vs attribute conflicts the other options
? The required option seems to be more straightforward
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.
what are you thinking the required logic would look like?
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'm seeing this logic
https://github.com/hashicorp/terraform-provider-tfe/pull/1540/files#diff-ad99357d00b5259c75af9f4a94edadd00fe2235ed7e23214b95a984d72845e2aR214
where we do a required on generic, ms-teams, slack. Why not just require email
?
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.
in that case, URL is required to create any of those types of notifications — it's enforced by the API. the API doesn't require the notification to have an email_user_id
nor email_address
for email notifications though
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.
but you need to have notification_type to be email
if you were to supply email_user_id
or email_address
field correct?
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.
where we do a required on generic, ms-teams, slack. Why not just require email?
but you need to have notification_type to be email if you were to supply email_user_id or email_address field correct?
the logic is slight inverted. it boils down to "if destination_type
is set to generic, slack, etc, then require that url
is also set." what you're asking for is the opposite: "if email_user_ids
is set, then require that destination_type
is email."
as far as I know, inspecting the value of the other attribute would require adding one more custom validator (there are already two new ones in this PR). but in this case we can make do with using one of the one's we're already adding.
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.
Ok, yea if we need an additional custom validator to achieve the same thing then it wouldn't make sense.
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.
Looks good! Approved with some comments, but no blockers.
if emailAddresses, err := types.SetValueFrom(ctx, types.StringType, v.EmailAddresses); err == nil { | ||
result.EmailAddresses = emailAddresses | ||
} | ||
|
||
if len(v.Triggers) == 0 { | ||
result.Triggers = types.SetNull(types.StringType) | ||
} else if triggers, err := types.SetValueFrom(ctx, types.StringType, v.Triggers); err == nil { | ||
result.Triggers = triggers | ||
} |
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.
In both cases here, is the err != nil
case worth a diagnostic warning? Or are we sure that won't happen based on how the config is parsed in the methods below?
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 ended up just exposing diagnostics to the caller generating the model and halting if there are any errors
internal/provider/resource_tfe_team_notification_configuration.go
Outdated
Show resolved
Hide resolved
} | ||
|
||
// Add email_addresses set to the options struct | ||
emailAddresses := make([]types.String, 0) |
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.
Consider:
emailAddresses := make([]types.String, 0) | |
emailAddresses := make([]types.String, len(plan.Triggers.Elements())) |
There are some other places in the PR where we can allocate to a known length.
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.
these should all be good now
Description
This PR adds a new
tfe_team_notification_configuration
resource for team notification configurations.Remember to:
Testing plan
External links
Output from acceptance tests