feat: add developer support

[ChristianJacquot]

This pull request is for handling developers in Go-kong and finally to allow deck to do it.

[CLAassistant]

All committers have signed the CLA.

[ChristianJacquot]

I observe 404 errors, it seems like developers are only available on enterprise version. Is there any way to validate those entities ?

Fixed by commit 04256f9

[rainest]

Haven't reviewed this completely yet, but it'll be affected by the same issue with enabling the Portal before testing it that necessitated #30

You may want to wait for another reviewer to complete review before making changes to your PR in case #30 changes at all, but assuming it goes in as-is, tests would need to add the new runWhenEnterprise() argument, portalRequired=true, and then add test code to enable a workspace's Portal and disable it once complete.

Since adding developers further requires authentication (and by extension, basic session conifuration), your workspace Config would need some additional items. I believe this should work:

{"portal_auth": "basic-auth","portal_session_conf": map[string]interface{}{"secret":"garbage"},"portal": true}

[rainest]

Tests will need to provide Meta with a full_name when creating a developer. Note that this requires a raw JSON string. Currently they fail:

POST /developers HTTP/1.1
Host: localhost:8001
User-Agent: Go-http-client/1.1
Content-Length: 55
Content-Type: application/json
Accept-Encoding: gzip

{"email":"foo@example.com","custom_id":"custom_id_foo"}

HTTP/1.1 400 Bad Request
Date: Mon, 29 Mar 2021 22:03:33 GMT
Content-Type: application/json; charset=utf-8
Connection: keep-alive
Access-Control-Allow-Origin: *
X-Kong-Admin-Request-ID: LkfFBBPxW4CwbJEgwHV1FjJz0t7PWYnK
vary: Origin
Content-Length: 67
X-Kong-Admin-Latency: 14
Server: kong/2.3.2.0-enterprise-edition

{"fields":{"meta":{"full_name":"required field missing"}},"code":2}

[ChristianJacquot]

I added what was recommended concerning the password and meta fields. What should we do next, wait for the merging of the pull request #30 ?

[rainest]

Yeah, once #30 is reviewed and merged, rework tests against it final merged version to enable the Portal and set other Portal settings needed for this.

Edit: go figure, wrote this before seeing that #30 had been approved. It's now in and tests support enabling the Portal and cleaning up workspaces after, so please add similar gates for the tests here. Assuming I got the config interface correct earlier, the intialization config should be like:

{"portal_auth": "basic-auth","portal_session_conf": map[string]interface{}{"secret":"garbage"},"portal": true}

Something is still going wrong with part of the tests when I set up the Portal manually first. The updated developer isn't being set properly from the Update() return, and instead it returns a developer with all fields nil:

> github.com/kong/go-kong/kong.TestDevelopersService() ./developer_service_test.go:45 (PC: 0x84ada6)
    40:		assert.Nil(err)
    41:		assert.NotNil(developer)
    42:	
    43:		developer.Email = String("bar@example.com")
    44:		developer, err = client.Developers.Update(defaultCtx, developer)
=>  45:		assert.Nil(err)
    46:		assert.NotNil(developer)
    47:		assert.Equal("bar@example.com", *developer.Email)
    48:	
    49:		err = client.Developers.Delete(defaultCtx, createdDeveloper.ID)
    50:		assert.Nil(err)
(dlv) p developer
*github.com/kong/go-kong/kong.Developer {
	CreatedAt: *int nil,
	ID: *string nil,
	Status: *int nil,
	Email: *string nil,
	CustomID: *string nil,
	UpdatedAt: *int nil,
	Roles: []*string len: 0, cap: 0, nil,
	RbacUser: *github.com/kong/go-kong/kong.RBACUser nil,
	Meta: *string nil,
	Password: *string nil,}

That then panics when it attempts to assert the Email equality.

Not immediately sure what's causing that: the update does in fact go through (I can see the modified email when looking at the admin API) and there's nothing that jumps out as unusual in the developer Update() function that suggests why on initial review.

[mmorel-35]

Is the database the same between two tests execution? Could it be related to the consumer table?

[rainest]

Is the database the same between two tests execution?

Sort of--with manual runs you have to rely on the tests cleaning up after themselves, and while most do (they delete the objects they create and confirm they're gone at the end), a test failing in the middle means that cleanup won't happen. If that occurs, or if the cleanup is imperfect, I'll run this between tests to clear it:

kong stop; kong migrations reset -y; kong migrations bootstrap; kong start

Since these didn't have the Portal setup scaffolding yet, I'd just been deleting the developer to leave the Portal configuration I'd added manually in place. Leftover data from previous runs shouldn't be the cause of the empty Update() response since the leftovers usually manifest earlier in the test: the Create() call will fail because it violates a unique constraint/attempts to create an entity that was already created, not the Update() call.

You're not seeing the same when you test locally then? Can you confirm what you set in the Portal config and what version you're testing against?

[rainest]

f863f02 is interesting; thanks for figuring out that oddity.

https://github.com/Kong/go-kong/runs/2249818490 is a CI run for branch on this repo that includes this suggestion along with the rest of the PR. Pulling fork branches into local repos is a bit of a clunky solution to make Enterprise CI run/work around GitHub limitations on secret use in PRs from forks, but it works.

[rainest]

@ChristianJacquot apologies for this being a bit late, but please fill out the following form to claim your contributor swag as thanks for this contribution:
https://github.com/Kong/kong/blob/master/CONTRIBUTING.md#contributor-t-shirt.