✨ Add registry provider client and integration tests

[annawinkler]

Description

This PR was broken out of this PR.

This PR adds support for the private registry provider API.

Testing plan

To test these changes locally, create a local go project, and in the go.mod include a line similar to the following:

replace github.com/hashicorp/go-tfe => /Users/YOURUSER/go/src/github.com/hashicorp/go-tfe

Then, for a registry provider, you can test:

• Create
• Delete
• Read
• List

External links

• Registry Providers API
• Private Registry Provider Requirements

Output from tests

Including output from tests may require access to a TFE instance. Ignore this section if you have no environment to test against.

$ TFE_ADDRESS="https://example" TFE_TOKEN="example" TF_ACC="1" go test ./... -v -tags=integration -run TestFunctionsAffectedByChange

...

[sebasslash]

Great work @annawinkler and @joekarl ... I have not been able to review all of it as it is quite a hefty PR, but hopefully a lot the comments translate to the rest of the unreviewed code.

Files I've reviewed:
helper_test.go
registry_provider.go
And the List test in the registry_provider_integration_test.go

Definitely would like @brandonc and @uturunku1 to give it a pass.

[sebasslash]

Should be jsonapi:"attr,created-at,iso8601"

[sebasslash]

Should be jsonapi:"attr,updated-at,iso8601"

[sebasslash]

We follow the doc convention: // Optional: A query string to filter by registry_name even though the field being a pointer is implying that it's optional.

[sebasslash]

valid() methods go all the way in the bottom of the file ⏬
For context, file should be organized in this order:

1. Interface/struct definitions
2. Endpoint methods
3. Valid and other helper methods

[sebasslash]

unnecessary whitespace ✏️

[sebasslash]

All these validStringID() checks should probably be refactored into a valid() function and perhaps should live in the ReadOptionsStruct instead of as method params (back to my previous point). What do you think?

[annawinkler]

This has been refactored.

[sebasslash]

Duplicate for loop?

[annawinkler]

It looks like it but we create private and public registry providers in the test.

[sebasslash]

Alternatively, we can condense this logic to:

for _, p := range providers {
  assert.Contains(t, returnedProviders.Items, p)
}

Careful with assert.Contains() as it performs deep equality. (I've been burned before with Included relationships before 👉 🔥 )

[sebasslash]

Furthermore, this sort of logic (checking that the desired provider(s) exists) seems better reserved for the Create test; for this test we should only care about that endpoint returns the correct # of elements, query params work as intended and that the fields are deserialized properly (although we can reserve checking the deserialization of fields in the Read test).

[sebasslash]

For this kind of test, the usual convention is to set PageSize and PageNumber to some incredibly large number, which I think is the easiest way to verify pagination is working as intended. Here's an example:

go-tfe/workspace_integration_test.go

Lines 44 to 58 in 11a4eb9

	t.Run("with list options", func(t *testing.T) {
	// Request a page number which is out of range. The result should
	// be successful, but return no results if the paging options are
	// properly passed along.
	wl, err := client.Workspaces.List(ctx, orgTest.Name, &WorkspaceListOptions{
	ListOptions: ListOptions{
	PageNumber: 999,
	PageSize: 100,
	},
	})
	require.NoError(t, err)
	assert.Empty(t, wl.Items)
	assert.Equal(t, 999, wl.CurrentPage)
	assert.Equal(t, 2, wl.TotalCount)
	})

[sebasslash]

Can we omit the ListOptions field here?

[annawinkler]

Closing this PR in favor of the one large one since refactoring has occurred there. I'll address the review comments in PR 313.