Chapter 7. Known issues 7.1. Issues with starting a new workspace from a URL that points to a branch of a repository that doesn't have a devfile There is a known issue affecting repositories without a devfile.yaml file. If you start a new workspace from a branch of such repository, the default branch (e.g. 'main') is used for project cloning instead of the expected branch. Additional resources CRW-6860 7.2. Refresh token mode causes cyclic reload of the workspace start page There is a known issue when experimental refresh token mode is applied using the CHE_FORCE_REFRESH_PERSONAL_ACCESS_TOKEN property for the 'GitHub' and 'Azure DevOps' OAuth providers. This causes the workspace starts to reload the dashboard cyclically, creating a new personal access token on each page restart. The refresh token mode works correctly for 'GitLab' and 'BitBucket' OAuth providers. Additional resources CRW-6859 7.3. Workspace creation failure for GitHub Enterprise public repositories with no PAT or OAuth configuration There is a known issue with creating a workspace from GitHub Enterprise public repositories that have no personal access token (PAT) or OAuth configured. If you try to create a workspace from such a repository, you receive the following error message: "Failed to create the workspace. Cannot build factory with any of the provided parameters. Please check parameters correctness, and resend query." Workaround Add a PAT of the Git provider, or configure the OAuth. Additional resources CRW-6831 7.4. Ansible Lightspeed not connecting to Ansible server There is a known issue with Ansible Lightspeed and connection to the Ansible server. If the OpenShift Dev Spaces environment is not under *.openshiftapps.com domain, Ansible Lightspeed can not connect to the Ansible server. There is no workaround available. Additional resources CRW-5691 7.5. FIPS compliance update There's a known issue with FIPS compliance that results in certain cryptographic modules not being FIPS-validated. Below is a list of requirements and limitations for using FIPS with OpenShift Dev Spaces: Required cluster and operator updates Update your Red Hat OpenShift Container Platform installation to the latest z-stream update for 4.11, 4.12, or 4.13 as appropriate. If you do not already have FIPS enabled, you will need to uninstall and reinstall. Once the cluster is up and running, install OpenShift Dev Spaces 3.7.1 (3.7-264) and verify that the latest DevWorkspace operator bundle 0.21.2 (0.21-7) or newer is also installed and updated. See https://catalog.redhat.com/software/containers/devworkspace/devworkspace-operator-bundle/60ec9f48744684587e2186a3 Golang compiler in UDI image The Universal Developer Image (UDI) container includes a golang compiler, which was built without the CGO_ENABLED=1 flag. The check-payload scanner ( https://github.com/openshift/check-payload ) will throw an error, but this can be safely ignored provided that anything you build with this compiler sets the correct flag CGO_ENABLED=1 and does NOT use extldflags -static or -tags no_openssl . The resulting binaries can be scanned and should pass without error. Statically linked binaries You can find statically linked binaries not related to cryptography in these two containers: code-rhel8 idea-rhel8. As they are not related to cryptography, they do not affect FIPS compliance. Helm support for FIPS The UDI container includes the helm binary, which was not compiled with FIPS support. If you are in a FIPS environment do not use helm . Additional resources CRW-4598 7.6. Debugger does not work in the .NET sample Currently, the debugger in Microsoft Visual Studio Code - Open Source does not work in the .NET sample. Workaround Use a different image from the following sources: Custom UBI-9 based Dockerfile devfile.yaml Additional resources CRW-3563

Commands: