`odo init` interactive mode: allow setting detected ports when Devfile has multiple container components

[rm3l]

/kind user-story

User Story

As an odo user, I want to be able to set the ports detected automatically by odo when calling odo init interactively even if the suggested Devfile has many container components So that I can have my Devfile initialized right away with the right ports without having to edit it later on.

#5863 added the ability to automatically detect my application ports from the source code and use that as ports when initializing a Devfile interactively, but odo currently shows a warning if the Devfile has multiple container components: https://github.com/redhat-developer/odo/blob/b481d4c4106f5abbca50d2608415d0c8c5485dac/pkg/init/backend/applicationports.go#L33-L39

As discussed in https://github.com/redhat-developer/odo/issues/6211#issuecomment-1293075852, there might be issues with Devfiles that have more than one container components. ~https://github.com/redhat-developer/odo/issues/6919 handles the simpler case of a Devfile that has at most one container component, and the goal of this issue is to handle the case where the Devfile has more than one container component when running odo init interactively. https://github.com/redhat-developer/odo/issues/6923 will handle the case for the non-interactive mode.~

Acceptance Criteria

• [ ] It should ...

Comments

• An idea discussed in https://github.com/redhat-developer/odo/issues/5863#issuecomment-1285351814: figure out the container with mountSources (the main container), and override ports for it. But this can have some limitations
• Another idea is to use the run command and determine the container component it uses. This is what will is mentioned for handling the non-interactive mode: https://github.com/redhat-developer/odo/issues/6923

Links

• Related Epic (mandatory):
• Feature request: #4448

/kind user-story

[rm3l]

Grooming (2023-06-22)

/priority Low

Low priority - let's keep this as it is for now.

[github-actions[bot]]

A friendly reminder that this issue had no activity for 90 days. Stale issues will be closed after an additional 30 days of inactivity.

[github-actions[bot]]

This issue was closed because it has been inactive for 30 days since being marked as stale.

[rm3l]

/reopen /remove-lifecycle rotten /remove-lifecycle stale /lifecycle frozen

Still relevant.

[openshift-ci[bot]]

@rm3l: Reopened this issue.

In response to this:

/reopen /remove-lifecycle rotten /remove-lifecycle stale /lifecycle frozen

Still relevant.

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.