发行注记和已知问题

OpenShift Dev Spaces 在以下 CPU 架构上的 OpenShift 4.10-4.13 上运行：

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

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

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

在这个版本中，管理员可以从托管在 Bitbucket 上的 devfile registry Git 仓库的克隆创建自定义 devfile registry。

在这个版本中，User Preferences 菜单带有一个 个人访问令牌 选项卡。您可以使用选项卡来管理 GitHub、GitLab、Bitbucket 和 Microsoft Azure DevOps 个人访问令牌。这适用于从 OpenShift Dev Spaces Dashboard UI 创建的令牌，以及使用 Kubernetes secret 手动创建的令牌。

此发行版本有两个 CheCluster CR 字段，用于管理与工作区 $HOME 目录相关的持久性：

在以前的版本中，如果配置了 OpenShift 集群范围代理，则 OpenShift Dev Spaces 中配置的可信 TLS 证书会被忽略。在这个版本中，您可以配置 DevWorkspace operator，以避免这种不必要的行为。

在这个版本中，Microsoft Visual Studio Code - Open Source 作为任务提供了父 devfile 中定义的命令。

在以前的版本中，用户在添加个人访问令牌时必须提供 Git 用户名。此步骤冗余，并导致错误。在这个版本中，步骤会从流程中删除。

默认情况下，OpenShift Dev Spaces 在 devfile 中指定的第一个容器中托管 IDE (Microsoft Visual Studio - Open Source Code 或 JetBrains IntelliJ IDEA 社区版本)。在这个版本中，您可以使用属性 controller.devfile.io/merge-contribution: true 指定托管 IDE 的组件。

在以下示例中，IDE 将托管在 "component2" 中：

schemaVersion: 2.2.0
components:
  - name: component1
    container:
      image: quay.io/sclorg/postgresql-15-c9s:c9s
  - name: component2
     attributes:
       controller.devfile.io/merge-contribution: true
     container:
       image: quay.io/devfile/developer-base-image:latest

schemaVersion: 2.2.0
components:
  - name: component1
    container:
      image: quay.io/sclorg/postgresql-15-c9s:c9s
  - name: component2
     attributes:
       controller.devfile.io/merge-contribution: true
     container:
       image: quay.io/devfile/developer-base-image:latest

在这个版本中，Podman 信任 OpenShift 内部容器注册表的 TLS 证书。您可以使用 Podman 在不手动添加证书的情况下拉取镜像。

在这个版本中，现有工作区的 IDE 会在升级后或 IDE 定义改变时自动更新。

在这个版本中，在工作区加载页面功能上"Waiting for a workspace to start"步骤为 7 子任务。此功能增强提供更好的进度反馈，并使故障排除变得更加容易。

在这个版本中，OpenShift Console Operator 指标中提供了以下指标：

在此次更新之前，管理员无法强制将容器列表添加到所有工作区。在这个版本中，要在 OpenShift Dev Spaces 中的所有工作区中自动包含特定容器，管理员可以将 URI 指定给在 CheCluster 自定义资源的 devEnvironments.defaultPlugins 中定义容器组件的 devfile。

在此次更新之前，从带有斜杠(/)的 Git 存储库的分支启动工作区会导致 "devfile could not be found" 错误。在这个版本中，这个问题已被解决。

在此次更新之前，如果管理员自定义了 CheCluster 自定义资源中的一些字段（如 .spec.components.pluginRegistry.openVSXURL），则 Operator 可能会覆盖这些值。在这个版本中，这个问题已被解决。

在此次更新之前，开发人员无法从 OpenShift Dev Spaces Dashboard 中的 User Preferences 菜单添加其 Microsoft Azure DevOps 个人访问令牌。在这个版本中，这个问题已被解决。

在此次更新之前，当开发人员试图通过 GitHub 进行身份验证（例如克隆存储库或使用 GitHub 扩展），并带有已过期的 GitHub 令牌或没有令牌的 GitHub 扩展时，操作可能会因为授权错误而失败。在这个版本中，如果没有找到有效的 GitHub 令牌，则会告知用户如何生成它。

在此次更新之前，当开发人员启动空工作区（未链接到特定 Git 存储库）或 OpenShift Dev Spaces 示例时，任何 consequent 尝试运行 git push 都会因为授权问题而失败。即使开发人员预配置了 Git 服务的个人访问令牌，也会发生这种情况。在这个版本中，预先配置的个人访问令牌挂载到空工作区和示例工作区中，以便 git push 成功运行。

存在一个已知问题：如果您使用 Java 或 Ansible 示例，则推荐的 Microsoft Visual Studio Code 的自动安装 - 开源扩展会失败。

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 合规性。

目前，对于将 Kubernetes Secret 与 Git-provider 凭证一起使用 的用户存在一个已知问题。这些用户的工作区中 Git 操作的用户名和电子邮件目前来自 <user> - devspaces 命名空间的 user -profile Secret。

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