[ui] Set AutoBuild and DeployByDefault

[feloy]

What type of PR is this:

/kind feature

What does this PR do / why we need it:

Which issue(s) this PR fixes:

Fixes #7021

PR acceptance criteria:

• Unit test

• Integration test

• Documentation

How to test changes / Special notes to the reviewer:

[netlify]

✅ Deploy Preview for odo-docusaurus-preview canceled.

Name	Link
🔨 Latest commit	b05c7c4
🔍 Latest deploy log	https://app.netlify.com/sites/odo-docusaurus-preview/deploys/64f08c3eefcf3200080db8cf

[odo-robot]

OpenShift Unauthenticated Tests on commit 6623b2e finished successfully.
View logs: TXT HTML

[odo-robot]

NoCluster Tests on commit 6623b2e finished successfully.
View logs: TXT HTML

[odo-robot]

Unit Tests on commit 6623b2e finished successfully.
View logs: TXT HTML

[odo-robot]

Validate Tests on commit 6623b2e finished successfully.
View logs: TXT HTML

[odo-robot]

Kubernetes Tests on commit 6623b2e finished successfully.
View logs: TXT HTML

[odo-robot]

Windows Tests (OCP) on commit 6623b2e finished successfully.
View logs: TXT HTML

[odo-robot]

OpenShift Tests on commit 6623b2e finished successfully.
View logs: TXT HTML

[odo-robot]

Kubernetes Docs Tests on commit 7ff38b7 finished successfully.
View logs: TXT HTML

[rm3l]

LGTM overall, but I was wondering about the case of components loaded from the Devfile, without autoBuild/deployByDefault set and not referenced.
Currently, odo automatically applies them at startup (per devfile/api#852 (comment)), but the UI shows them as not built/deployed at startup, which might sound confusing, I guess.

So shouldn't we at least show them in the UI as built/deployed at startup?

[rm3l]

LGTM overall, but I was wondering about the case of components loaded from the Devfile, without autoBuild/deployByDefault set and not referenced. Currently, odo automatically applies them at startup (per devfile/api#852 (comment)), but the UI shows them as not built/deployed at startup, which might sound confusing, I guess.

So shouldn't we at least show them in the UI as built/deployed at startup?

Looks good on the UI with the latest changes, but I just noticed one slight side effect.

The YAML view currently loads the Devfile with all boolean fields set to their default values if they were not set in the source Devfile, which causes an issue here.
For example, if the Devfile contains an orphan Image component without autoBuild set (so built on startup), the YAML view will have the field set to false. And when persisting it back to the filesystem, this Image component will no longer be applied automatically (because autoBuild is false).

In the source Devfile:

- image:
   imageName: my-image
   dockerfile:
     uri: Containerfile
  name: my-image-cmp

In the UI:

I think we should tell the Devfile parser not to automatically set default boolean values when they are unset. See devfile/library#169
And I guess this would also fix some other boolean fields like dedicatedPod, secure, ... that get automatically added when saving the Devfile from the UI to the disk.

[feloy]

LGTM overall, but I was wondering about the case of components loaded from the Devfile, without autoBuild/deployByDefault set and not referenced. Currently, odo automatically applies them at startup (per devfile/api#852 (comment)), but the UI shows them as not built/deployed at startup, which might sound confusing, I guess.
So shouldn't we at least show them in the UI as built/deployed at startup?

Looks good on the UI with the latest changes, but I just noticed one slight side effect.

The YAML view currently loads the Devfile with all boolean fields set to their default values if they were not set in the source Devfile, which causes an issue here. For example, if the Devfile contains an orphan Image component without autoBuild set (so built on startup), the YAML view will have the field set to false. And when persisting it back to the filesystem, this Image component will no longer be applied automatically (because autoBuild is false).

The definition of this autoBuild field is not clear to me. Is it a three-state value?

• true: always build at startup
• false: never build at startup (even if orphan)
• undefined: build if orphan only

Or two-states?

• true: always build at startup
• false: build if orphan only
• undefined: defaults to false (build if orphan only)

@rm3l @kadel @elsony wdyt?

[rm3l]

LGTM overall, but I was wondering about the case of components loaded from the Devfile, without autoBuild/deployByDefault set and not referenced. Currently, odo automatically applies them at startup (per devfile/api#852 (comment)), but the UI shows them as not built/deployed at startup, which might sound confusing, I guess.
So shouldn't we at least show them in the UI as built/deployed at startup?

Looks good on the UI with the latest changes, but I just noticed one slight side effect.
The YAML view currently loads the Devfile with all boolean fields set to their default values if they were not set in the source Devfile, which causes an issue here. For example, if the Devfile contains an orphan Image component without autoBuild set (so built on startup), the YAML view will have the field set to false. And when persisting it back to the filesystem, this Image component will no longer be applied automatically (because autoBuild is false).

The definition of this autoBuild field is not clear to me. Is it a three-state value?

• true: always build at startup
• false: never build at startup (even if orphan)
• undefined: build if orphan only

Yes, to me, it is a 3-state value and is currently implemented as above (per devfile/api#852 (comment)). So if it is explicitly set to false, it will never be applied at startup even if orphan.

[feloy]

LGTM overall, but I was wondering about the case of components loaded from the Devfile, without autoBuild/deployByDefault set and not referenced. Currently, odo automatically applies them at startup (per devfile/api#852 (comment)), but the UI shows them as not built/deployed at startup, which might sound confusing, I guess.
So shouldn't we at least show them in the UI as built/deployed at startup?

Looks good on the UI with the latest changes, but I just noticed one slight side effect.
The YAML view currently loads the Devfile with all boolean fields set to their default values if they were not set in the source Devfile, which causes an issue here. For example, if the Devfile contains an orphan Image component without autoBuild set (so built on startup), the YAML view will have the field set to false. And when persisting it back to the filesystem, this Image component will no longer be applied automatically (because autoBuild is false).

The definition of this autoBuild field is not clear to me. Is it a three-state value?

• true: always build at startup
• false: never build at startup (even if orphan)
• undefined: build if orphan only

Yes, to me, it is a 3-state value and is currently implemented as above (per devfile/api#852 (comment)). So if it is explicitly set to false, it will never be applied at startup even if orphan.

OK, so I will introduce a 3-states button for the user to be able to select one of them

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[rm3l]

Works great with the latest changes - thanks!

[rm3l]

/retest