-
Notifications
You must be signed in to change notification settings - Fork 312
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
Fix regression with OKTETO_TOKEN
and improve DevX for invalid token
#4297
Fix regression with OKTETO_TOKEN
and improve DevX for invalid token
#4297
Conversation
3e088c7
to
24b356f
Compare
@@ -146,10 +146,6 @@ func (c *Command) UseContext(ctx context.Context, ctxOptions *Options) error { | |||
ctxOptions.IsOkteto = true | |||
} | |||
|
|||
if ctxOptions.Context == okteto.CloudURL { |
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.
removing this fixes the regression
24b356f
to
c01ab95
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #4297 +/- ##
==========================================
- Coverage 43.21% 43.19% -0.03%
==========================================
Files 371 371
Lines 30006 30015 +9
==========================================
- Hits 12967 12964 -3
- Misses 15916 15926 +10
- Partials 1123 1125 +2 |
OKTETO_TOKEN
and improve DevX for invalid token
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.
There is a variant of scenario B is not covered and it returns an Internal Server Error
.
Instead of setting an invalid value, try to set a token from another instance and you would get the internal server error. Could we also cover that case?
@@ -111,6 +111,9 @@ func doRun(ctx context.Context, servicesToTest []string, options *Options, ioCtr | |||
|
|||
// Loads, updates and uses the context from path. If not found, it creates and uses a new context | |||
if err := contextCMD.LoadContextFromPath(ctx, options.Namespace, options.K8sContext, options.ManifestPath, contextCMD.Options{Show: true}); err != nil { | |||
if err.Error() == fmt.Errorf(oktetoErrors.ErrNotLogged, okteto.GetContext().Name).Error() { |
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.
We should probably create a specific error and being able to use error.Is()
instead of comparing string values of the error. For example, not sure if we could have some problem with a trailing slash (/
) at the end of the context name at some point.
Not needed to do as part of this PR, but it should be the way to go
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.
@ifbyol I agree, that is what I've attempted to begin with, then realized that ErrNotLogged
is being used like this all over, so it's tech debt that we need to adress. I didn't want to extend the scope of this change too much, but we should look into improve it!
Signed-off-by: Andrea Falzetti <andrea@okteto.com>
Signed-off-by: Andrea Falzetti <andrea@okteto.com>
c01ab95
to
b039f9b
Compare
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.
All scenarios with the "NEW" changes work as expected. Deferring approval to @jLopezbarb or @ifbyol that have more context
Proposed changes
Fixes: DEV-344
This PR mainly includes a fix for a regression introduced in
2.27.1
causing the Okteto CLI to attempt calling the sunsetted Okteto Cloud when settingOKTETO_TOKEN
without specifying the context. Additionally, the change also aims to improve the DevX of other scenario or misconfiguration of credentials when using the environment variableOKTETO_TOKEN
.In a previous PR we changed the order in which credentials are checked, causing the unsedired behavior because of left over logic from Okteto Cloud.
I've listed below the tested scenarios. A is the actual regression. From B onwards, are improvements, mainly making sure that for invalid token the error message is meaningful.
Note: all the tests below are
okteto deploy
tests, but this regression also applies todestroy
and other commands. I've tested some of them, there are a lot of permutations, but I've tested the main ones.How to validate
Scenario A (Regression)
Description: Context file configured correctly with an Okteto context + setting a valid
OKTETO_TOKEN
✅Command:
OKTETO_TOKEN=$VALID_TOKEN okteto deploy
(exportVALID_TOKEN
with a valid token)Scenario B
Description: Context file configured correctly with an Okteto context + setting an invalid
OKTETO_TOKEN
❌Command:
OKTETO_TOKEN=123 okteto deploy
Scenario C
Description: Empty context file + invalid
OKTETO_TOKEN
❌Command:
OKTETO_HOME=$(mktemp -d) OKTETO_TOKEN=123 okteto-2.26.0 deploy
Scenario D
Description: Empty context file + valid
OKTETO_TOKEN
✅Command:
OKTETO_HOME=$(mktemp -d) OKTETO_TOKEN=$VALID_TOKEN okteto-2.26.0 deploy
(exportVALID_TOKEN
with a valid token)Scenario E
Description: context file without current context + invalid
OKTETO_TOKEN
❌Command:
Scenario F
Description: context file without current context + valid
OKTETO_TOKEN
✅Command:
CLI Quality Reminders
For both authors and reviewers: