发行注记和已知问题

OpenShift Dev Spaces 在以下 CPU 架构的 OpenShift 4.12-4.17 上运行：

以下 CPU 架构需要 Openshift 4.13-4.17 来运行 OpenShift Dev Spaces：

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

Red Hat OpenShift Dev Spaces 和基于它的上游项目之间的一些区别，Eclipse Che:

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

在这个版本中，您可以使用用户首选项中的"SSH Keys"选项卡在添加新的 SSH 密钥时指定密码短语。

这个功能是一个技术预览功能，默认是禁用的。要使用这个功能，必须在 DevWorkspaceOperatorConfig 自定义资源中设置 config.enableExperimentalFeatures: true。

在这个版本中，您可以使用 maxNumberOfRunningWorkspacesPerCluster CheCluster CR 属性限制集群中的 'Running' 工作区总数。

在 官方文档 中了解更多有关此功能的信息。

在这个版本中，您可以使用专用的 allowedSources CheCluster CR 属性指定基于 Cloud Development Environments (CDEs)初始化的 URL 列表：

     "devEnvironments": {
       "allowedSources": {
         "urls": ["url_1", "url_2"]
       }

在 官方文档 中了解更多有关此功能的信息。

在这个版本中，您可以使用专用的 nodeSelector 和 tolerations 属性 CR 属性在特定集群节点上部署由 operator (dashboard、gateway、plugin-registry 等)管理的操作对象：

  dashboard:
      deployment:
        nodeSelector:
        tolerations:

在这个版本中，您可以包括编辑器定义。当管理员希望从 Dashboard UI 中隐藏特定编辑器时（例如，删除 IntelliJ 并仅具有 Visual Studio Code - 开源可见）时，这非常有用。

在 官方文档 中了解更多有关流程的信息。

在这个版本中，您可以在 devfile 中提供 端点注解。例如，以下 devfile 片断将在 Cloud Development Environment (CDE)启动时使用注解 foo: bar 创建入口或路由：

components:
  - container:
      endpoints:
        - name: my-endpoint
          annotation:
            foo: bar
            ...

spec.devEnvironments.runtimeClassName 属性已添加到 CheCluster CR 中。此属性为所有 Cloud Development Environment (CDE) pod 设置 spec.runtimeClassName。CDE 的 controller.devfile.io/runtime-class 属性优先于 CheCluster spec.devEnvironments.runtimeClassName 属性。

在这个版本中，FailedScheduling 事件是 spec.devEnvironments.ignoredUnrecoverableEvents 属性的默认值。当集群配置了自动扩展器时，这很有用。如果云开发环境(CDE) pod 无法调度到导致 FailedScheduling 事件的任何节点上，则在置备新节点时将重试 CDE 启动。

在此发行版本中，在 Cloud Development Environment (CDE)重启后有时会显示之前启动的错误消息，这对用户造成混淆。

这个版本解决了这个缺陷。

在此版本之前，安装最新的 Python 扩展(v2024.14.0)会失败，并显示以下出错信息："Extension 'ms-python.python' CANNOT use API proposal: terminalShellIntegration"。在这个版本中，这个问题已被解决

在此版本之前，从内部托管的 Gitlab 存储库启动带有 devfile 的工作区会导致 "devfile not found" 错误消息。在这个版本中，这个问题已被解决。

在以前的版本中，粘贴 Che Dashboard 中的 User Preferences 页面中的 SSH 密钥会导致在克隆 git 存储库时造成无效的格式错误。这个版本解决了这个问题。

当持久性卷挂载有 /home/user/.local 的挂载路径时，CDE 的通用开发人员镜像(UDI)容器中缺少podman。这个程序错误已在最新的 UDI 版本中解决。

在此版本之前，如果配置了 GitHub OAuth 且 GitHub 停机，则无法从此源启动现有的 CDE。这个版本中解决了这个缺陷，即使 OAuth 供应商在启动时显示专用警告信息，也会启动现有的 CDE。

在以前的版本中，存在一个已知问题：使用 Microsoft Azure DevOps、Bitbucket 或 GitHub 供应商与 CHE_FORCE_REFRESH_PERSONAL_ACCESS_TOKEN 属性的连接。每次启动工作区时，会添加一个新的个人访问令牌(PAT)，并且之前没有被删除。当存在超过五个现有的 PAT 时，您无法运行工作区，且仪表板不可用。这个版本解决了这个缺陷。

在 Visual Studio Code - Open Source ("Code - OSS")编辑器，点欢迎页面中的链接和项目 README 文件无效。这个版本解决了这个缺陷。

在这个版本中，Intelij IDEA 社区已弃用。

存在一个已知问题：在没有 devfile.yaml 文件的情况下影响存储库。如果您从此类存储库的分支启动新的工作区，则默认分支（如 'main'）将用于项目克隆，而不是预期的分支。

当使用 GitHub 和 Microsoft Azure DevOps OAuth 提供程序的 CHE_FORCE_REFRESH_PERSONAL_ACCESS_TOKEN 属性应用实验性刷新令牌模式时，存在一个已知问题。这会导致工作区开始重新载入仪表板，在每个页面重启时创建一个新的个人访问令牌。刷新令牌模式可用于 'GitLab' 和 'BitBucket' OAuth 供应商。

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 中的 debugger - 开源无法在 .NET 示例中工作。