Chapter 1. Get started with OpenShift Dev Spaces
Start a new workspace from a Git repository, manage running workspaces, and authenticate to a Git server.
OpenShift Dev Spaces creates cloud development environments from any Git repository. Open a repository URL in OpenShift Dev Spaces to launch a workspace with the project code, tools, and dependencies defined in a devfile.
1.1. Start a workspace from a Git repository URL Copy linkLink copied to clipboard!
Start a new OpenShift Dev Spaces workspace with cloned source code by using a Git repository URL, so that you can begin developing immediately without manual repository setup.
Prerequisites
- You have a running instance of OpenShift Dev Spaces.
-
You know the Fully Qualified Domain Name (FQDN) URL of your organization’s OpenShift Dev Spaces instance:
https://<openshift_dev_spaces_fqdn>. - Optional: You have authentication to the Git server configured.
-
Optional: You have a
devfile.yamlor.devfile.yamlfile in the root directory of the Git repository. Without a devfile, the workspace starts with Universal Developer Image and Microsoft Visual Studio Code - Open Source as the workspace IDE. For alternative devfile names and paths, see Chapter 2, Optional parameters for the URLs for starting a new workspace. - For private repositories: you have configured a personal access token or accepted the SCM authentication page to access the repository content. See Section 7.6, “Use a Git provider access token”.
- For Git+SSH URLs: you have propagated the SSH key. See Configuring DevWorkspaces to use SSH keys for Git operations.
Procedure
- Optional: Visit your OpenShift Dev Spaces dashboard pages to authenticate to your organization’s instance of OpenShift Dev Spaces.
Enter the URL in your browser or in the Git Repository URL field on the Create Workspace page to start a new workspace:
https://<openshift_dev_spaces_fqdn>#<git_repository_url>To append optional parameters, add
?<optional_parameters>to the URL. See Chapter 2, Optional parameters for the URLs for starting a new workspace for supported parameters.For example:
-
https://<openshift_dev_spaces_fqdn>#https://github.com/che-samples/cpp-hello-world https://<openshift_dev_spaces_fqdn>#git@github.com:che-samples/cpp-hello-world.gitURL syntax per Git provider:
Expand Table 1.1. GitHub URL pattern Default branch:
https://<openshift_dev_spaces_fqdn>#https://<github_host>/<user_or_org>/<repository>Specified branch:
https://<openshift_dev_spaces_fqdn>#https://<github_host>/<user_or_org>/<repository>/tree/<branch_name>Pull request branch:
https://<openshift_dev_spaces_fqdn>#https://<github_host>/<user_or_org>/<repository>/pull/<pull_request_id>Git+SSH:
https://<openshift_dev_spaces_fqdn>#git@<github_host>:<user_or_org>/<repository>.gitFor GitHub, you can also use a URL of a directory containing a devfile, or a direct URL to the devfile. The devfile name must be
devfile.yamlor.devfile.yaml. Other Git providers do not support this feature.Expand Table 1.2. GitLab URL pattern Default branch:
https://<openshift_dev_spaces_fqdn>#https://<gitlab_host>/<user_or_org>/<repository>Specified branch:
https://<openshift_dev_spaces_fqdn>#https://<gitlab_host>/<user_or_org>/<repository>/-/tree/<branch_name>Git+SSH:
https://<openshift_dev_spaces_fqdn>#git@<gitlab_host>:<user_or_org>/<repository>.gitExpand Table 1.3. Bitbucket Server URL pattern Default branch:
https://<openshift_dev_spaces_fqdn>#https://<bb_host>/scm/<project-key>/<repository>.gitDefault branch (user profile repository):
https://<openshift_dev_spaces_fqdn>#https://<bb_host>/users/<user_slug>/repos/<repository>/Specified branch:
https://<openshift_dev_spaces_fqdn>#https://<bb_host>/users/<user-slug>/repos/<repository>/browse?at=refs%2Fheads%2F<branch-name>Git+SSH:
https://<openshift_dev_spaces_fqdn>#git@<bb_host>:<user_slug>/<repository>.gitExpand Table 1.4. Microsoft Azure DevOps URL pattern Default branch:
https://<openshift_dev_spaces_fqdn>#https://<organization>@dev.azure.com/<organization>/<project>/_git/<repository>Specified branch:
https://<openshift_dev_spaces_fqdn>#https://<organization>@dev.azure.com/<organization>/<project>/_git/<repository>?version=GB<branch>Git+SSH:
https://<openshift_dev_spaces_fqdn>#git@ssh.dev.azure.com:v3/<organization>/<project>/<repository>
-
Verification
- After you enter the URL to start a new workspace in a browser tab, the workspace starting page appears.
- When the new workspace is ready, the workspace IDE loads in the browser tab.
- A clone of the Git repository is present in the filesystem of the new workspace.
-
The workspace has a unique URL:
https://<openshift_dev_spaces_fqdn>/<user_name>/<unique_url>.
1.2. Start a workspace from a raw devfile URL Copy linkLink copied to clipboard!
Start a new OpenShift Dev Spaces workspace from a devfile URL. Open the URL in your browser or enter it in the Git Repo URL field on the Create Workspace page.
Prerequisites
- You have a running instance of OpenShift Dev Spaces.
-
You know the Fully Qualified Domain Name (FQDN) URL of your organization’s OpenShift Dev Spaces instance:
https://<openshift_dev_spaces_fqdn>. - The devfile contains project info to clone the Git repository into the workspace filesystem. See https://devfile.io/docs/2.2.0/adding-projects.
Procedure
- Optional: Visit your OpenShift Dev Spaces dashboard pages to authenticate to your organization’s instance of OpenShift Dev Spaces.
Enter the devfile URL in your browser to start a new workspace.
For a public repository:
https://<openshift_dev_spaces_fqdn>#<devfile_url>For a private repository, include your personal access token in the URL:
https://<openshift_dev_spaces_fqdn>#https://<token>@<host>/<path_to_devfile>where:
<token>Your personal access token that you generated on the Git provider’s website. This method works for GitHub, GitLab, Bitbucket, Microsoft Azure, and other providers that support Personal Access Token.
ImportantAutomated Git credential injection does not work with token-embedded URLs. To configure Git credentials separately, see Section 7.6, “Use a Git provider access token”.
To append optional parameters, add
?<optional_parameters>to the URL. See Chapter 2, Optional parameters for the URLs for starting a new workspace for supported parameters.For example:
-
Public repository:
https://<openshift_dev_spaces_fqdn>#https://raw.githubusercontent.com/che-samples/cpp-hello-world/main/devfile.yaml -
Private repository:
https://<openshift_dev_spaces_fqdn>#https://<token>@raw.githubusercontent.com/che-samples/cpp-hello-world/main/devfile.yaml
-
Public repository:
Verification
After you enter the URL to start a new workspace in a browser tab, the workspace starting page appears. When the new workspace is ready, the workspace IDE loads in the browser tab.
+ The workspace has a unique URL: https://<openshift_dev_spaces_fqdn>/<user_name>/<unique_url>.
1.3. Basic actions you can perform on a workspace Copy linkLink copied to clipboard!
You manage your workspaces and verify their current states in the Workspaces page (https://<openshift_dev_spaces_fqdn>/dashboard/#/workspaces) of your OpenShift Dev Spaces dashboard.
After you start a new workspace, you can perform the following actions on it in the Workspaces page:
| Action | GUI steps in the Workspaces page |
|---|---|
| Reopen a running workspace | Click Open. |
| Restart a running workspace | Go to ⋮ > Restart Workspace. |
| Stop a running workspace | Go to ⋮ > Stop Workspace. |
| Start a stopped workspace | Click Open. |
| Delete a workspace | Go to ⋮ > Delete Workspace. |
1.4. Git server authentication from a workspace Copy linkLink copied to clipboard!
OpenShift Dev Spaces workspaces support authenticated Git operations such as cloning private repositories and pushing to remote repositories. Administrators and users configure authentication to ensure seamless access to Git servers from workspaces.
User authentication to a Git server from a workspace is configured by the administrator or, in some cases, by the individual user:
- Your administrator configures an OAuth application on GitHub, GitLab, Bitbucket, or Microsoft Azure Repos for your Red Hat OpenShift Dev Spaces instance.
- As a workaround, some users create their own Kubernetes Secrets for personal Git-provider access tokens or configure SSH keys.