Issue labels aren't checked against Github API #245

clebio · 2019-06-25T21:02:55Z

I'm running into issues using Terraform to manage existing labels. The addition of labels to an existing set fails, and unfortunately removes labels assigned to issues, since Terraform re-orders its indexed list of labels, apparently unaware of Github's own ordering of labels. Terraform doesn't even seem to be checking Github for the existence of labels at all. This makes issue label management via Terraform impossible.

I created a new public Github repo, which by default has nine labels, and set up Terraform to add issue labels.
https://github.com/clebio/example/labels

Further, even if I manually import the existing labels,

LABS="bug documentation duplicate enhancement 'good first issue' 'help wanted' invalid question wontfix"
arr=(${LABS})
for i in `seq 0 ${#arr[@]}`; do terraform import github_issue_label.main[$i] example:${arr[$i]}; done

Adding one more in alphabetical order (as Github seems to use), causes existing labels to get reordered, and removes the existing labels from issues they were assigned to.

Terraform Version

$ terraform version
Terraform v0.12.3
+ provider.github v2.1.0

Affected Resource(s)

github_issue_label

Terraform Configuration Files

$ cat main.tf
terraform {
  required_version = "~> 0.12"
}

provider "github" {}

data "github_repository" "main" {
  full_name = "clebio/example"
}

variable "issue_labels" {
  description = "Standard set of labels for all repositories"
  type = list(object({name=string,color=string,description=string}))

  default = [
    {
      color       = "d60876"
      description = "Issue is blocked (should cross-reference to blocking issue)"
      name        = "blocked"
    },
    {
      color       = "d73a4a"
      description = "Something isn't working"
      name        = "bug"
    },
    {
      color       = "0075ca"
      description = "Improvements or additions to documentation"
      name        = "documentation"
    },
    {
      color       = "cfd3d7"
      description = "This issue or pull request already exists"
      name        = "duplicate"
    },
    {
      color       = "d876e3"
      description = "Further information is requested"
      name        = "question"
    },
    {
      color       = "cfd3d7"
      description = "This will not be worked on"
      name        = "wontfix"
    }
  ]
}

resource "github_issue_label" "standard" {
  count = length(var.issue_labels)
  repository = data.github_repository.main.name
  name       = lookup(element(var.issue_labels, count.index), "name")
  color      = lookup(element(var.issue_labels, count.index), "color")
  description = lookup(element(var.issue_labels, count.index), "description")
}

Output

Labels as they actually exist:

$ curl -H "Authorization: token `cat ~/.github.token`" https://api.github.com/repos/clebio/example/labels 2>/dev/null | jq '.[] |[.name,.color]'
[
  "bug",
  "d73a4a"
]
[
  "documentation",
  "0075ca"
]
[
  "duplicate",
  "cfd3d7"
]
[
  "enhancement",
  "a2eeef"
]
[
  "good first issue",
  "7057ff"
]
[
  "help wanted",
  "008672"
]
[
  "invalid",
  "e4e669"
]
[
  "question",
  "d876e3"
]
[
  "wontfix",
  "ffffff"
]

Terraform plan:


$ terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

data.github_repository.main: Refreshing state...

------------------------------------------------------------------------

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # github_issue_label.standard[0] will be created
  + resource "github_issue_label" "standard" {
      + color       = "d60876"
      + description = "Issue is blocked (should cross-reference to blocking issue)"
      + etag        = (known after apply)
      + id          = (known after apply)
      + name        = "blocked"
      + repository  = "example"
      + url         = (known after apply)
    }

  # github_issue_label.standard[1] will be created
  + resource "github_issue_label" "standard" {
      + color       = "d73a4a"
      + description = "Something isn't working"
      + etag        = (known after apply)
      + id          = (known after apply)
      + name        = "bug"
      + repository  = "example"
      + url         = (known after apply)
    }

  # github_issue_label.standard[2] will be created
  + resource "github_issue_label" "standard" {
      + color       = "0075ca"
      + description = "Improvements or additions to documentation"
      + etag        = (known after apply)
      + id          = (known after apply)
      + name        = "documentation"
      + repository  = "example"
      + url         = (known after apply)
    }

  # github_issue_label.standard[3] will be created
  + resource "github_issue_label" "standard" {
      + color       = "cfd3d7"
      + description = "This issue or pull request already exists"
      + etag        = (known after apply)
      + id          = (known after apply)
      + name        = "duplicate"
      + repository  = "example"
      + url         = (known after apply)
    }

  # github_issue_label.standard[4] will be created
  + resource "github_issue_label" "standard" {
      + color       = "d876e3"
      + description = "Further information is requested"
      + etag        = (known after apply)
      + id          = (known after apply)
      + name        = "question"
      + repository  = "example"
      + url         = (known after apply)
    }

  # github_issue_label.standard[5] will be created
  + resource "github_issue_label" "standard" {
      + color       = "cfd3d7"
      + description = "This will not be worked on"
      + etag        = (known after apply)
      + id          = (known after apply)
      + name        = "wontfix"
      + repository  = "example"
      + url         = (known after apply)
    }

