Conversation
✅ Testkube GitHub IntegrationReview based on commit All tests and quality gates passed.
7 workflows executed
|
igmagollo
force-pushed
the
tkc-6852-webhooks-clierror
branch
from
September 15, 2026 19:58
3e185bd to
e4bc79e
Compare
igmagollo
marked this pull request as ready for review
September 15, 2026 20:26
Contributor
 |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
…ce hints The webhook commands, and the four resource packages that follow them, fail on the same handful of things: building the API client, reading a resource, writing one, and printing the result. Adds the codes and the hints for those so each package is a transcription rather than a new set of decisions. TKErrAPIClientInitFailed sits at 1807 in the auth block rather than with the resource codes. GetClient fails on the context and the credentials, so a reader who looks the code up should land on authentication, which is where their problem is, not on the resource command that happened to run. TKErrAPIReadFailed and TKErrAPIWriteFailed split the same way the agent codes do: a read and a write fail for the same reasons, so the code says which was attempted and the title carries the verb. They are API codes, not Resource codes, because TKErrResourceNotFound and TKErrResourceLookupFailed already own the cluster meaning in the 17xx block and a second Resource pair with an API meaning is where the next person has to stop and think. TKErrOutputRenderFailed covers the command that got its result and could not print it. The fetch worked, so its hint names the output flags. APIClientHint names the kubeconfig before the credentials. On the default proxy client the token paths are unreachable and the kubeconfig is what breaks, so a Pro-only hint would point the common case at the wrong thing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Converts the 26 exits of `testkube create webhook`, `get webhook`, `get webhooks`, `delete webhook` and `update webhook`. The client, the reads, the writes and the rendering take the new API codes, the flag failures take TKErrInvalidRuntimeParameter, and the webhook that is missing or taken takes TKErrResourceNotFound and a name hint. `get webhook <name>` branches on apiclient.IsNotFound before it builds the error. A typo in the name is the usual way that command fails, and reporting it as a read that did not complete would contradict what the code means and what update.go already does with the same condition. A delete keeps one code for every failure, 404 included. That is what the agents package does, and APIDeleteHint exists to name '--ignore-not-found' for the resource that is already gone. NewCreateWebhookOptionsFromFlags no longer exits while reading the payload template. Every other branch in it returns, and both callers already map its error, so the exit was the odd one out. Its twin in the update helper wrapped the same failure without a separator colon; both read the same way now. The titles no longer carry the namespace, which leaves create with no reader for the '--namespace' flag it read directly: every use of that variable comes after GetClient returns the namespace it resolved. The dead read goes, and the variable is declared with the client it arrives with. The confirmation prompt keeps ui.Failf. Declining an overwrite is a choice, not a failure, and dressing it up as a Testkube Error with a code and a Slack invitation teaches people to ignore the codes that matter. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
igmagollo
force-pushed
the
tkc-6852-agents-error-foundations
branch
from
September 16, 2026 14:21
1f43673 to
5538dad
Compare
igmagollo
force-pushed
the
tkc-6852-webhooks-clierror
branch
from
September 16, 2026 14:21
e4bc79e to
b84e359
Compare
update and create both threw away the error from GetWebhook and read the returned name instead. A lookup that fails on authentication, connectivity or any non-404 response also returns a zero-value webhook. So update printed "Webhook not found" with TKErrResourceNotFound, and create went ahead and created the webhook. Both point the user, and any automation reading the code, at the wrong fix. Keep the error and check it with apiclient.IsNotFound. TKErrResourceNotFound now means an actual 404, and everything else reports TKErrAPIReadFailed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
igmagollo
force-pushed
the
tkc-6852-webhooks-clierror
branch
from
September 17, 2026 19:15
7562568 to
2392bbd
Compare
Contributor
Author
This branch has not been deployed
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
1 participant
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.
Pull request description
Second package after agents. The 26 exits in create/get/delete/update webhook now report a code, a title and a hint instead of
getting client: connection refused.The codes and hints are shaped for the four packages after this one (webhooktemplates, testtriggers, workflowtriggers, testworkflowtemplates), which should be mostly transcription.
Two calls worth a look:
TKErrAPIClientInitFailedsits at 1807 in the auth block, not with the resource codes. GetClient fails on the context and the credentials, so that's where someone looking up the code should land.They're
API*codes, notResource*. 17xx already ownsTKErrResourceNotFoundandTKErrResourceLookupFailedwith a cluster meaning, and a second Resource pair meaning the Testkube API is exactly where the next person has to stop and think.Checklist (choose whats happened)
Breaking changes
Changes
TKErrAPIClientInitFailed(1807) and a 19xx block:TKErrAPIReadFailed,TKErrAPIWriteFailed,TKErrOutputRenderFailed, plus 11 hint constantsget webhook <name>branches onapiclient.IsNotFoundtoTKErrResourceNotFound, matching update.go and the agents packageNewCreateWebhookOptionsFromFlagsreturns its payload-template error instead of exiting, like every other branch in it already didui.Failf. It's a choice, not a failure, and a TKERR code on it teaches people to ignore TKERR codesFixes
--namespaceand never used it. Every reader of that variable runs after GetClient returns the namespace it resolved