Support "internal" repository types

[mindfulmonk]

Hi,

Currently the provider only supports private = true, but there is now a new type called internal.
I think this should now be switched to a new variable called visibility with three possible values public,private and internal

References:
https://www.terraform.io/docs/providers/github/r/repository.html#private
https://help.github.com/en/github/creating-cloning-and-archiving-repositories/creating-an-internal-repository

[alexbde]

Any update on this? We are really looking forward to this.

Details on API: https://developer.github.com/v3/repos/#parameters-4

[vikkyomkar]

@jcudit I would like to work on this issue

[jcudit]

@vikkyomkar that is great to hear. I can help with breaking down the work if needed as well as validating acceptance tests pass once a PR is up for review.

Please mention me if there is any support needed while you work through this. Thanks again for volunteering!

[benj-fletch]

Hi @vikkyomkar / @jcudit - is this actively being worked on still? I would also like to work on this issue if you are not actively working on it? Thanks

[sheldonhull]

I recently adapted my team for using github to manage our repos, and found it also missing the internal setting. Only adding comment instead of a plus + here to make sure it's bumped in attention. Following

[jcudit]

Thanks for the bump. I am in favour of opening this one up to another collaborator if @vikkyomkar has no objections within a week.

[sheldonhull]

Github Documentation indicates the valid types are:

Can be one of all, public, private, forks, sources, member, internal. Default: all. If your organization is associated with an enterprise account using GitHub Enterprise Cloud or GitHub Enterprise Server 2.20+, type can also be internal.

I'd love to contribute if this is straight forward (newer to Go). To your knowledge, is it simply added a new valid value type for internal, or are there more complex requirements that change based on an internal flag (such as need to lookup an organization, even though it's the provided as the "Owner" for the repo)?

If it's simply adding a new value then I'd be willing to dig in and take a first swing at this, just wanted to ask so I don't spin my wheels on something that has more complex requirements I'm not aware of.

[jcudit]

@sheldonhull I agree with @mindfulmonk that we should add a new visibility parameter, leaving the internal parameter intact. This aligns our interface with that of the underlying go-github client library and ultimately the GitHub API.

We would then have to document and write acceptance test cases to ensure the new parameter behaves as expected alongside the existing internal parameter:

The visibility parameter overrides the private parameter when you use both parameter

---

Let us know if you're interested in claiming this one. If not, other contributors should feel free to claim it by posting to the thread.

[patrickmarabeas]

Got this feature merged into (google/go-github#1471) last week and it's been released in v30.1.0 - so don't forget to update the go-github dependency.

[sheldonhull]

How do effectively track this to know when it's released in terraform-provider-github? Is it when the issue is closed?

[patrickmarabeas]

@sheldonhull releases are done on request. New versions are tagged on master - so anything merged before that point.

[gesellix]

Related: PR #424 makes the dependency update for go-github.

[patrickmarabeas]

Looks like no one is claiming this @jcudit - happy to do so

[patrickmarabeas]

Added the functionality in: #441. This should be rebased once #424 is merged.

[grispin]

I saw @patrickmarabeas changes were removed from v2.8.0 last week. When can will a release be done with internal support included?

[gesellix]

@grispin see https://github.com/terraform-providers/terraform-provider-github/milestone/8 with PR #454.

[sheldonhull]

When reviewing the commit 3a52bc6 itself, I see it tagged with 2.9.0,2.9.1,2.9.2

What should I use to know? Can anyone give me a quick idea of how to verify this commit is actually in a release?

[match-caseydaniell]

When reviewing the commit 3a52bc6 itself, I see it tagged with 2.9.0,2.9.1,2.9.2

What should I use to know? Can anyone give me a quick idea of how to verify this commit is actually in a release?

I am setting my version locally to 2.9.0, it seems like a regression occurred in the 2.9.x series and broke the internal repo visibility and a few other settings. I haven't revised with the latest release in a while.