Add ability for project clone to 'bootstrap' devworkspaces

[amisevsk]

What does this PR do?

Adds DevWorkspace attribute controller.devfile.io/bootstrap-devworkspace. If set to true, this attribute will configure project clone to do the following:

1. Clone all projects in the DevWorkspace as normal
2. Search cloned projects for a devfile.yaml or .devfile.yaml
3. Merge contents of this devfile into the DevWorkspace
   • Projects are merged (i.e. both devfile and DevWorkspace projects are used)
   • Attributes from the DevWorkspace override attributes from the devfile
   • Components, commands, events, etc. from the Devfile are used.
4. Apply the updated DevWorkspace to the cluster, automatically restarting the workspace.

What issues does this PR fix or reference?

Closes #1192

Is it tested? How?

Basic testing of this PR is to create a DevWorkspace that uses the attribute and imports a project with a devfile.yaml at its root:

kind: DevWorkspace
apiVersion: workspace.devfile.io/v1alpha2
metadata:
  name: plain
spec:
  started: true
  routingClass: 'basic'
  template:
    attributes:
      controller.devfile.io/bootstrap-devworkspace: true
    projects:
      - name: che-dashboard
        git:
          remotes:
            origin: "https://github.com/eclipse-che/che-dashboard.git"
    components:
      - name: web-terminal
        container:
          image: quay.io/wto/web-terminal-tooling:next
          memoryRequest: 256Mi
          memoryLimit: 512Mi
          mountSources: true
          command:
           - "tail"
           - "-f"
           - "/dev/null"

After starting, the workspace should update so that the .spec.template of the workspace matches the devfile of the imported project, with the merge process above (attributes, projects are merged instead of overwritten)

PR Checklist

• [ ] E2E tests pass (when PR is ready, comment /test v8-devworkspace-operator-e2e, v8-che-happy-path to trigger)
  • [ ] v8-devworkspace-operator-e2e: DevWorkspace e2e test
  • [ ] v8-che-happy-path: Happy path for verification integration with Che

[AObuchow]

@amisevsk looks awesome to me so far 🥳 Will aim to do a full review on Monday.

[codecov[bot]]

Codecov Report

Attention: 16 lines in your changes are missing coverage. Please review.

Comparison is base (c654384) 52.96% compared to head (7966462) 52.81%.

Additional details and impacted files

```diff @@ Coverage Diff @@ ## main #1193 +/- ## ========================================== - Coverage 52.96% 52.81% -0.15% ========================================== Files 84 84 Lines 7583 7592 +9 ========================================== - Hits 4016 4010 -6 - Misses 3278 3292 +14 - Partials 289 290 +1 ``` | [Files](https://app.codecov.io/gh/devfile/devworkspace-operator/pull/1193?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=devfile) | Coverage Δ | | |---|---|---| | [controllers/workspace/devworkspace\_controller.go](https://app.codecov.io/gh/devfile/devworkspace-operator/pull/1193?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=devfile#diff-Y29udHJvbGxlcnMvd29ya3NwYWNlL2RldndvcmtzcGFjZV9jb250cm9sbGVyLmdv) | `62.42% <100.00%> (-1.24%)` | :arrow_down: | | [pkg/library/env/workspaceenv.go](https://app.codecov.io/gh/devfile/devworkspace-operator/pull/1193?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=devfile#diff-cGtnL2xpYnJhcnkvZW52L3dvcmtzcGFjZWVudi5nbw==) | `28.68% <0.00%> (-2.29%)` | :arrow_down: |

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[amisevsk]

@svor @RomanNikitenko If you have some time, please also take a look at this PR and leave review comments (I can't explicitly request review from you). This is somewhat related to the devworkspace generator and the "Restart from local Devfile" functionality in Code (e.g. this PR).

This PR partly reimplements the logic/goal of the generator's generateDevfileContext, with some different assumptions (basically, we assume someone else can handle the editor, etc.). My reasoning here is that "Update DevWorkspace using an in-repo devfile" amounts to:

• Copy devfile's contents to DevWorkspace .spec.template
• Copy attributes from original DevWorkspace, so as to not lose any attributes already on the DevWorkspace
• Merge projects by taking existing projects + any projects in the devfile

If you would like me to contribute something similar to the generator, let me know :)

[RomanNikitenko]

@amisevsk as far as I understand - we need similar changes at least for the generator - correct? and probably some changes on the che-code side - to handle the use case with merging projects

[amisevsk]

as far as I understand - we need similar changes at least for the generator - correct?

I don't think the generator or che-code needs to be updated, and there's not really an issue on that side of things:

• The generator library's purpose is similar but different to this change -- it has to add various attributes and the default editor, etc. while also outputting DevWorkspaceTemplates for the editor contribution. The majority of the work done by the generator library is not applicable in this case (e.g. DWO can't worry about default editors, or the plugin registry URL)
• The usage of the generator library in che-code also doesn't really need updating, since it basically does the same thing as this change (except for projects, which is worth discussing at some point).

On the other hand, the DevWorkspace/devfile/Che APIs have reached a level of complexity that it's probably worth our time to discuss and make sure our interpretations of how things should fit together are in line -- I don't want to do something in DWO that is unexpected from the perspective of the devworkspace-generator library.

As for projects, the implementation here is basically just a temporary workaround until dependentProjects are added to the devfile API. After dependentProjects is introduced, handling this is a fair bit simpler :)

[openshift-ci[bot]]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: amisevsk, AObuchow, svor

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: - ~~[OWNERS](https://github.com/devfile/devworkspace-operator/blob/main/OWNERS)~~ [amisevsk] Approvers can indicate their approval by writing `/approve` in a comment Approvers can cancel approval by writing `/approve cancel` in a comment

[amisevsk]

I'm curious where this flow could be useful/applicable in case of Che/DS? Maybe in tests that don't use UI and were we need to have a final DevWorkspace, but we still need to create and store short version of DevWorkspace with bootstrap-devworkspace attribute.

I don't have anything specific in mind, it was just brought up that this change may be of interest to the generator (and prompted me to look into the generator as well to see how it works). I agree that the generator is doing something different (and needs to generate e.g. devworkspacetemplates, etc.).

One area we could potentially improve is https://github.com/eclipse/che/issues/22614 -- currently the generator will set environment variables on all containers when converting the devfile, and I'm not sure that's still necessary with the move to container contributions (which merge environment variables from the contribution). As far as I know, those Che-specific environment variables are needed only by the editor, so we could probably get away with not setting them in any devfile containers. This would also make bootstrapping "safer" since the result of bootstrapping would be more similar to the result of the generator.