Plan: 6 to add, 0 to change, 0 to destroy.

------------------------------------------------------------------------

Note: You didn't specify an "-out" parameter to save this plan, so Terraform
can't guarantee that exactly these actions will be performed if
"terraform apply" is subsequently run.

Expected Behavior

A terraform plan should see that labels already exist, and not try to add duplicates.
A terraform apply should account for existing labels and do ... something sensible (replace, import, fail?).

Actual Behavior

Terraform apply fails in various related ways.

$ terraform apply -auto-approve
data.github_repository.main: Refreshing state...
github_issue_label.standard[1]: Creating...
github_issue_label.standard[5]: Creating...
github_issue_label.standard[2]: Creating...
github_issue_label.standard[3]: Creating...
github_issue_label.standard[0]: Creating...
github_issue_label.standard[4]: Creating...
github_issue_label.standard[5]: Creation complete after 6s [id=example:wontfix]
github_issue_label.standard[1]: Creation complete after 8s [id=example:bug]
github_issue_label.standard[3]: Creation complete after 8s [id=example:duplicate]
github_issue_label.standard[0]: Creation complete after 9s [id=example:blocked]
github_issue_label.standard[4]: Creation complete after 9s [id=example:question]
github_issue_label.standard[2]: Creation complete after 9s [id=example:documentation]

Terraform thinks there are six issues:

$ terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

data.github_repository.main: Refreshing state...
github_issue_label.standard[5]: Refreshing state... [id=example:wontfix]
github_issue_label.standard[1]: Refreshing state... [id=example:bug]
github_issue_label.standard[2]: Refreshing state... [id=example:documentation]
github_issue_label.standard[0]: Refreshing state... [id=example:blocked]
github_issue_label.standard[4]: Refreshing state... [id=example:question]
github_issue_label.standard[3]: Refreshing state... [id=example:duplicate]

------------------------------------------------------------------------

No changes. Infrastructure is up-to-date.

and yet, Github says 10:

$ curl -H "Authorization: token `cat ~/.github.token`" https://api.github.com/repos/clebio/example/labels 2>/dev/null | jq '. | length'
10

Steps to Reproduce

create a new , empty Github repo; update data source accordingly
terraform apply
and a label after blocked in the example variable:

