[FEATURE] Enhanced Error Messaging for Nonexistent Build Runs in Shipwright CLI
Is there an existing feature request for this?
- [X] I have searched the existing feature requests
Is your feature request related to a problem or use-case? Please describe.
Currently, when a user requests logs for a build run from a namespace that doesn't exist or lacks build runs, the CLI returns repeated messages indicating that
no builder pod was found for the specified build run
. While these messages technically convey the absence of the requested resources, they do not provide clear context or guidance to the user.
Describe the solution that you would like.
To improve user experience and facilitate better understanding, I propose implementing more informative error messages in such scenarios. For example:
If the specified namespace does not exist: "Error: Namespace 'xyz' not found. Please ensure that the namespace exists and try again."
If the specified namespace exists but contains no build runs: "Error: No build runs found in namespace 'xyz'. Please initiate a build run or verify the namespace."
If the specified build run is not found in the namespace: "Error from server (NotFound): Build run 'buildah-golang-build-61855' not found in namespace 'xyz'."
Describe alternatives you have considered.
No response
Anything else?
By incorporating these detailed error messages, users will have better clarity on the status of their requests and can take appropriate actions accordingly. This enhancement would significantly enhance the usability and user-friendliness of the Shipwright CLI.
This issue is addressed in issue #244 and PR #278.
The only option that is lacking is this one because there's no command that lets user search a specific buildrun : If the specified build run is not found in the namespace: "Error from server (NotFound): Build run 'buildah-golang-build-61855' not found in namespace 'xyz'."
If we want to implement this too, please let me know, we can create a sepeate issue to address this and i would love to work on this! @qu1queee
/assign
Given this issue has been addressed separately (with a merged fix), I am going to close this issue as a "duplicate" of #244. Please add a comment if any further message improvements are needed.