Skip to content
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 support for notification configuration resource #86

Merged
merged 1 commit into from
Aug 19, 2019

Conversation

lafentres
Copy link
Contributor

@lafentres lafentres commented Aug 8, 2019

Description

This adds support and documentation for creating, updating, destroying, and importing notification configurations. It resolves #68.

Notification configuration resources require:

  1. name
  2. destination_type - one of slack or generic
  3. url - url the notifications will go to
  4. workspace_external_id - external id of the workspace this notification configuration belongs to

Optionally, you can provide:

  1. enabled - true or false, defaults to false
  2. token - key used for providing an HMAC signature on notification requests, only allowed with destination_type of generic
  3. triggers - set of triggers, defaults to empty set (no notification trigger on any run events)

Updating destination_type or workspace_external_id will force the creation of a new notification configuration resource.

Testing

The examples from the documentation I added or from the test cases work and you can use them to generate notification configurations if you pull this down and use it locally.

Documentation

@lafentres lafentres self-assigned this Aug 8, 2019
@ghost ghost added the size/XL label Aug 8, 2019
@lafentres lafentres force-pushed the lafentres/add-notification-configuration-support branch from 5d6f7b3 to a76a313 Compare August 9, 2019 16:55
@lafentres lafentres marked this pull request as ready for review August 9, 2019 17:16
@lafentres
Copy link
Contributor Author

I might have been a little overzealous with the tests, so please let me know if there are tests that are unnecessary. Or if there are more tests that need to be added :)

d.Set("enabled", notificationConfiguration.Enabled)
d.Set("name", notificationConfiguration.Name)
// Don't set token here, as it is write only
// and setting it here would make it blank
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for adding this comment! I noticed that resources like OrganizationToken and TeamToken also don't set the actual token value, but with no comment as to why.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I pieced this together after a lot of trial and error. It would be nice to get confirmation from someone who has done a lot of work with providers though.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lafentres I think you're good here. 👍 If the value would be blank, then setting it here would for sure break the state and cause a diff.

I'm wondering why we even have a field for this value though? That's not your fault, just curious why it would even be in the SDK 🤔 Unless the notification configuration is shared with other parts of the CRUD, but it doesn't seem to be.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm wondering why we even have a field for this value though?

Good point. In this resource the token field should probably be omitted in the response type.

In other resources (e.g. team token, organization token) its used to return a newly created token in the create response, so it adds value there. But here its a value that is provided by the caller, so its never used in any of the responses.

Copy link
Contributor

@davidcelis davidcelis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks AWESOME ✨ great work with this PR!

I just have a couple small questions before I turn this into a ✅!

@lafentres lafentres changed the title [DRAFT] Add support for notification configuration resource Add support for notification configuration resource Aug 9, 2019
Copy link
Contributor

@vancluever vancluever left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lafentres great work! I have some minor nits and a few things that should probably be changed (namely the de-coupling of the import test from the rest of the tests, and the update of the intention on the check functions). Otherwise this is a 👍 from me!

Optional: true,
Elem: &schema.Schema{
Type: schema.TypeString,
ValidateFunc: validation.StringInSlice(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lafentres did this work in your testing? Depending on how hashicorp/terraform#22298 goes, this might need to be removed. Just FYI. Hopefully the primitive-element type case gets allowed though.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Being able to do this (in a supported way) would be nice though.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@vancluever, yep, this worked :) In addition to passing the tests I wrote, it also stopped me from putting in various invalid strings when I was creating notifications with Terraform locally.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Weird. I'm asking @radeksimko to weigh in here as I'm not too sure how this is working given the restrictions in place. Maybe the acceptance testing suite is not using InternalValidate after all.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This works just fine because you are validating each element, not the whole set. In other words the ValidateFunc is associated with TypeString, not TypeSet.

Copy link
Contributor

@vancluever vancluever Aug 17, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@radeksimko what I'm wondering about is how it's passing InternalValidate with the current code in place: https://github.com/hashicorp/terraform/blob/v0.12.6/helper/schema/schema.go#L831-L836

Scratch that, I see that now. Good call and great application @lafentres!

d.Set("enabled", notificationConfiguration.Enabled)
d.Set("name", notificationConfiguration.Name)
// Don't set token here, as it is write only
// and setting it here would make it blank
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lafentres I think you're good here. 👍 If the value would be blank, then setting it here would for sure break the state and cause a diff.

I'm wondering why we even have a field for this value though? That's not your fault, just curious why it would even be in the SDK 🤔 Unless the notification configuration is shared with other parts of the CRUD, but it doesn't seem to be.

tfe/resource_tfe_notification_configuration_test.go Outdated Show resolved Hide resolved
tfe/resource_tfe_notification_configuration_test.go Outdated Show resolved Hide resolved
tfe/resource_tfe_notification_configuration_test.go Outdated Show resolved Hide resolved
Copy link
Contributor

@svanharmelen svanharmelen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added my 2cts 😉

Optional: true,
Elem: &schema.Schema{
Type: schema.TypeString,
ValidateFunc: validation.StringInSlice(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Being able to do this (in a supported way) would be nice though.

d.Set("enabled", notificationConfiguration.Enabled)
d.Set("name", notificationConfiguration.Name)
// Don't set token here, as it is write only
// and setting it here would make it blank
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm wondering why we even have a field for this value though?

Good point. In this resource the token field should probably be omitted in the response type.

In other resources (e.g. team token, organization token) its used to return a newly created token in the create response, so it adds value there. But here its a value that is provided by the caller, so its never used in any of the responses.

tfe/resource_tfe_notification_configuration_test.go Outdated Show resolved Hide resolved
tfe/resource_tfe_notification_configuration_test.go Outdated Show resolved Hide resolved
@lafentres lafentres force-pushed the lafentres/add-notification-configuration-support branch from 3cc2b0f to 1418928 Compare August 13, 2019 17:21
Copy link
Contributor

@vancluever vancluever left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just making sure that this is changed to approved based on all of the conversations. Great work again @lafentres!

Copy link
Contributor

@davidcelis davidcelis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great to me too 🎉

Optional: true,
Elem: &schema.Schema{
Type: schema.TypeString,
ValidateFunc: validation.StringInSlice(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This works just fine because you are validating each element, not the whole set. In other words the ValidateFunc is associated with TypeString, not TypeSet.

@lafentres lafentres merged commit 7fc1d5f into master Aug 19, 2019
@lafentres lafentres deleted the lafentres/add-notification-configuration-support branch August 19, 2019 19:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Please add ‘notification_configuration’(?) resource
5 participants