variable "issue_labels" {
  description = "Standard set of labels for all repositories"
  type = list(object({name=string,color=string,description=string}))

  default = [
    {
      color       = "d60876"
      description = "Issue is blocked (should cross-reference to blocking issue)"
      name        = "blocked"
    },
    {
      color       = "d60876"
      description = "Let's see how Terraform handles this"
      name        = "new-label"
    },
#...

terraform plan

$ terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

data.github_repository.main: Refreshing state...
github_issue_label.standard[5]: Refreshing state... [id=example:wontfix]
github_issue_label.standard[3]: Refreshing state... [id=example:duplicate]
github_issue_label.standard[0]: Refreshing state... [id=example:blocked]
github_issue_label.standard[1]: Refreshing state... [id=example:bug]
github_issue_label.standard[2]: Refreshing state... [id=example:documentation]
github_issue_label.standard[4]: Refreshing state... [id=example:question]

------------------------------------------------------------------------

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  + create
  ~ update in-place

Terraform will perform the following actions:

  # github_issue_label.standard[1] will be updated in-place
  ~ resource "github_issue_label" "standard" {
      ~ color       = "d73a4a" -> "d60876"
      ~ description = "Something isn't working" -> "Let's see how Terraform handles this"
        etag        = "W/\"3d80ae58003db751d97f469ea83b0f74\""
        id          = "example:bug"
      ~ name        = "bug" -> "new-label"
        repository  = "example"
        url         = "https://api.github.com/repos/clebio/example/labels/bug"
    }

  # github_issue_label.standard[2] will be updated in-place
  ~ resource "github_issue_label" "standard" {
      ~ color       = "0075ca" -> "d73a4a"
      ~ description = "Improvements or additions to documentation" -> "Something isn't working"
        etag        = "W/\"fd7b91a61d920a89349c52c8aca96b7c\""
        id          = "example:documentation"
      ~ name        = "documentation" -> "bug"
        repository  = "example"
        url         = "https://api.github.com/repos/clebio/example/labels/documentation"
    }

  # github_issue_label.standard[3] will be updated in-place
  ~ resource "github_issue_label" "standard" {
      ~ color       = "cfd3d7" -> "0075ca"
      ~ description = "This issue or pull request already exists" -> "Improvements or additions to documentation"
        etag        = "W/\"92cd6839c9bfd3e35b230c4c837ffd12\""
        id          = "example:duplicate"
      ~ name        = "duplicate" -> "documentation"
        repository  = "example"
        url         = "https://api.github.com/repos/clebio/example/labels/duplicate"
    }
# ...

terraform apply -auto-approve


$ terraform apply -auto-approve
data.github_repository.main: Refreshing state...
github_issue_label.standard[2]: Refreshing state... [id=example:documentation]
github_issue_label.standard[5]: Refreshing state... [id=example:wontfix]
github_issue_label.standard[3]: Refreshing state... [id=example:duplicate]
github_issue_label.standard[1]: Refreshing state... [id=example:bug]
github_issue_label.standard[0]: Refreshing state... [id=example:blocked]
github_issue_label.standard[4]: Refreshing state... [id=example:question]
github_issue_label.standard[6]: Creating...
github_issue_label.standard[3]: Modifying... [id=example:duplicate]
github_issue_label.standard[1]: Modifying... [id=example:bug]
github_issue_label.standard[2]: Modifying... [id=example:documentation]
github_issue_label.standard[4]: Modifying... [id=example:question]
github_issue_label.standard[5]: Modifying... [id=example:wontfix]
github_issue_label.standard[6]: Creation complete after 8s [id=example:wontfix]
github_issue_label.standard[1]: Modifications complete after 8s [id=example:new-label]

Error: PATCH https://api.github.com/repos/clebio/example/labels/documentation: 422 Validation Failed [{Resource:Label Field:name Code:already_exists Message:}]

  on main.tf line 54, in resource "github_issue_label" "standard":
  54: resource "github_issue_label" "standard" {



Error: PATCH https://api.github.com/repos/clebio/example/labels/question: 422 Validation Failed [{Resource:Label Field:name Code:already_exists Message:}]

  on main.tf line 54, in resource "github_issue_label" "standard":
  54: resource "github_issue_label" "standard" {



Error: PATCH https://api.github.com/repos/clebio/example/labels/wontfix: 422 Validation Failed [{Resource:Label Field:name Code:already_exists Message:}]

  on main.tf line 54, in resource "github_issue_label" "standard":
  54: resource "github_issue_label" "standard" {



Error: PATCH https://api.github.com/repos/clebio/example/labels/duplicate: 422 Validation Failed [{Resource:Label Field:name Code:already_exists Message:}]

  on main.tf line 54, in resource "github_issue_label" "standard":
  54: resource "github_issue_label" "standard" {

Then, terraform apply -auto-approve again:

$ terraform apply -auto-approve
data.github_repository.main: Refreshing state...
github_issue_label.standard[3]: Refreshing state... [id=example:duplicate]
github_issue_label.standard[5]: Refreshing state... [id=example:wontfix]
github_issue_label.standard[2]: Refreshing state... [id=example:documentation]
github_issue_label.standard[1]: Refreshing state... [id=example:new-label]
github_issue_label.standard[6]: Refreshing state... [id=example:wontfix]
github_issue_label.standard[4]: Refreshing state... [id=example:question]
github_issue_label.standard[0]: Refreshing state... [id=example:blocked]

Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

References

Renaming labels creates new labels. #173

The text was updated successfully, but these errors were encountered:

megan07 · 2019-06-27T17:26:24Z

Hi @clebio !

Thank you for submitting this issue. When using count in Terraform, each item is saved in state by the index from when it was created. Therefore, if you insert a new label in the 0th spot, the old 0-indexed label will basically be ‘edited’ to the new labels information, and so on and so forth down the list. Luckily, the order of the list does not need to match the order of labels in GitHub, as GitHub will handle its ordering on its own (alphabetically). My suggestion is to forego alphabetizing in your configuration file, and add any new labels you’d like to maintain to the bottom of the list.

As for Terraform not checking for existing labels, in order for Terraform to maintain the GitHub labels, the configurations needs to be set up in your main.tf file. You’ll see that in your example provided, you have 6 configured labels, so Terraform will only maintain those 6. If you add the configuration for the other 4 and either import or apply (as an apply on labels will check if the label exists, and then either update, or create as appropriate), then Terraform will be able to maintain them as well.

I was unable to see any labels being removed from issues, so it’s possible I’m misunderstanding part of what is happening. I believe GitHub associates labels by id (which is repo-name/label-name), so as long as there is still an existing label with the same name, it should not disassociate the label from the issue.

Let me know if you have further questions or if I can help with anything else!
Thanks!
Megan

clebio · 2019-06-28T17:30:16Z

Ok. I removed all but three labels, just to make imports simpler for now. Then imported them.

variable "issue_labels" {
  description = "Standard set of labels for all repositories"
  type = list(object({name=string,color=string,description=string}))

  default = [
    {
      color       = "d60876"
      description = "Issue is blocked (should cross-reference to blocking issue)"
      name        = "blocked"
    },
    {
      color       = "d73a4a"
      description = "Something isn't working"
      name        = "bug"
    },
    {
      color       = "0075ca"
      description = "Improvements or additions to documentation"
      name        = "documentation"
    },
  ]
}

Importing:

$ for i in `seq 0 ${#arr[@]}`; do terraform import github_issue_label.main[$i] example:${arr[$i]}; done
github_issue_label.main[0]: Importing from ID "example:blocked"...
github_issue_label.main[0]: Import complete!
  Imported github_issue_label
github_issue_label.main[0]: Refreshing state... [id=example:blocked]

Import successful!

The resources that were imported are shown above. These resources are now in
your Terraform state and will henceforth be managed by Terraform.

github_issue_label.main[1]: Importing from ID "example:bug"...
github_issue_label.main[1]: Import complete!
  Imported github_issue_label
github_issue_label.main[1]: Refreshing state... [id=example:bug]

Import successful!

The resources that were imported are shown above. These resources are now in
your Terraform state and will henceforth be managed by Terraform.

github_issue_label.main[2]: Importing from ID "example:documentation"...
github_issue_label.main[2]: Import complete!
  Imported github_issue_label
github_issue_label.main[2]: Refreshing state... [id=example:documentation]

Import successful!

The resources that were imported are shown above. These resources are now in
your Terraform state and will henceforth be managed by Terraform.

github_issue_label.main[3]: Importing from ID "example:"...
github_issue_label.main[3]: Import complete!
  Imported github_issue_label
github_issue_label.main[3]: Refreshing state... [id=example:]

Error: Cannot import non-existent remote object

While attempting to import an existing object to github_issue_label.main[3],
the provider detected that no object exists with the given id. Only
pre-existing objects can be imported; check that the id is correct and that it
is associated with the provider's configured region or endpoint, or use
"terraform apply" to create a new remote object for this resource.

Clean plan after that:

$ terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

data.github_repository.main: Refreshing state...
github_issue_label.main[2]: Refreshing state... [id=example:documentation]
github_issue_label.main[0]: Refreshing state... [id=example:blocked]
github_issue_label.main[1]: Refreshing state... [id=example:bug]

------------------------------------------------------------------------

No changes. Infrastructure is up-to-date.

This means that Terraform did not detect any differences between your
configuration and real physical resources that exist. As a result, no
actions need to be performed.

Then I added another label at the end of the variable:

    {
      color       = "d60876"
      description = "Let's see how Terraform handles this"
      name        = "new-label"
    },

And applied:


$ terraform apply
data.github_repository.main: Refreshing state...
github_issue_label.main[0]: Refreshing state... [id=example:blocked]
github_issue_label.main[2]: Refreshing state... [id=example:documentation]
github_issue_label.main[1]: Refreshing state... [id=example:bug]

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # github_issue_label.main[3] will be created
  + resource "github_issue_label" "main" {
      + color       = "d60876"
      + description = "Let's see how Terraform handles this"
      + etag        = (known after apply)
      + id          = (known after apply)
      + name        = "new-label"
      + repository  = "example"
      + url         = (known after apply)
    }

Plan: 1 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

github_issue_label.main[3]: Creating...
github_issue_label.main[3]: Creation complete after 2s [id=example:new-label]

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

However, when I remove the first label from the Terraform list variable, things break down:

$ terraform apply
data.github_repository.main: Refreshing state...
github_issue_label.main[1]: Refreshing state... [id=example:bug]
github_issue_label.main[2]: Refreshing state... [id=example:documentation]
github_issue_label.main[3]: Refreshing state... [id=example:new-label]
github_issue_label.main[0]: Refreshing state... [id=example:blocked]

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  ~ update in-place
  - destroy

Terraform will perform the following actions:

  # github_issue_label.main[0] will be updated in-place
  ~ resource "github_issue_label" "main" {
      ~ color       = "d60876" -> "d73a4a"
      ~ description = "Issue is blocked (should cross-reference to blocking issue)" -> "Something isn't working"
        etag        = "W/\"ff6c74ebd6e45e217ba566811cec6e69\""
        id          = "example:blocked"
      ~ name        = "blocked" -> "bug"
        repository  = "example"
        url         = "https://api.github.com/repos/clebio/example/labels/blocked"
    }

  # github_issue_label.main[1] will be updated in-place
  ~ resource "github_issue_label" "main" {
      ~ color       = "d73a4a" -> "0075ca"
      ~ description = "Something isn't working" -> "Improvements or additions to documentation"
        etag        = "W/\"3d80ae58003db751d97f469ea83b0f74\""
        id          = "example:bug"
      ~ name        = "bug" -> "documentation"
        repository  = "example"
        url         = "https://api.github.com/repos/clebio/example/labels/bug"
    }

  # github_issue_label.main[2] will be updated in-place
  ~ resource "github_issue_label" "main" {
      ~ color       = "0075ca" -> "d60876"
      ~ description = "Improvements or additions to documentation" -> "Let's see how Terraform handles this"
        etag        = "W/\"fd7b91a61d920a89349c52c8aca96b7c\""
        id          = "example:documentation"
      ~ name        = "documentation" -> "new-label"
        repository  = "example"
        url         = "https://api.github.com/repos/clebio/example/labels/documentation"
    }

  # github_issue_label.main[3] will be destroyed
  - resource "github_issue_label" "main" {
      - color       = "d60876" -> null
      - description = "Let's see how Terraform handles this" -> null
      - etag        = "W/\"1ac69f998414e21a6a63fbf0543eb9ef\"" -> null
      - id          = "example:new-label" -> null
      - name        = "new-label" -> null
      - repository  = "example" -> null
      - url         = "https://api.github.com/repos/clebio/example/labels/new-label" -> null
    }

Plan: 0 to add, 3 to change, 1 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

github_issue_label.main[3]: Destroying... [id=example:new-label]
github_issue_label.main[0]: Modifying... [id=example:blocked]
github_issue_label.main[1]: Modifying... [id=example:bug]
github_issue_label.main[2]: Modifying... [id=example:documentation]
github_issue_label.main[3]: Destruction complete after 1s
github_issue_label.main[2]: Modifications complete after 6s [id=example:new-label]

Error: PATCH https://api.github.com/repos/clebio/example/labels/blocked: 422 Validation Failed [{Resource:Label Field:name Code:already_exists Message:}]

  on main.tf line 34, in resource "github_issue_label" "main":
  34: resource "github_issue_label" "main" {



Error: PATCH https://api.github.com/repos/clebio/example/labels/bug: 422 Validation Failed [{Resource:Label Field:name Code:already_exists Message:}]

  on main.tf line 34, in resource "github_issue_label" "main":
  34: resource "github_issue_label" "main" {

Unfortunately, now plan shows no change needed, yet my Terraform state and Github are out of sync:

$ terraform apply
data.github_repository.main: Refreshing state...
github_issue_label.main[1]: Refreshing state... [id=example:bug]
github_issue_label.main[0]: Refreshing state... [id=example:blocked]
github_issue_label.main[2]: Refreshing state... [id=example:new-label]

Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

$ curl -H "Authorization: token `cat ~/.github.token`" https://api.github.com/repos/clebio/example/labels 2>/dev/null | jq '.[].name'
"blocked"
"bug"
"documentation"
"new-label"

megan07 · 2019-06-28T20:48:20Z

Hi @clebio !

One way to avoid this issue is to have one declared resource per label, rather than trying to create it from a list.

For example:

resource "github_issue_label"  "blocked" {
  repository = data.github_repository.main.name
  name        = "blocked"
  color         = "d60876"
  description = "Issue is blocked (should cross-reference to blocking issue)"
}

resource "github_issue_label" "bug" {
  repository = data.github_repository.main.name
  name        = "bug"
  color         = "d73a4a"
  description = "Something isn't working"
}
…

The way that count works is going to make it difficult to maintain any sort of ordering. You make an excellent point, that if a label is removed from anywhere in the list, the labels below it will all need to rearrange their indices again. If they are all separate resources you will be able to remove each resource and it will not affect any of the others.

Let me know if you have further questions or if I can help with anything else!
 Thanks!

clebio · 2019-06-28T21:14:32Z

Hmm. Don't use count is certainly a workaround. Not sure there's anything more to say -- maybe the provider docs should be updated to state that, for this resource?

megan07 · 2019-07-02T16:39:39Z

Hi @clebio !

I understand the frustration that the code can feel somewhat repetitive, and that it would be a good use case for count. However, this is more of an issue with Terraform itself than it is with this particular resource or provider. Because count uses indices to store things in state, it makes it impossible to re-order that list and not modify those indices. This will happen regardless of which resource is being created, or provider. I’m sure the team maintaining Terraform would be happy to hear further suggestions if you have any. Their issues are tracked here: https://github.com/hashicorp/terraform/issues. Also, feel free to ask any questions in our community portal here: https://discuss.hashicorp.com/c/terraform-providers.

I’ll close this for now with the thought that further issues and questions will be tracked in one of the places above, or if you run across another issue, a new issue will be opened.

Thanks again!

tracypholmes added the Awaiting response label Jun 28, 2019

tracypholmes removed the Awaiting response label Jun 28, 2019

megan07 closed this as completed Jul 2, 2019

clebio mentioned this issue Jul 15, 2019

Incorrect execution plan for resource using count hashicorp/terraform#22061

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Issue labels aren't checked against Github API #245

Issue labels aren't checked against Github API #245

clebio commented Jun 25, 2019

megan07 commented Jun 27, 2019

clebio commented Jun 28, 2019

megan07 commented Jun 28, 2019

clebio commented Jun 28, 2019

megan07 commented Jul 2, 2019

Issue labels aren't checked against Github API #245

Issue labels aren't checked against Github API #245

Comments

clebio commented Jun 25, 2019

Terraform Version

Affected Resource(s)

Terraform Configuration Files

Output

Expected Behavior

Actual Behavior

Steps to Reproduce

References

megan07 commented Jun 27, 2019

clebio commented Jun 28, 2019

megan07 commented Jun 28, 2019

clebio commented Jun 28, 2019

megan07 commented Jul 2, 2019