-
Notifications
You must be signed in to change notification settings - Fork 244
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
Devfile support for odo create #2699
Devfile support for odo create #2699
Conversation
Signed-off-by: jingfu wang <jingfu.j.wang@ibm.com>
Hi @GeekArthur. Thanks for your PR. I'm waiting for a openshift member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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. |
Signed-off-by: jingfu wang <jingfu.j.wang@ibm.com>
/ok-to-test |
@yangcao77: changing LGTM is restricted to collaborators 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. |
Signed-off-by: jingfu wang <jingfu.j.wang@ibm.com>
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.
Nice changes Jingfu. I've left some review comments. Can you add some integration tests too? Since your changes don't rely on odo push
, you won't need my changes in #2681.
Additionally, if I do odo create <component>
where <component>
is a non existent devfile component, it tells me:
johns-mbp-3:odo johncollier$ ./odo create fakedevfile
✗ imagestreams.image.openshift.io "fakedevfile" not found
We shouldn't be telling them that an image stream with that name didn't exist, but rather a devfile component with that name didn't exist
Another thought I've had: I'm thinking E.g. if a devfile has:
Then odo would git clone this project (and any other projects in the devfile) during |
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.
Just small nits and small changes around component name
Sure, I can add the integration tests for
That's the current expected behavior and I agree the error message a little bit misleading. I discussed this with Elson, basically the design is we wanna support both
|
If we follow the existing odo design, |
…fileCreateCase Signed-off-by: jingfu wang <jingfu.j.wang@ibm.com>
Codecov Report
@@ Coverage Diff @@
## master #2699 +/- ##
=========================================
+ Coverage 43.48% 43.58% +0.1%
=========================================
Files 91 91
Lines 8222 8264 +42
=========================================
+ Hits 3575 3602 +27
- Misses 4298 4311 +13
- Partials 349 351 +2
Continue to review full report at Codecov.
|
Signed-off-by: jingfu wang <jingfu.j.wang@ibm.com>
Signed-off-by: jingfu wang <jingfu.j.wang@ibm.com>
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: kadel 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 |
@GeekArthur Since Integration tests are not here, could please add manual steps/example to test this PR. |
Signed-off-by: jingfu wang <jingfu.j.wang@ibm.com>
@adisky Thanks! I will add my integration tests to the corresponding |
Signed-off-by: jingfu wang <jingfu.j.wang@ibm.com>
/retest |
Signed-off-by: jingfu wang <jingfu.j.wang@ibm.com>
/retest |
spinner := log.Spinner("Validating component") | ||
defer spinner.End(false) | ||
|
||
if util.CheckPathExists(DevfilePath) || util.CheckPathExists(EnvFilePath) { |
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 this before running catalogDevfileList, err := catalog.ListDevfileComponents()
, currently if you run odo create openLiberty
and then run odo create openLiberty
in the same folder it is taking too much time to return "Devfile.yaml or env.yaml already exists
, I think this should be the first validation.
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.
By design after we implement devfile support for odo, odo needs to support both devfile and s2i components, but devfile component has higher priority.
catalogDevfileList, err := catalog.ListDevfileComponents()
helps us check devfile registry so that we can validate if the component is supported devfile component, if it's not supported devfile component we won't validate Devfile.yaml or env.yaml already exists
and we go to the existing s2i code path. That's why we call catalogDevfileList, err := catalog.ListDevfileComponents()
before Devfile.yaml or env.yaml already exists
@@ -265,6 +285,109 @@ func (co *CreateOptions) setResourceLimits() error { | |||
|
|||
// Complete completes create args | |||
func (co *CreateOptions) Complete(name string, cmd *cobra.Command, args []string) (err error) { | |||
if experimental.IsExperimentalModeEnabled() { |
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.
just a thought should we make separate function func (co *CreateOptions) completeDevfile(...)
and do like this here
if experimental.IsExperimentalModeEnabled() {
completeDevfile(...)
}
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.
By design after we implement devfile support for odo, odo needs to support both devfile and s2i components, but devfile component has higher priority.
So the experimental flag will be removed finally, currently we don't separate the generic Complete
, Validate
and Run
functions for all devfile support for odo features (eg odo create, odo push, odo url). I think the reason is it would be better for refactoring once we remove the experimental flag.
@GeekArthur I tried this out, Works well. Looks good to me. |
/retest |
2 similar comments
/retest |
/retest |
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.
@GeekArthur See my note on the integration tests, it may be what's causing the flakiness in your tests
Signed-off-by: jingfu wang <jingfu.j.wang@ibm.com>
/retest |
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.
/lgtm
/retest Please review the full test history for this PR and help us cut down flakes. |
1 similar comment
/retest Please review the full test history for this PR and help us cut down flakes. |
Signed-off-by: jingfu wang jingfu.j.wang@ibm.com
What type of PR is this?
/kind feature
What does does this PR do / why we need it:
This PR implements devfile support for
odo create
, basically theodo create
command does two things:devfile.yaml
from predefined registries to user's local file system./.odo/env/env.yaml
) and store component metadata (eg. component name, component namespace) into the the configuration fileIt covers three cases below:
odo create <component type>
odo create <component type> <component name>
odo create <component type> <component name> --project <namespace>
Note: Supported devfile component should satisfy the following conditions:
dockerimage
as component typealias
devRun
commanddevBuild
commandWhich issue(s) this PR fixes:
Fixes #2557
Fixes #2684
How to test changes / Special notes to the reviewer:
Unit tests have been done in this PR. All devfile support integration tests can start once integration test suites PR merges in.