Skip to content
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 componentType in odo list output #2730

Closed
mohitsuman opened this issue Mar 18, 2020 · 6 comments · Fixed by #2880
Closed

Add componentType in odo list output #2730

mohitsuman opened this issue Mar 18, 2020 · 6 comments · Fixed by #2880
Assignees
Labels
estimated-size/M (10-20) Rough sizing for Epics. About 1 sprint of work for one person kind/feature Categorizes issue as a feature request. For PRs, that means that the PR is the implementation
Projects

Comments

@mohitsuman
Copy link

/kind feature

Which functionality do you think we should add?

odo list -o json should mention the specific componentType associated with that component.
e.g. 'type': 'git'

Why is this needed?

With the change mentioned with this PR #2674 , it removes Source tag from the output.
The adapters workflow was using this tag to figure out the component Type as in git, binary, local.
Hence this change will help in keeping the view consistent in OpenShift connector view.

@openshift-ci-robot openshift-ci-robot added the kind/feature Categorizes issue as a feature request. For PRs, that means that the PR is the implementation label Mar 18, 2020
@jichenjc
Copy link
Contributor

I have the following , looks like the type is kept? or misunderstand the question above? Thanks

 "spec": {
                "app": "app",
                "type": "ubi",
                "source": "file://./",
                "env": [
                    {
                        "name": "DEBUG_PORT",
                        "value": "5858"
                    }
                ]
            },

@girishramnani girishramnani added this to For consideration in Sprint 182 via automation Mar 30, 2020
@girishramnani
Copy link
Contributor

@jichenjc are you planning to work on this?

@girishramnani
Copy link
Contributor

If not, I would like to work on this.

@jichenjc
Copy link
Contributor

jichenjc commented Apr 2, 2020

yes, please, I didn't plan to work on this , above are just questions to make sure understand this
thanks for asking this @girishramnani

@girishramnani
Copy link
Contributor

@mohitsuman currently the json output looks like this

( for a single component present in an application )

{
            "kind": "Component",
            "apiVersion": "odo.openshift.io/v1alpha1",
            "metadata": {
                "name": "nodejs-tesrr-hqtz",
                "namespace": "testproject",
                "creationTimestamp": null
            },
            "spec": {
                "app": "app",
                "type": "nodejs",
                "source": "file://./",
                "ports": [
                    "8080/TCP"
                ]
            },
            "status": {
                "state": "Not Pushed"
            }
        }

now the issue is that we already have a type which corresponds to the component type i.e. nodejs, java etc.

To introduce the git,local or binary information in the json output we can consider

  • source_type
  • source

@girishramnani
Copy link
Contributor

In terms of implementation we already have sourceType present as an annotation here https://github.com/openshift/odo/blob/2a56a67dc45e9ca5559a6cc243fda0e294b48e79/pkg/component/component.go#L1015.
Its just matter of exposing it for --all and current application scenerio.

I would also consider changing the standard output ( non-json one ) to have the sourceType information for consistency.

@girishramnani girishramnani self-assigned this Apr 2, 2020
@girishramnani girishramnani added the estimated-size/M (10-20) Rough sizing for Epics. About 1 sprint of work for one person label Apr 2, 2020
@girishramnani girishramnani moved this from For consideration to To do in Sprint 182 Apr 2, 2020
@girishramnani girishramnani moved this from To do to In progress in Sprint 182 Apr 9, 2020
@girishramnani girishramnani moved this from In progress to For review in Sprint 182 Apr 14, 2020
Sprint 182 automation moved this from For review to Done Apr 18, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
estimated-size/M (10-20) Rough sizing for Epics. About 1 sprint of work for one person kind/feature Categorizes issue as a feature request. For PRs, that means that the PR is the implementation
Projects
No open projects
Sprint 182
  
Done
Development

Successfully merging a pull request may close this issue.

4 participants