[devfile-registry] Links (index.json, devfile.yaml) are not correct in Single Host mode
See original GitHub issueDescribe the bug
index.json and devfile.yaml of devfile registry has absolute links which are wrong in Che Single-Host mode. To make it working, Dashboard needs to workaround this issue in resolving link against Devfile Registry URL https://github.com/eclipse/che-dashboard/pull/176
Since Che has single host mode, each component should be adapted to share the host with others and in such case we cannot use ‘From the Root’ links, we should use ‘Fully Qualified’ or ‘Relative’ paths for all resources.
Che version
- latest
- nightly
- other: please specify
Steps to reproduce
- Deploy Single Host Che with the following CheCluster patch
# save the content to /tmp/che-custom-che-server.yaml and execute the following:
# chectl server:deploy --installer=operator --platform=minikube --che-operator-cr-patch-yaml=/tmp/che-custom-che-server.yaml
spec:
k8s:
singleHostExposureType: 'gateway'
server:
serverExposureStrategy: single-host
- Open Devfile registry URL and make sure it’s a absolute path which won’t work when you use it, in the way it’s supposed to be used (append path to the current host).
Expected behavior
index.json and devfile.yaml have correct links.
Runtime
- kubernetes (include output of
kubectl version
) - Openshift (include output of
oc version
) - minikube (include output of
minikube version
andkubectl version
) - minishift (include output of
minishift version
andoc version
) - docker-desktop + K8S (include output of
docker version
andkubectl version
) - other: (please specify)
Screenshots
Installation method
- chectl
- provide a full command that was used to deploy Eclipse Che (including the output)
- provide an output of
chectl version
command
- OperatorHub
- I don’t know
Environment
- my computer
- Windows
- Linux
- macOS
- Cloud
- Amazon
- Azure
- GCE
- other (please specify)
- other: please specify
Issue Analytics
- State:
- Created 3 years ago
- Comments:6 (6 by maintainers)
Top Results From Across the Web
`CHE_DEVFILE_REGISTRY_URL` is not properly ... - GitHub
Describe the bug. CHE_DEVFILE_REGISTRY_URL is only defined on the helm chart, but not on OpenShift template.
Read more >Chapter 3. Customizing the devfile and plug-in registries
To verify that the new plug-in is correctly published to the plug-in registry, make a request to the registry path /v3/plugins/index.json (or /devfiles/index....
Read more >Building a custom devfile registry
To create a devfile registry for your team's container development: ... Verify every devfile stack contains at least one devfile.yaml file.
Read more >Introduction to Devfile - GitHub Pages
Please note that currently this way only works for the local (same machine) devfiles - URL can't be used here atm. Project details....
Read more >Devfile v2 and IDE plug-ins - Eclipse Che Blog
ℹ️ When DevWorkspace is enabled, single-host deployment is enforced. As a consequence, when the Che host certificate is untrusted, there is no ......
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
@benoitf it’s not related to OpenShift templates and platform does not matter, it depends on Single Host. You can try to deploy with the following CheCluster Patch:
Che Devfile Registry will be available at
$host/devfile-registry/devfiles
Links in index.json and meta.yaml are root-relative URL likeicon: /images/dotnetcore.svg
orself: /devfiles/dotnet/devfile.yaml
Which since they are root-relative URL should be resolved by browser as$host/images/dotnetcore.svg
which is not correct, while the right is$host/devfile-registry/images/dotnetcore.svg
.Does it make sense?
yes, will do.