Throw an error if Devfile from unsupported ssh repository is not resolved

[vinokurig]

What does this PR do?

Throw an error if Devfile from unsupported ssh repository is not resolved instead of returning an empty factory dto without devfile. The ApiException will be handled by dashboard and default devfile will be used: https://github.com/eclipse-che/che-dashboard/blob/05bf4383a45cb367924c788763beb5c7689a7c79/packages/dashboard-frontend/src/components/WorkspaceProgress/CreatingSteps/Fetch/Devfile/index.tsx#L215

Screenshot/screencast of this PR

What issues does this PR fix or reference?

eclipse-che/che#23277

How to test this PR?

1. Deploy che with the pull request image: quay.io/eclipse/che-server:pr-763
2. Start workspcae from an ssh url of an unsupported provider e.g. [email protected]:ivinokur/test.git

See workspace starts from the default devfile.

PR Checklist

As the author of this Pull Request I made sure that:

• The Eclipse Contributor Agreement is valid
• Code produced is complete
• Code builds without errors
• Tests are covering the bugfix
• The repository devfile is up to date and works
• Sections What issues does this PR fix or reference and How to test this PR completed
• Relevant user documentation updated
• Relevant contributing documentation updated
• CI/CD changes implemented, documented and communicated

Release Notes

Reviewers

Reviewers, please comment how you tested the PR when approving it.

[vinokurig]

/retest

[vinokurig]

/retest

[tolusha]

Sounds like significant changes.

[vinokurig]

I do not think so. As I mentioned in the description this function is used to handle unsupported git provider and this url pattern is just potentially can match a RAW devfile url. If we handle a known provider, we have the pattern to fetch the devfile, but here we just trying to guess and with this pattern it is more likely that we will fetch the devfile.

[ibuziuk]

would it be possible to add javadoc? it is not intuitive why location for GitSshUrl returns https?

[vinokurig]

This change is not related to this pull request so I decided to revert it and leave a todo.

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: tolusha, vinokurig

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[dmytro-ndp]

If this PR is fixing an issue eclipse-che/che#23277 , then workspace should start successfully without any errors following test scenario described by @ibuziuk in his comment eclipse-che/che#23277 (comment)

• SSH key is configured
• workspace started via private SSH URL
• workspace is started correctly based on the devfile from the private SSH repo.

N.B. no OAuth / PAT are configured

Otherwise it looks like a regression compare to previous version, IMHO

If PR is fixing specific use case, I would suggest opening separate issue with clear description.

[vinokurig]

@dmytro-ndp
Why do we need a separate issue for the case described in the pull request? From the current issue description:

A typical example is when it's not GitHub, GitLab, Bitbucket or Azure DevOps repository or when SSH URL is used.

The pull request fixes the case when an SSH url from an unsupported provider is used, which is mentioned in the description above.
But if you insist, I can create a separate issue.

[artaleks9]

/retest

[openshift-ci]

@vinokurig: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/v14-gitlab-with-oauth-setup-flow	5715f7e	link	true	/test v14-gitlab-with-oauth-setup-flow

Full PR test history. Your PR dashboard.

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-sigs/prow repository. I understand the commands that are listed here.

[dmytro-ndp]

@vinokurig : thank you for the answer!

If I understood the following description of issue #22025 correctly, an SSH URL from an unsupported provider should work in Eclipse Che:

Through the GIT+SSH protocol Che would be able to fully support any git service. That won't replace the HTTP + OAuth flow that remains the preferred if support (GitHub, BB, GitLab and Azure DevOps), but an alternative that allows Che to work on other services too (gerrit, gogs, githut...).

As far as I remember, I was able to create and open a workspace from a Gogs Git repository using a GIT+SSH link (ssh://[email protected]:10022/test/quarkus-api-example-public.git) in Eclipse Che 7.98.x, and the devfile from the Git repository was successfully applied.

My concern is that, to avoid regression, it makes sense to ensure that Eclipse Che continues to support this functionality after this PR is merged. For example, someone could create a PR for the Dashboard to properly handle 500 server errors from Che Server in case of SSH url from unsupported provider like Gogs, and merge it together with this PR.