WIP: support repository_custom_properties resource and datasource

[felixlut]

Resolves #1956 (doesn't resolve that whole issue, but contributes to it)

Custom properties are defined on an organizational level, and then applied on a repository level. This PR aims to solve the latter of those two, while the former already has a PR for it in #2107.

This is a work in progress (WIP) since the underlying sdk:s are lacking for the REST endpoints pertaining to the repository level custom properties:

• Regular go-github lacks support for the multi_select custom property type, see https://github.com/google/go-github/issues/3198. There is a PR close to being merged for solving this https://github.com/google/go-github/pull/3200
  • The PR is merged, but no new release of go-github has been released since
• As @kfcampbell mentioned here, the GitHub SDK team has created a SDK generated from GitHub's OpenAPI spec. I've added and used it to implement a github_repository_custom_properties datasource with it due to the lacking functionality of go-github in this area currently. I'm currently trying to get it to write the custom properties, which I've been unsuccessful in so far. See https://github.com/octokit/go-sdk/issues/90
  • Reworked the github_repository_custom_properties datasource to github_repository_custom_property (notice propertIES --> propertY), which fetches a specific property instead of all of them after discussion in https://github.com/integrations/terraform-provider-github/pull/2107#discussion_r1677557505

If there's any progress on either of these I'll update this PR

---

Before the change?

After the change?

Pull request checklist

• [ ] Tests for the changes have been added (for bug fixes / features)
• [ ] Docs have been reviewed and added / updated if needed (for bug fixes / features)

Does this introduce a breaking change?

Please see our docs on breaking changes to help!

• [ ] Yes
• [ ] No

---

[ViktorLindgren95]

@felixlut It seems that v64 https://github.com/google/go-github/pull/3240 added support for Multi select finally. Only issue is that the terraform provider codebase is still at v63

[felixlut]

@felixlut It seems that v64 google/go-github#3240 added support for Multi select finally. Only issue is that the terraform provider codebase is still at v63

Seems like #2359 will deal with bumping the dep, so I'll revisit this once it's merged

[felixlut]

I started looking into this again over the weekend but hit a bottleneck again. I made a fix in https://github.com/google/go-github/pull/3309, but that requires another bump of the go-github provider. Hopefully that is the last blocker before we can use that provider fully for this feature.

The reason I'd rather use that than the go-sdk is that the PR simply becomes huge, and anytime another PR is merged I have to resolve conflicts (or at least run the risk of it). Dealing with that on a long-living PR like this is pretty painful. Using the go-github will skip that pain 😅

[stevehipwell]

@felixlut given that go-github has been updated to v66 are you now unblocked?

[felixlut]

@felixlut given that go-github has been updated to v66 are you now unblocked?

Will take a look again in the coming week or so

[ChaosCypher]

🚀

[hashildy]

Any update on getting this PR merged? This would be a really useful enhancement to support custom properties!

[felixlut]

Aight, long time coming but I finally think this PR is in a reviewable state! I've made some comments on certain parts where I'm not 100% sure on the design, I'd love to get some opinions on those! Of the bat these 2 things are noteworthy as well:

1. I opted for a non-authoriative custom_propertY resource as opposed to an authoriative custom_propertIES resource. Reason being that fulfills the use-case I have. I think an authoriative resource should exist, as it has its uses similarily to github_repository_collaborators. Nothing stops later PR:s doing just that
   • On a similar note I opted opted out of adding custom_property to github_repository, as proposed here for the same reason. Nothing stops future PR:s here either. Docs just needs to reflect that both shouldn't be used as the same time
2. For the data_source I opted for custom_propertIES over reading each property individually. The reason for this is that the API endpoint for reading custom properties on a repo returns ALL properties. Filtering that full list and returning just 1 property seemed redundant to me. With that said creating a custom_propertY data source should be trivial with a future PR 😄

Also, thanks @ViktorLindgren95 for juggling some ideas regarding this PR with me, much appreciated!

@hashildy it hasn't moved since my last message ^^

It is ready for review though (or at least it was 2m ago).

[hashildy]

@stevehipwell - is this PR able to be reviewed/merged?

[stevehipwell]

@hashildy I'm just a contributor, I have 9 PRs that have been ready to review merge in the last 3 months that haven't had a single comment by a maintainer.

[tayven-bigelow]

@kfcampbell - Any chance of getting a review / approval of this PR? Custom properties would be great to have support around in terraform.