Here we add a new resource type `gitlab_project_hook`. It allows for
management of custom hooks for a gitlab project.
This is a relatively simple resource as a project hook is a simple
association between a project, and a url to hit when one of the flagged
events occurs on that project.
Hooks (called Webhooks in some user documentation, but simply Hooks
in the api documentation) are covered here for users
https://docs.gitlab.com/ce/user/project/integrations/webhooks.html and
in the API documentation at
https://docs.gitlab.com/ce/api/projects.html#hooks
The current google_compute_url_map resource already supports backend
buckets out of the box: Just pass the self_link of the backend buckets
as you would pass the self_link of a backend service.
This adds some example code as well.
When trying to run the example code with the most recent terraform
master you get the following errors:
```
2 error(s) occurred:
* google_compute_backend_service.home: "region": [REMOVED] region has been removed as it was never used
* google_compute_backend_service.login: "region": [REMOVED] region has been removed as it was never used
```
Hence remove it from the documentation.
* Document the data source interpolation usage
Also briefly mentions how to use counts and splat syntax as with resources to further document the usage of counts for data sources (see https://github.com/hashicorp/terraform/pull/14143).
* Output -> Attribute
As per feedback.
* added emr security configurations
* gofmt after rebase
* provider/aws: Update EMR Cluster to support Security Configuration
* update test to create key
* update docs
We've supported GOOGLE_APPLICATION_CREDENTIALS as an environment
variable (it comes free with our OAuth2 client) but it has never been
documented. Documenting it now to resolve#12626.
This commit adds an option to skip TLS verification of the Triton
endpoint, which can be useful for private or temporary installations not
using a certificate signed by a trusted root CA.
Fixes#13722.
With the FQDN specified, it throws error:
```
1 error(s) occurred:
* azurerm_container_service.test: "agent_pool_profile.0.fqdn": this field cannot be set
```
Update our docs for `google_compute_forwarding_rule` to clarify that the
`ip_address` field expects a literal IP address and will not accept the
`self_link` property of a `google_compute_address` resource.
Prompted by #13375
* Make dnsimple_records importable
terraform 0.7 supports importing a resource into the local state, and
this adds that feature to the dnsimple_record resource.
Unfortunately, the DNSimple v1 API requires a domain name and record ID
to fetch a record, so the import command accepts both pieces of data as
a slash-delimted string like so:
terraform import dnsimple_record.test example.com/1234
* add an acceptance test for importing a dnsimple_record
Fixes: #13173
We now tag at instance creation and introduced `volume_tags` that can be
set so that all devices created on instance creation will receive those
tags
```
% make testacc TEST=./builtin/providers/aws TESTARGS='-run=TestAccAWSInstance_volumeTags' 2 ↵ ✚ ✭
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /terraform/vendor/)
2017/04/26 06:30:48 Generated command/internal_plugin_list.go
TF_ACC=1 go test ./builtin/providers/aws -v -run=TestAccAWSInstance_volumeTags -timeout 120m
=== RUN TestAccAWSInstance_volumeTags
--- PASS: TestAccAWSInstance_volumeTags (214.31s)
PASS
ok github.com/hashicorp/terraform/builtin/providers/aws 214.332s
```
As a follow up to #13844, this pull request sorts the AMIs and snapshots returned from the aws_ami_ids and aws_ebs_snapshot_ids data sources, respectively.
When TerraForm is used to configure and deploy infrastructure
applications that require dozens templated files, such as Kubernetes, it
becomes extremely burdensome to template them individually: each of them
requires a data source block as well as an upload/export (file
provisioner, AWS S3, ...).
Instead, this commit introduces a mean to template an entire folder of
files (recursively), that can then be treated as a whole by any provider
or provisioner that support directory inputs (such as the
file provisioner, the archive provider, ...).
This does not intend to make TerraForm a full-fledged templating system
as the templating grammar and capabilities are left unchanged. This only
aims at improving the user-experience of the existing templating
provider by significantly reducing the overhead when several files are
to be generated - without forcing the users to rely on external tools
when these templates stay simple and that their generation in TerraForm
is justified.
This is the minimal amount of work needed to be able to create a list of a subset of subnet IDs in a VPC, allowing people to loop through them easily when creating EC2 instances or provide a list straight to an ELB.
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.
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.
Paddy