Add attribute controller.devfile.io/bootstrap-devworkspace: true when Devfile resolution via API fails or is not supported

[l0rd]

Is your enhancement related to a problem? Please describe

This is a subtask of #22491

Describe the solution you'd like

After this recent PR, when the attribute controller.devfile.io/bootstrap-devworkspace: true is set on a DevWorkspace object, then the project clone is configured to search for a devfile and apply it after cloning the DW projects.

To close the issue to automatically restart a workspace and the epic to support resolving devfiles for any git service we need now to automatically add this attribute when the che-server fails to resolve a Devfile (because of an unsupported git service or because an error occurred).

[ibuziuk]

@l0rd am I correct that this issue boils down to setting attribute when we start workspace with default devfile

[l0rd]

In theory, when che-server is able to connect to the git service API and figures out that there is no devfile at the root of the repository, project-clone container should avoid inspecting again for the same devfile. In practice I don't think that's a big deal if both (che-server and project-clone) look for the devfile.

Another more important case is when the user explicitly click on "start using the default devfile". In this case we don't want to set controller.devfile.io/bootstrap-devworkspace: true.

[ibuziuk]

@l0rd in this cases, there is a question if we need an extra UI item, clicking on which the label would be added. If we want to implement it without UI changes, it is not clear when restart with default devfile should be shown in general

[l0rd]

@ibuziuk, UI item? No, there should be no need.

What I mean is that if the startup of a workspace fails because of an invalid devfile, we currently prompt the user to restart with default devfile. But if the default devfile has controller.devfile.io/bootstrap-devworkspace: true then, the project-clone container will find the invalid devfile in the git repository and replace the default devfile with it...

[ibuziuk]

@l0rd thanks, my understanding is that we should rework when restart with default devfile is shown e.g.

• if workspace failed to start due to the invalid image, restart with default devfile is shown and no attribute is injected (current flow)
• if workspace can not be started because the URL can not be resolved (ssh, gerit, gitea), we do not fail, but instead automatically use default devfile with the controller.devfile.io/bootstrap-devworkspace: true annotation

[l0rd]

if workspace can not be started because the URL can not be resolved (ssh, gerit, gitea), we do not fail, but instead automatically use default devfile with the controller.devfile.io/bootstrap-devworkspace: true annotation

We currently should not fail when a git+SSH URL is provided. We can extend that to https URL as well yes but that's not in the scope of this issue or in the scope of the epic.

[l0rd]

@akurinnoy @svor @olexii4 that's fantastic that you have been able to close this one but when I tried to test it on our dogfooding instance, it didn't work for me.

I have tested using the repository [email protected]:~l0rd/public-project-sample and...

The devfile is not resolved

This is expected as sourcehut is an unknown git service for che server:

There is no controller.devfile.io/bootstrap-devworkspace: true attribute

This is not expected:

kubectl get devworkspaces public-project-sample -o json | jq '.spec.template.attributes | keys'
[
  "che-theia.eclipse.org/sidecar-policy",
  "controller.devfile.io/devworkspace-config",
  "controller.devfile.io/scc",
  "controller.devfile.io/storage-type",
  "dw.metadata.annotations"
]

And this is project-clone init-container log:

2023/12/21 14:37:25 Using temporary directory /projects/project-clone-2749812435
2023/12/21 14:37:25 Read DevWorkspace at /devworkspace-metadata/flattened.devworkspace.yaml
2023/12/21 14:37:25 Processing project public-project-sample
2023/12/21 14:37:25 Cloning project public-project-sample to /projects/project-clone-2749812435/public-project-sample
Cloning into '/projects/project-clone-2749812435/public-project-sample'...
Warning: Permanently added 'git.sr.ht,173.195.146.142' (ECDSA) to the list of known hosts.
2023/12/21 14:37:25 Cloned project public-project-sample to /projects/project-clone-2749812435/public-project-sample
2023/12/21 14:37:25 Setting up remotes for project public-project-sample
2023/12/21 14:37:25 Fetched remote origin at [email protected]:~l0rd/public-project-sample
2023/12/21 14:37:25 Moving cloned project public-project-sample from temporary directory /projects/project-clone-2749812435/public-project-sample to /projects/public-project-sample

[svor]

@l0rd we'll double check the flow. I'll reopen the issue for now

[l0rd]

This is what I get now, if I try to start the workspace from [email protected]:~l0rd/public-project-sample:

There is a Devfile in the git repository, and the DevWorkspace will be able to read it and use it. This prompt to the user is an error.

[l0rd]

@ibuziuk from my point of view this issue cannot be resolved yet.

UPDATE This can be related to current outage of sourcehut 🤦 I will try again as soon as the outage get fixed.

[l0rd]

Besides the sourcehut outage, I am still I am wondering: why are we trying to resolve the devfile if the protocol is git+SSH and the git service is not supported by che-server?

[l0rd]

I have tested again this morning and it worked as expected 👍

The dashboard still says that "Devfile could not be found in... Applying the default configuration" which is misleading but that can be handled as a separate issue.