provider/pagerduty: pagerduty_schedule data source

[heimweh]

This PR adds a new data source pagerduty_schedule

So far, the only thing we store is the actual ID of the resource,
but can easily be extended to export more attributes in the future.

Example usage:

data "pagerduty_schedule" "test" {
  name = "Daily Engineering Rotation"
}

resource "pagerduty_escalation_policy" "test" {
  name      = "Engineering Escalation Policy"
  num_loops = 2

  rule {
    escalation_delay_in_minutes = 10

    target {
      type = "schedule_reference"
      id   = "${data.pagerduty_schedule.test.id}"
    }
  }
}

[heimweh]

Tests are passing:

$ make testacc TEST=./builtin/providers/pagerduty TESTARGS='-run=TestAccDataSourcePagerDutySchedule_Basic'                                                                                          19:24:10
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /terraform/vendor/)
2017/02/01 19:24:16 Generated command/internal_plugin_list.go
TF_ACC=1 go test ./builtin/providers/pagerduty -v -run=TestAccDataSourcePagerDutySchedule_Basic -timeout 120m
=== RUN   TestAccDataSourcePagerDutySchedule_Basic
--- PASS: TestAccDataSourcePagerDutySchedule_Basic (6.45s)
PASS
ok  	github.com/hashicorp/terraform/builtin/providers/pagerduty	6.465s

[stack72]

1 small comment but LGTM!

[stack72]

We don't need the ID here - Id is exposed internally

[heimweh]

Ah good catch, that's true. I'll push a fix straight away 👍

[heimweh]

Pushed a fix now to both data sources 🙂

[stack72]

LGTM!

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.