-
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 run-command
flag to odo dev
to run non-default Run command
#5878
Add run-command
flag to odo dev
to run non-default Run command
#5878
Conversation
✅ Deploy Preview for odo-docusaurus-preview ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
cmdName string, | ||
kind v1alpha2.CommandGroupKind, | ||
handler Handler, | ||
ignoreCommandNotFound bool, |
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.
In what case this boolean would be useful? What if user provides a custom command of certain kind and has set this boolean to true
? Could you also brief this in function's comment?
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.
The use case for this was mainly for the Build
command. The previous behavior I noticed was ignoring errors if the Devfile does not have any Build commands.
I'll update the description of this function - thanks.
commands, err := data.GetCommands(common.DevfileOptions{}) | ||
// getDefaultCommand iterates through the devfile commands and returns the default command associated with the group kind. | ||
// If there is no default command, the second return value is false. | ||
func getDefaultCommand(devfileObj parser.DevfileObj, groupType v1alpha2.CommandGroupKind) (v1alpha2.Command, 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.
A plural for default command? Is it possible to have multiple default commands for the same group kind in a devfile?
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.
Ah, OK. It's an error to have multiple default commands. Isn't this already covered in the devfile validator? 🤔
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.
Where is this Devfile validator? And when is it called in odo
? I basically used what was done before, but if it is already validated elsewhere, we can remove this check here.
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.
Where is this Devfile validator? And when is it called in
odo
?
Lines 15 to 19 in 33733a0
func parseDevfile(args parser.ParserArgs) (parser.DevfileObj, error) { | |
devObj, varWarnings, err := devfile.ParseDevfileAndValidate(args) | |
if err != nil { | |
return parser.DevfileObj{}, err | |
} |
I basically used what was done before, but if it is already validated elsewhere, we can remove this check here.
@feloy came up with libdevfile
package as a way to add things on top of devfile library. These could eventually be put into the library itself. But that's a different story. Point is, you don't need to remove a check unless you can find a counterpart in devfile library.
/lgtm |
/approve |
[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 |
Few functions used to have similar but slightly different logic, which could make them quite confusing to use. This also fixes a behavior which is not supposed to be part of the Devfile spec: in the past, if a Devfile contains a single but non-default command for a given kind, this command would get returned as the Default command for such kind. Now, an explicit error is returned instead if this single command is not marked as default in the Devfile.
978f52a
to
068d864
Compare
Kudos, SonarCloud Quality Gate passed! 0 Bugs No Coverage information |
/lgtm |
/retest-required |
/test v4.10-integration-e2e |
/override ci/prow/v4.10-integration-e2e Doesn't pass in Prow due to the same issues with SBO. Overriding because IBM Cloud tests are passing. |
@rm3l: Overrode contexts on behalf of rm3l: 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 Unit tests passing in IBM Cloud. |
@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. |
…edhat-developer#5878) * Add documentation * Add integration test cases * Refactor functions in 'pkg/libdevfile/libdevfile.go' Few functions used to have similar but slightly different logic, which could make them quite confusing to use. This also fixes a behavior which is not supposed to be part of the Devfile spec: in the past, if a Devfile contains a single but non-default command for a given kind, this command would get returned as the Default command for such kind. Now, an explicit error is returned instead if this single command is not marked as default in the Devfile. * Add `run-command` to `odo dev`, to run non-default run commands * Fix documentation of a few libdevfile functions, as suggested in review
What type of PR is this:
/kind feature
/area dev
What does this PR do / why we need it:
See #5775 for the use case.
Which issue(s) this PR fixes:
Fixes #5775
PR acceptance criteria:
Unit test
Integration test
Documentation
How to test changes / Special notes to the reviewer:
odo dev --run-command <command>
should allow to run the specified<command>
, provided it is in therun
group.