You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the renku CLI for session start, we need to know where gitlab and especially the gitlab image registry is located, so we can poll the notebook service on if an image is built.
Currently, the CLi logs in like renku login <renku deployment url>, e.g. renku login renkulab.io and it then just guesses that the registry is at registry.<renku deployment url> and gitlab at gitlab.<renku deployment url>. In the case of our CI deployments or any other case where an external gitlab is used, this would not work, causing CLI commands that need this information to fail.
Since we can't access the helm values from a local CLI, we need to expose those URLs somewhere in the renku deployment so the CLI can get them. The gateway is the candidate that makes the most sense for this, as it's already the central entrypoint into the application, so we should expose this under some endpoint on the gateway.
The text was updated successfully, but these errors were encountered:
In the renku CLI for session start, we need to know where gitlab and especially the gitlab image registry is located, so we can poll the notebook service on if an image is built.
Currently, the CLi logs in like
renku login <renku deployment url>
, e.g.renku login renkulab.io
and it then just guesses that the registry is atregistry.<renku deployment url>
and gitlab atgitlab.<renku deployment url>
. In the case of our CI deployments or any other case where an external gitlab is used, this would not work, causing CLI commands that need this information to fail.Since we can't access the helm values from a local CLI, we need to expose those URLs somewhere in the renku deployment so the CLI can get them. The gateway is the candidate that makes the most sense for this, as it's already the central entrypoint into the application, so we should expose this under some endpoint on the gateway.
The text was updated successfully, but these errors were encountered: