Fixes: #13588
It was pointed out in #13588 that we don't need to ForceNew on a change
of IPv6 CIDR block. The logic I decided to implement here was to
disassociate then associate. We should only be able to be associated to
1 IPv6 CIDR block at once. This feels like a risky move. We can
disassociate and then error on the associate. This would leave us in a
situation where we have no IPv6 CIDR block associated
The alternative here would be that the failure of association, triggers
a reassociation with the old IPv6 CIDR block
I added a test to make sure that the subnet Ids don't change as the ipv6
block changes. Before removing the ForceNew from the ipv6_cidr_block,
the test results in the following:
```
=== RUN TestAccAWSSubnet_ipv6
--- FAIL: TestAccAWSSubnet_ipv6 (92.09s)
resource_aws_subnet_test.go:105: Expected SubnetIDs not to change, but both got before: subnet-0d2b6a6a and after: subnet-742c6d13
```
After the removal of ForceNew, the test result looks as follows:
```
=== RUN TestAccAWSSubnet_ipv6
--- PASS: TestAccAWSSubnet_ipv6 (188.34s)
```
```
% make testacc TEST=./builtin/providers/aws TESTARGS='-run=TestAccAWSSubnet_'
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /terraform/vendor/)
2017/04/24 21:26:36 Generated command/internal_plugin_list.go
TF_ACC=1 go test ./builtin/providers/aws -v -run=TestAccAWSSubnet_ -timeout 120m
=== RUN TestAccAWSSubnet_importBasic
--- PASS: TestAccAWSSubnet_importBasic (85.63s)
=== RUN TestAccAWSSubnet_basic
--- PASS: TestAccAWSSubnet_basic (80.28s)
=== RUN TestAccAWSSubnet_ipv6
--- PASS: TestAccAWSSubnet_ipv6 (188.34s)
PASS
ok github.com/hashicorp/terraform/builtin/providers/aws 354.283s
```
Many apps deployed to Heroku require that multiple buildpacks be
configured in a particular order to operate correctly.
This updates the builtin Heroku provider's app resource to support
configuring buildpacks and the related documentation in the website.
Similar to config vars, externally set buildpacks will not be altered if
the config is not set.
Fixes: #13829
When IPv6 support was added to subnets, we added a new parameter that
had a default value. This means that users are experiencing unexpected
changes in their configuration
We need a schema migration in place to make sure this isn't the case for
the users who have not upgraded yet
```
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /terraform/vendor/)
2017/04/23 10:36:43 Generated command/internal_plugin_list.go
TF_ACC=1 go test ./builtin/providers/aws -v -run=TestAWSSubnetMigrateState -timeout 120m
=== RUN TestAWSSubnetMigrateState
2017/04/23 10:37:27 [INFO] Found AWS Subnet State v0; migrating to v1
2017/04/23 10:37:27 [DEBUG] Attributes before migration: map[string]string{}
2017/04/23 10:37:27 [DEBUG] Attributes after migration: map[string]string{"assign_ipv6_address_on_creation":"false"}
--- PASS: TestAWSSubnetMigrateState (0.00s)
PASS
ok github.com/hashicorp/terraform/builtin/providers/aws 0.021s
```
Here we add a basic provider with a single resource type.
It's copied heavily from the `github` provider and `github_repository`
resource, as there is some overlap in those types/apis.
~~~
resource "gitlab_project" "test1" {
name = "test1"
visibility_level = "public"
}
~~~
We implement in terms of the
[go-gitlab](https://github.com/xanzy/go-gitlab) library, which provides
a wrapping of the [gitlab api](https://docs.gitlab.com/ee/api/)
We have been a little selective in the properties we surface for the
project resource, as not all properties are very instructive.
Notable is the removal of the `public` bool as the `visibility_level`
will take precedent if both are supplied which leads to confusing
interactions if they disagree.
The conditional to ignore the deletion of NS and SOA records can fail to
match if the hostedZoneName already ends with a ".". When that happens,
terraform tries to delete those records which is not supported by AWS
and results in a 400 bad request. This fixes the conditional so that it
will work whether or not hostedZoneName ends with a ".".
fixes#12407
