Change provider structure to best practices from terraform-provider-scaffolding project

[timofurrer]

At first glance, this change set appears to be quite huge, but actually isn't.

It basically reproduces the best practice provider structure and setup from the terraform-provider-scaffolding project.

The major changes are that:

• provider code moved from gitlab to internal/provider directory
• change provider code from gitlab to provider package
• used scaffolding setup in main.go and provider.go
• For the test code we don't re-use the Gitlab client from the provider, but I've introduced a testGitlabClient which is separate from the provider Gitlab client.
• the rest of the changes were all necessary evil

[armsnyder]

Lots of cool sdk v2 improvements!

I just want to acknowledge that moving code to internal is going to break almost all PRs and anyone who might be using this repository as a package (which they shouldn't.) What are the benefits of moving code to internal now in your opinion?

I looked at some other providers. The major first-party ones have largely moved to internal, and the major third-party ones have not yet.

[timofurrer]

@armsnyder

I just want to acknowledge that moving code to internal is going to break almost all PRs and anyone who might be using this repository as a package (which they shouldn't.) What are the benefits of moving code to internal now in your opinion?

Yes, I actually share the same hesitation towards this change. First of all, I wouldn't want to merge this before 3.9.0 is out. The reason I went for the change anyways (to be merged after 3.9.0) is because I don't foresee that there will be an "ideal" time to make it. Also I think a v4 wouldn't necessarily be it, because the target audience for the "break" is another one.

IMHO: moving it to internal doesn't provide huge benefits other than (1) that it's aligned (as you mentioned) with other popular providers and the scaffolding project and (2) that no one is using it a go dependency.

[armsnyder]

Also I think a v4 wouldn't necessarily be it

Agree

(2) that no one is using it a go dependency

That's a good reason, in case we modularize more in the future.

[github-actions]

This pull request has merge conflicts. Please rebase your branch onto master.

[github-actions]

Conflicts are resolved. Thank you! 😀

[github-actions]

This pull request has merge conflicts. Please rebase your branch onto master.

[timofurrer]

@armsnyder Are you okay if we merge this early next week? ... most open PRs have merge conflicts already, so maybe it doesn't hurt too much.

Awaiting the regression bugfix release, of course ;)

[armsnyder]

@timofurrer Sounds good, as long as it's after the 3.9.1 patch release. I don't know if you saw my two PRs for this branch, in your fork? It's up to you if you want to include those or not. I thought it might make sense to get the changes in the same PR (this one).

[timofurrer]

Yes, I'll wait for 3.9.1 - I've marked it as blocked in the meantime.

I haven't seen your PR 🙈 Let me see :)

[timofurrer]

@armsnyder I've added the changes from our two PRs - look good to me 🎉

[github-actions]

This pull request has merge conflicts. Please rebase your branch onto main.

[github-actions]

Conflicts are resolved. Thank you! 😀

[github-actions]

This functionality has been released in v3.10.0 of the Terraform GitLab Provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

For further feature requests or bug reports with this functionality, please create a new GitHub issue. Thank you!