* provider/aws: Add DeploymentRollback as a valid TriggerEvent type
* provider/aws: Add auto_rollback_configuration to aws_codedeploy_deployment_group
* provider/aws: Document auto_rollback_configuration
- part of aws_codedeploy_deployment_group
* provider/aws: Support removing and disabling auto_rollback_configuration
- part of aws_codedeploy_deployment_group resource
- when removing configuration, ensure events are removed
- when disabling configuration, preserve events in case configuration is re-enabled
* provider/aws: Add alarm_configuration to aws_codedeploy_deployment_group
* provider/aws: Document alarm_configuration
- part of aws_codedeploy_deployment_group
* provider/aws: Support removing alarm_configuration
- part of aws_codedeploy_deployment_group resource
- disabling configuration doesn't appear to work...
* provider/aws: Refactor auto_rollback_configuration tests
- Add create test
- SKIP failing test for now
- Add tests for build & map functions
* provider/aws: Refactor new aws_code_deploy_deployment_group tests
- alarm_configuration and auto_rollback_configuration only
- add assertions to deployment_group basic test
- rename config funcs to be more easy to read
- group public tests together
* provider/aws: A max of 10 alarms can be added to a deployment group.
- aws_code_deploy_deployment_group.alarm_configuration.alarms
- verified this causes test failure with expected exception
* provider/aws: Test disabling alarm_configuration and auto_rollback_configuration
- the tests now pass after rebasing the latest master branch
`on_premises_instance_tag_filter`
When setting `on_premises_instance_tag_filter`, Terraform was not
pushing the changes on the cReate (due to a spelling mistake). A second
apply would push the tags and then cause a panic. Terraform was building
a ec2.Tagfilter struct without checking for optional values. When the
TagFilter was being dereferenced, it caused a panic
* Improve testing of CodeDeploy DeploymentGroup Trigger Configs
- ensure updates to trigger_events are applied
- assert changes to trigger_target_arn
* Retry CodeDeploy DeploymentGroup when Trigger Config SNS Topic is not available
- increase retries from 2 => 5
* provider/aws: CodeDeploy Deployment Group Triggers
- Create a Trigger to Send Notifications for AWS CodeDeploy Events
- Update aws_codedeploy_deployment_group docs
* Refactor validateTriggerEvent function and test
- also rename TestAccAWSCodeDeployDeploymentGroup_triggerConfiguration test
* Enhance existing Deployment Group integration tests
- by using built in resource attribute helpers
- these can get quite verbose and repetitive, so passing the resource to a function might be better
- can't use these (yet) to assert trigger configuration state
* Unit tests for conversions between aws TriggerConfig and terraform resource schema
- buildTriggerConfigs
- triggerConfigsToMap
Change the `RetryFunc` from a plain `error` return type to a
specialized `RetryError` which must decide whether it is
retryable or not.
Add `RetryableError` / `NonRetryableError` factory functions that
callers are meant to use to build up these errors.
This makes it eminently clear whether or not a given error is
retryable from inside the client code.
Goal here is to _not_ change any behavior, simply reflect the
existing behavior with the new, clearer, API.
All of these RetryErrors were meant to fail right away, but instead
caused retry looping because the typecheck in the implementation of
`resource.Retry()` only catches the value type, and not the pointer
type.
Refs #5537
Andras Ferencz-Szabo