feat: implement github_issue_labels resource

[galargh]

Resolves #1247

Behavior

Before the change?

There was no resource for managing all the labels for given repository. The only option was to manage each label individually which is unsustainable for big organisations.

After the change?

This change adds a new resource github_issue_labels which can be used to manage all the labels in a repository with a single resource.

Other information

Unlike github_issue_label, github_issue_labels cannot ensure continuity for labels through significant name changes. I.e. if a label name changes (providing the change is more significant than a casing change), the resource will delete the old label and create a new one. One way to go around it I could think of was to introduce user provided IDs per label but I thought it would complicate the new resource too much.

Another considerable design choice I made was not to assume refresh in create/update CRUD operation. After executing that operation, the resource will update the state with information about newly created labels, updated labels and untouched labels BUT it will not pull information about labels created outside of terraform, for example. The latter is reserved for read operation only. Thanks to this, it is possibly to call terrafrom apply -refresh=false and have an empty plan after the operation even if some labels were created outside. This is a specific edge case but it's significant to the project I'm working on - GitHub Management - and seems to fit well with the tf philosophy.

---

Additional info

Pull request checklist

• Tests for the changes have been added (for bug fixes / features)
  • TF_ACC=1 go test -v ./... -run ^TestAccGithubIssueLabels$
  • I also tried using the newly added resource and it seems to be behaving correctly - https://github.com/galargh/terraform-provider-github/releases/tag/v5.25.2-rc9
• Docs have been reviewed and added / updated if needed (for bug fixes / features)
• Added the appropriate label for the given change

Does this introduce a breaking change?

Please see our docs on breaking changes to help!

• Yes (Please add the Type: Breaking change label)
• No

If Yes, what's the impact:

• N/A

Pull request type

Please add the corresponding label for change this PR introduces:

• Bugfix: Type: Bug
• Feature/model/API additions: Type: Feature
• Updates to docs or samples: Type: Documentation
• Dependencies/code cleanup: Type: Maintenance

---

[nickfloyd]

Hey @galargh, Thanks for the contributions here! Overall they look great; I have a clarifying question regarding the design choices - thank you for the explanation above, the docs, and the tests - it helped me understand the challenges you were facing.

Encapsulating the inferred delete in an "update" might be problematic. The reason is that when you delete labels, they become disassociated from any issues, PRs, etc... that they were used with. Part of the challenge is around the label deletion's side effects.

Given that, what are your thoughts on consumers using the implementation you provided for Delete (resourceGithubIssueLabelsDelete) first so they could explicitly perform the destructive operation? They could then follow it up with a Create.

Disallow name changes in update (or only allow casing changes - IDK). Let me know your thoughts, and I could be missing an aspect of the need here as well, but the separation of concerns as described above seems more clear and simplistic.

[galargh]

Encapsulating the inferred delete in an "update" might be problematic. The reason is that when you delete labels, they become disassociated from any issues, PRs, etc... that they were used with. Part of the challenge is around the label deletion's side effects.

Hey! Thanks for the comment. This ⬆️ is the biggest challenge about using "collective" github issue labels resource rather than per-label github issue label one. I think it'd make sense to add a note about it to the description of the resource. I'll take care of it shortly.

Given that, what are your thoughts on consumers using the implementation you provided for Delete (resourceGithubIssueLabelsDelete) first so they could explicitly perform the destructive operation? They could then follow it up with a Create.

I think the only consumer of all the CRUD methods is really just the terraform plugin engine. resourceGithubIssueLabelsDelete is used when the entire resource is removed from the configuration and it deletes all the labels. Whereas resourceGithubIssueLabelsCreate is used when the resource is added to the config. Terraform plan should correctly advertise to end users that when a label is changed, it's recreated.

[jmalloc]

Is there anything I can do to help get this merged?

[nickfloyd]

Apologies for the delay on this. We'll be taking a look today!

[nickfloyd]

Thanks for the contributions here! ❤️