-
Notifications
You must be signed in to change notification settings - Fork 243
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
Implement odo dev --no-commands
#6855
Implement odo dev --no-commands
#6855
Conversation
✅ Deploy Preview for odo-docusaurus-preview ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
Skipping CI for Draft Pull Request. |
odo dev --no-commands
af5529c
to
f2f0b5f
Compare
4. Synchronize the local files to the Dev environment | ||
5. Start the port forwarding logic | ||
|
||
Note that this is the default behavior of `odo dev` if the Devfile does not define any commands at all. |
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.
Note that this is the default behavior of `odo dev` if the Devfile does not define any commands at all. | |
Note that this is the default behavior of `odo dev` if the Devfile does not define any Build, Run or Debug commands. |
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.
When there is only one command of a given kind, odo
currently automatically uses it even if it is not explicitly marked as the default:
odo/pkg/libdevfile/libdevfile.go
Lines 103 to 106 in b6c9c88
// if there is only one command of a given group kind, use it as default | |
if len(commands) == 1 { | |
return commands[0], true, nil | |
} |
Do we want to change that behavior?
That's why I considered limiting this to the case where there are no commands at all, like with the UDI Stack.
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.
OK, you 're right for the Default commands. I replaced my proposal with:
Note that this is the default behavior of `odo dev` if the Devfile does not define any Build, Run or Debug commands.
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.
Alright, that makes sense. I'll update it. Thanks.
pkg/libdevfile/libdevfile.go
Outdated
@@ -244,6 +244,15 @@ func HasDebugCommand(devfileData data.DevfileData) bool { | |||
return hasCommand(devfileData, v1alpha2.DebugCommandGroupKind) | |||
} | |||
|
|||
// HasCommands returns whether the Devfile has any commands. | |||
func HasCommands(devfileData data.DevfileData) (bool, 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 need to check if there are Default commands of kind Build/Run/Debug
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 need to check if there are Default commands of kind Build/Run/Debug
pkg/odo/cli/dev/dev.go
Outdated
@@ -105,6 +106,18 @@ func (o *DevOptions) PreInit() string { | |||
} | |||
|
|||
func (o *DevOptions) Complete(ctx context.Context, cmdline cmdline.Cmdline, args []string) error { | |||
if !o.noCommandsFlag { | |||
devfileObj := *odocontext.GetEffectiveDevfileObj(ctx) | |||
hasCommands, err := libdevfile.HasCommands(devfileObj.Data) |
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 think it would be more robust and adaptable if the existence of commands are checked separately when we try to run them. For example, if no Build command exists but a Run command exists, of the other way.
There is also the case when there is not default command, but the user passes the Build or Run command to consider using --build-command
and/or --run-command
f2f0b5f
to
ffbea2c
Compare
fce1400
to
8d160d6
Compare
Co-authored-by: Philippe Martin <phmartin@redhat.com>
For example, it should not be possible to call it alongside '--build-command' or '--run-command', because we won't be able to know what to do.
For consistency with how e.g., the build command works, instead of erroring out, `odo dev` will now simply log the error message and wait for new input.
As suggested in review, this makes it more adaptable. As a consequence, if the default (or single) build/run command does not exist, "odo dev" will not error out immediately; instead, it will behave a bit like "odo dev --no-commands" (by starting, but printing a warning about the missing command). The difference here is that if a run command is added later on during the dev session, "odo dev" will pick it up and run it, but "odo dev --no-commands" will continue to purposely ignore it. The existence of the optional default Build is already checked by the 'libdevfile.Build' command. It does not error out if there is no default (or single) Build command. It errors out only if the specified '--build-command' does not exist in the Devfile. Co-authored-by: Philippe Martin <phmartin@redhat.com>
…and and if there are ports to forward This prevents: i) displaying the "Waiting for the application to be ready" spinner for nothing, if there are no ports to forward ii) waiting until the timeout of 1m has expired if there was no run/debug command executed, in which case, it is less unlikely that the application ports defined in the Devfile will ever be reachable.
8d160d6
to
abd98af
Compare
Kudos, SonarCloud Quality Gate passed! 0 Bugs No Coverage information |
odo dev --no-commands
odo dev --no-commands
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.
Works great, thanks
Issue with /override Kubernetes-Integration-Tests/Kubernetes-Integration-Tests |
@rm3l: Overrode contexts on behalf of rm3l: Kubernetes-Integration-Tests/Kubernetes-Integration-Tests In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Issues with volume mounting on OpenShift. /override OpenShift-Integration-tests/OpenShift-Integration-tests |
@rm3l: Overrode contexts on behalf of rm3l: OpenShift-Integration-tests/OpenShift-Integration-tests In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
What type of PR is this:
/kind feature
/area dev
What does this PR do / why we need it:
This adds a new
--no-commands
flag to thedev
subcommand. When this flag is set, nobuild
,run
ordebug
commands are executed. More details in https://deploy-preview-6855--odo-docusaurus-preview.netlify.app/docs/command-reference/dev#running-with-no-commandsThis is useful in conjunction with the
odo run
command.This PR also changes the behavior of
odo dev
when the Devfile has no (default or single non-default)build
,run
ordebug
commands defined. For more consistency, instead of erroring out at CLI validation time, theodo dev
session starts and just prints a warning in this case. For consistency (e.g., when the build command fails), it will just wait for new input and retrigger the inner loop logic.Which issue(s) this PR fixes:
Fixes #6569
PR acceptance criteria:
Unit test
Integration test
Documentation
How to test changes / Special notes to the reviewer:
It should work the same way regardless of the target platform, e.g.:
You can also try with the Universal Developer Image Stack, which only defines a container component and no commands. Previously,
odo dev
would error out immediately, but now, it should not:odo dev
odo dev --run-command 404
odo dev --no-commands