-
Notifications
You must be signed in to change notification settings - Fork 883
AGPL Entitlements API #3523
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AGPL Entitlements API #3523
Conversation
Signed-off-by: Spike Curtis <spike@coder.com>
Signed-off-by: Spike Curtis <spike@coder.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FE ✅
EntitlementEntitled Entitlement = "entitled" | ||
EntitlementGracePeriod Entitlement = "grace_period" | ||
EntitlementNotEntitled Entitlement = "not_entitled" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of EntitlementEntitled
would Entitled
suffice? Seems like these are implicit Entitlement
based on the name.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the consistency of either always or never including the prefix. It'd be nice if Go would support enums natively one day.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I copied
type UserStatus string
const (
UserStatusActive UserStatus = "active"
UserStatusSuspended UserStatus = "suspended"
)
for the sake of consistency. But, if I were writing the package myself for the first time I'd have dropped the prefix. I don't really mind either way.
coderd/features_internal_test.go
Outdated
func TestEntitlements(t *testing.T) { | ||
t.Parallel() | ||
t.Run("GET", func(t *testing.T) { | ||
t.Parallel() | ||
r := httptest.NewRequest("GET", "https://example.com/api/v2/entitlements", nil) | ||
rw := httptest.NewRecorder() | ||
entitlements(rw, r) | ||
resp := rw.Result() | ||
assert.Equal(t, http.StatusOK, resp.StatusCode) | ||
dec := json.NewDecoder(resp.Body) | ||
var result codersdk.Entitlements | ||
err := dec.Decode(&result) | ||
require.NoError(t, err) | ||
assert.False(t, result.HasLicense) | ||
assert.Empty(t, result.Warnings) | ||
for _, f := range codersdk.AllFeatures { | ||
require.Contains(t, result.Features, f) | ||
fe := result.Features[f] | ||
assert.False(t, fe.Enabled) | ||
assert.Equal(t, codersdk.EntitlementNotEntitled, fe.Entitlement) | ||
} | ||
}) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doing this works around any middlewares we have that could make this not function.
Could we do this like a normal coderd
test instead? Then we'd build codersdk
functions to fetch entitlements, which seems valuable for future API consumers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I could. That makes the test more complex to write and slower to execute. This unit test is just testing the handler itself returns what we expect.
There is another test case in coderd_test.go
that hits the endpoint through all the API routing and middlewares, so that's covered too.
I agree a codersdk function is important, but that's in my next PR that will include a CLI command to display these entitlements.
coderd/features_internal_test.go
Outdated
func TestEntitlements(t *testing.T) { | ||
t.Parallel() | ||
t.Run("GET", func(t *testing.T) { | ||
t.Parallel() | ||
r := httptest.NewRequest("GET", "https://example.com/api/v2/entitlements", nil) | ||
rw := httptest.NewRecorder() | ||
entitlements(rw, r) | ||
resp := rw.Result() | ||
assert.Equal(t, http.StatusOK, resp.StatusCode) | ||
dec := json.NewDecoder(resp.Body) | ||
var result codersdk.Entitlements | ||
err := dec.Decode(&result) | ||
require.NoError(t, err) | ||
assert.False(t, result.HasLicense) | ||
assert.Empty(t, result.Warnings) | ||
for _, f := range codersdk.AllFeatures { | ||
require.Contains(t, result.Features, f) | ||
fe := result.Features[f] | ||
assert.False(t, fe.Enabled) | ||
assert.Equal(t, codersdk.EntitlementNotEntitled, fe.Entitlement) | ||
} | ||
}) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doing this works around any middlewares we have that could make this not function.
Could we do this like a normal coderd
test instead? Then we'd build codersdk
functions to fetch entitlements, which seems valuable for future API consumers.
Signed-off-by: Spike Curtis <spike@coder.com>
Relates to #3278
I intend to follow up this PR with a CLI command to view the information in the Entitlements API.
RFC description of this API