refactor!: Split Key request bodies into CreateDeployKeyRequest, CreateUserKeyRequest and CreateSSHSigningKeyRequest and pass by value - #4477
Open
JamBalaya56562 wants to merge 2 commits into
Conversation
…`CreateUserKeyRequest` and `CreateSSHSigningKeyRequest` and pass by value Three create methods across three resources reused the 9-field Key response type as their request body, but each endpoint accepts only key (required) and title, plus read_only for deploy keys — the other six fields are server-generated. The new per-resource request types model each schema exactly, with a non-pointer Key, and are passed by value. The Key response type stays unchanged, and its entry is removed from the .golangci.yml allowlist. This also fixes a pre-existing copy-paste bug in TestUsersService_CreateSSHSigningKey, whose failure case called Users.CreateKey instead of Users.CreateSSHSigningKey. BREAKING CHANGE: RepositoriesService.CreateKey, UsersService.CreateKey and UsersService.CreateSSHSigningKey now take new CreateDeployKeyRequest, CreateUserKeyRequest and CreateSSHSigningKeyRequest (with non-pointer Key) by value instead of *Key.
gmlewis
approved these changes
Aug 21, 2026
gmlewis
left a comment
Collaborator
There was a problem hiding this comment.
Thank you, @JamBalaya56562!
LGTM.
Awaiting second LGTM+Approval from any other contributor to this repo before merging.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #4477 +/- ##
==========================================
+ Coverage 98.51% 98.53% +0.01%
==========================================
Files 195 195
Lines 17691 17691
==========================================
+ Hits 17429 17431 +2
+ Misses 262 260 -2 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
alexandear
reviewed
Aug 21, 2026
The deploy-key response schema includes an enabled boolean that was missing from the Key struct. It is deploy-key specific (the user SSH key response doesn't have it), matching how Key already carries other deploy-only fields such as added_by, so it's an optional pointer.
gmlewis
approved these changes
Aug 21, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Continues the request-body-by-value work in #3644, this time for the three key-creation endpoints that shared the
Keyresponse type as their request body.Per the docs, each endpoint accepts only a small request schema — the other six
Keyfields (id,url,verified,created_at,added_by,last_used) are server-generated — and the schemas differ per resource:keytitleread_onlyRepositoriesService.CreateKeyUsersService.CreateKeyUsersService.CreateSSHSigningKeySo this splits the body into three per-resource request types —
CreateDeployKeyRequest(withReadOnly),CreateUserKeyRequestandCreateSSHSigningKeyRequest— following the same approach as #4406/#4425/#4432/#4434/#4444.Keyis a non-pointerstringin all three since it's required everywhere. The methods keep their names (theCreateverb already matches the docs, and renaming only the create methods would break consistency with the surroundingGet/List/DeleteKeyfamilies).Also fixed in passing, since the signature change touches the exact lines: the failure case in
TestUsersService_CreateSSHSigningKeyhad a pre-existing copy-paste bug — it calledUsers.CreateKey(a different method) withmethodName = "CreateKey"; it now exercisesCreateSSHSigningKeyas intended.Notes:
Keyresponse type is unchanged — it stays the response forListKeys/GetKey/both create methods, so its fields keep pointer semantics.SSHSigningKeyis untouched.test/integration/users_test.gobuilds under the root module with-tags integration, so itsUsers.CreateKeycall is updated too (verified withgo vet -tags integration).Verified with
go build ./...,go vet -tags integration ./test/integration/,gofmt, the full./github/test suite (all three methods and the seven generated accessors at 100%), andcustom-gcl(noparamcheckfindings after removing the allowlist entry).Updates #3644
BREAKING CHANGE: RepositoriesService.CreateKey, UsersService.CreateKey and UsersService.CreateSSHSigningKey now take new CreateDeployKeyRequest, CreateUserKeyRequest and CreateSSHSigningKeyRequest (with non-pointer Key) by value instead of *Key.
cc @jvm986 — flagging for #3644 coordination; this covers the
Keytype (repos/users key endpoints), so it doesn't overlap with #4475.