发行注记和已知问题

OpenShift Dev Spaces 在以下 CPU 架构上的 OpenShift 4.11-4.14 上运行：

对于 Red Hat OpenShift Dev Spaces 3.11，红帽将为部署、配置和使用产品提供支持。

Red Hat OpenShift Dev Spaces 和基于 Eclipse Che 的上游项目之间存在一些区别：

红帽提供了许可证和打包，以确保 OpenShift Dev Spaces 的企业级支持。

在这个版本中，自定义资源中提供了高级授权的以下属性。

allowUsers, allowGroups, denyUsers, denyGroups

此配置允许集群管理员明确管理 Red Hat OpenShift Dev Spaces 的加入并策展访问权限。

在这个版本中，支持使用回调和 URI 处理程序的 OAuth2 授权代码流。现在，您可以使用 Microsoft Visual Studio Code - 使用此流的开源扩展，例如使用 AI-powered Lightspeed 服务的 Ansible 扩展。

在这个版本中，您可以使用 User Preferences 仪表板页面中的 Git Services 选项卡拒绝授权 opt-out 标志。

在这个版本中，您可以在用户仪表板中为 GitHub Enterprise Server 配置个人访问令牌。

在这个版本中，以下页面功能可用于在启动时失败的工作区：

在这个版本中，支持带有 github.com 上的 ?token 参数的专用原始 URL。

在这个版本中，在 UDI 中默认使用 Java 17。

在这个版本中，您可以使用所有 Git 供应商配置 SSH 密钥并打开工作区。这包括 GitHub、Gitlab、Bitbucket 和 Microsoft Azure，以及之前不支持的 Git 供应商：

在这个版本中，您可以通过复制和粘贴在用户仪表板中添加 SSH 密钥。

在这个版本中，支持 schemaVersion 2.2.1 和 2.2.2 的 devfile。

在此次更新之前，HOSTNAME 环境变量可以被覆盖。这会导致 Microsoft Visual Studio Code - Open Source extension che-resource-monitor 无法正常工作。在这个版本中，HOSTNAME 环境变量在 IDE 启动前复制到 DEVWORKSPACE_POD_NAME 环境变量，以创建相关数据的备份源。

在此次更新之前，如果没有配置 OAuth 或个人访问令牌(PAT)，则公共 GitHub Enterprise Server 仓库中的工作区无法启动。在这个版本中，这个问题已被解决。

在此次更新之前，从断开连接的集群中的工作区访问 OpenShift API 会失败，并显示以下错误消息："HttpError: HTTP request failed"。在这个版本中，这个问题已被解决。

在此次更新之前，命令面板中没有 GitHub 设备身份验证。这会导致以下 GitHub Copilot 错误："Copilot 无法连接到服务器。扩展激活失败："Request failed with status code 401"。在这个版本中，这个问题已被解决。

在此次更新之前，Microsoft Visual Studio Code - Open Source launcher 仅在初始工作区启动过程中将项目从 devfile.yaml 添加到 .vscode-workspace 配置文件。如果您在 devfile 中添加新项目（或依赖项目），并使用 "Restart Workspace from Local Devfile" 选项重启工作区，则新项目不会添加到配置文件中。这会导致您看到项目，即使所有项目都克隆在 /projects 文件夹中。在这个版本中，项目会在 .vscode-workspace 配置文件中正确更新。

在此次更新之前，Git Services 选项卡中不会显示 BitBucket OAuth 1.0。在这个版本中，这个问题已被解决。

在此次更新之前，自定义资源中定义的 defaultPlugins 在工作区启动过程中不会应用。在这个版本中，这个问题已被解决。您还可以使用 devfile.yaml 参考添加额外的 sidecar 插件：

     devEnvironments:
       - editor: che-incubator/che-code/insiders
         plugins:
            - >-
              https://example.com/devfile.yaml

Ansible Lightspeed 和连接到 Ansible 服务器时存在一个已知问题。如果 OpenShift Dev Spaces 环境没有处于 Ifopenshiftapps.com 域下，Ansible Lightspeed 无法连接到 Ansible 服务器。

没有可用的临时解决方案。

存在一个影响 Ansible Lightspeed 和嵌入式插件 registry 的已知问题。使用嵌入式插件 registry 登录 Ansible Lightspeed 后，您不会重定向到 OpenShift Dev Spaces。

存在一个已知问题，影响在/克隆到空工作区中创建的项目。项目的默认文件夹是"/home/user"目录。但是，重启工作区后不会保存对文件夹的更改。

自动安装推荐的 Microsoft Visual Studio Code - 开源扩展存在一个已知问题。使用嵌入式插件 registry 安装扩展后，扩展会在 Extensions 菜单中处于"正在安装"状态。

FIPS 合规性存在一个已知问题，导致某些加密模块没有被 FIPS 验证。以下是在 OpenShift Dev Spaces 中使用 FIPS 的要求和限制列表：

集群启动并运行后，安装 OpenShift Dev Spaces 3.7.1 (3.7-264)，并验证最新的 DevWorkspace operator 捆绑包 0.21.2 (0.21-7)或更新版本也会安装和更新。请参阅 https://catalog.redhat.com/software/containers/devworkspace/devworkspace-operator-bundle/60ec9f48744684587e2186a3

生成的二进制文件可以被扫描，应该会在没有错误的情况下通过。

因为它们与加密无关，它们不会影响 FIPS 合规性。

目前存在一个已知问题：在 Microsoft Visual Studio Code 中不会自动安装推荐的扩展 - 开源。

目前，Microsoft Visual Studio Code 中的 debugger - 开源无法在 .NET 示例中工作。