-
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
Add support for composite run/debug commands #5841
Add support for composite run/debug commands #5841
Conversation
✅ Deploy Preview for odo-docusaurus-preview canceled.
|
…'.odo_cmd_<name>.pid' The implementation in kubeexec.go is indeed able to run any kind of commands, not only Devfile-related.
Drop validation rules that prevented from going further with composite run or debug commands.
…point overridden or env vars updated The previous implementation was limited to Exec commands solely. This now makes it easier to support other kind of commands. For example, when handling a composite command, we are now recursively determining the containers (a.k.a components) that would get used by this composite command.
This allows to more accurately determine how the process could be reported.
9b8e50c
to
8595906
Compare
This way, users would be able to display them (and follow them) with `odo logs` or `kubectl logs`
Thanks!
I'll test with this Devfile, but you had to do that only with the containers used by the build command, right? |
Yes, you are right, only for build containers. Here is a more appropriate devfile to illustrate (with 2 sleeperbuild and sleeperrun containers instead of one common one):
|
Okay, I see. Because currently, we are adding the It makes sense to me to do the same thing for Build containers, if any. I'll change that as well. Following the grooming discussion about supporting exec commands for Deploy, I think we should actually do the same thing for all container components, regardless of the kind of the command. What do you think? (But this would be done in the scope of #5701) |
Yes, I think so also |
Build commands (which could also be composite ones) might be executed in a container different from the run or debug ones.
…D 1 process streams This way, we can also have them displayed with `odo logs` or `kubectl logs`. This includes Build and Devfile events commands.
…ere not empty This reduces the clutter in case of an error with the command execution.
…ebug commands running in different containers and with a shared volume)
3c14855 adds an integration test case with a more complex Devfile, i.e. with commands running in different containers. Thanks @feloy for the Devfile you sent me, which I took inspiration from. I also fixed the issue with missing |
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.
/approve
Just a comment about the spinner for the app
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: feloy The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
…elated command is done
Kudos, SonarCloud Quality Gate passed! 0 Bugs No Coverage information |
/lgtm |
/override ci/prow/unit Tests pass on IBM cloud |
@feloy: Overrode contexts on behalf of feloy: ci/prow/unit 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. |
/override ci/prow/v4.10-integration-e2e Tests pass on IBM Cloud |
@feloy: Overrode contexts on behalf of feloy: ci/prow/v4.10-integration-e2e 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. |
/override ci/prow/unit |
@rm3l: Overrode contexts on behalf of rm3l: ci/prow/unit 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. |
/override ci/prow/v4.10-integration-e2e |
@feloy: Overrode contexts on behalf of feloy: ci/prow/v4.10-integration-e2e 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. |
* Change integration test expectations regarding composite run commands * Add integration test supporting composite debug commands * Rename in-container pid file from '.odo_devfile_cmd_<name>.pid' into '.odo_cmd_<name>.pid' The implementation in kubeexec.go is indeed able to run any kind of commands, not only Devfile-related. * Pave the way to supporting composite run/debug commands Drop validation rules that prevented from going further with composite run or debug commands. * Update logic for determining which containers should have their entrypoint overridden or env vars updated The previous implementation was limited to Exec commands solely. This now makes it easier to support other kind of commands. For example, when handling a composite command, we are now recursively determining the containers (a.k.a components) that would get used by this composite command. * Store the process exit code in the pid file handled by kubeexec.go This allows to more accurately determine how the process could be reported. * Fix issue with util#DisplayLogs potentially not picking the last element of lines * Make sure to execute the Build command only once when running a composite command * Test that the Build command is executed once running a composite command * Make sure not to retrieve the parent default command uselessly * Log the command Id when it is about to be restarted * Redirect build command logs to PID 1 process This way, users would be able to display them (and follow them) with `odo logs` or `kubectl logs` * Handle Errored case when logging information about the process that exited * Make sure to override container entrypoint if needed for Build commands Build commands (which could also be composite ones) might be executed in a container different from the run or debug ones. * Redirect output from commands handled by component.exec_handler to PID 1 process streams This way, we can also have them displayed with `odo logs` or `kubectl logs`. This includes Build and Devfile events commands. * Make remotecmd#ExecuteCommand log stdout or stderr content only if there not empty This reduces the clutter in case of an error with the command execution. * Add integration test with more complex Devfile (composite build/run/debug commands running in different containers and with a shared volume) * Update the 'Executing the application' spinner accordingly when the related command is done
What type of PR is this:
/kind feature
/area devfile-spec
What does this PR do / why we need it:
This improves our coverage of the Devfile spec, by supporting composite commands as run or debug commands for
odo dev
.Which issue(s) this PR fixes:
Fixes #5054
PR acceptance criteria:
Unit test
Integration test
Documentation
How to test changes / Special notes to the reviewer:
Example of devfile with composite run commands: https://github.com/rm3l/odo/blob/5054-add-support-for-composite-run-commands/tests/examples/source/devfiles/nodejs/devfileCompositeRunAndDebug.yaml