3.16.0 发行注记和已知问题

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

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

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

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

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

在这个版本中，devworkspace-webhook-server 部署选项在全局 DevWorkspaceOperatorConfig (DWOC)中提供，包括 副本、pod tolerations 和 nodeSelector。

这些配置选项存在于全局 DWOC 的 config.webhook 字段中：

apiVersion: controller.devfile.io/v1alpha1
kind: DevWorkspaceOperatorConfig
metadata:
  name: devworkspace-operator-config
  namespace: $OPERATOR_INSTALL_NAMESPACE
config:
 routing:
   clusterHostSuffix: 192.168.49.2.nip.io
   defaultRoutingClass: basic
 webhook:
   nodeSelector: <string, string>
   tolerations: <[]tolerations>
   replicas: <int32>

在这个版本中，当您从 URL 启动云开发环境(CDE)时，要求您信任存储库的作者，因为从未知或不受信任的源创建工作区可能会危险。

从这个版本开始，可以使用 "Import from Git" 流启动 CDE 时配置容器镜像、临时存储、内存和 CPU 限制。

在这个版本中，您只能为 Git 配置设置 名称和 电子邮件，还可以从 User Dashboard 上传和编辑整个 .gitconfig 文件。

从这个版本开始，您可以在 CheCluster CustomResource 级别上明确设置 ignoredUnrecoverableEvents ：

apiVersion: org.eclipse.che/v2
kind: CheCluster
spec:
  devEnvironments:
    ignoredUnrecoverableEvents:
    - FailedScheduling
    - FailedMount

有关配置 ignoredUnrecoverableEvents 的更多详细信息，请参阅 官方文档。

DisableInitContainer 字段已添加到 CheCluster CR 中。此字段在 operator-owned DWOC 中设置 config.workspaces.persistUserHome.disableInitContainer 字段。此字段是否应禁用初始化持久主目录的 init 容器。

当 /home/user 目录持久化时，init 容器会在工作区启动前初始化目录。如果设置为 true，则不会创建 init 容器，将家持久性设置委派到 CDE 的第一个容器组件的入口点。如果 devEnvironments.persistUserHome.enabled 字段设置为 false，则不使用此字段。

init 容器默认启用。

在这个版本中，您可以在用户仪表板上添加个人访问令牌时，在 Git Provider Endpoint 的 URL 中提供端口。在以前的版本中，因为严格的验证无法进行。

在此版本之前，当启用 spec.devEnvironments.persistUserHome 选项时，.kube/config 中的令牌不会在工作区重启过程中自动更新。

您可以在 官方文档 中找到有关自动令牌注入的更多详细信息。

在以前的版本中，在使用 Local Devfile 功能中的 Restart Workspace 后，不会正确设置 PROJECTS_ROOT 和 PROJECT_SOURCE 环境变量。这个版本解决了这个缺陷。

在以前的版本中，当在 devfile 中使用命令定义执行命令时，它们有不同的 $PATH，与 components 部分中定义的容器中启动的命令不同。这个版本解决了这个缺陷。

在以前的版本中，用户无法在其 devfile 环境变量中引用 $PROJECT_ROOT 或 $PROJECT_SOURCE 环境变量。这个版本解决了这个问题。

在以前的版本中，在工作区启动过程中，即使工作区启动成功，状态可能会意外变为 'Stopped'。这个版本解决了这个缺陷，在工作空间启动过程中会忽略状态更改。

在以前的版本中，如果存储库没有 devfile.yaml，使用指定分支的克隆启动新的工作区无法正常工作。相反，默认分支总是在云环境(CDE)启动后克隆。这个版本解决了这个缺陷。

在此版本之前，Microsoft Azure 存储库的分支检测无法在用户仪表板中工作。这个版本解决了这个缺陷。

在此版本之前，从没有配置个人访问令牌(PAT)或 OAuth 的 GitHub Enterprise 公共存储库创建一个工作区会导致以下错误： "Failed to create the workspace.无法使用任何提供的参数构建工厂。请检查参数是否正确，并重新发送查询"。这个版本解决了这个缺陷。

在以前的版本中，使用实验性 CHE_FORCE_REFRESH_PERSONAL_ACCESS_TOKEN 功能可能会导致云开发环境(CDE)启动过程中 cyclic 重新加载序列。这个版本解决了这个缺陷。

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

在此发行版本中，通过手动粘贴仪表板中的密钥字符串来添加 SSH 密钥存在问题。保存 SSH 密钥并启动工作区后，不会使用以下错误消息克隆项目："Could not read from remote repository.请确保您具有正确的访问权限，并且存在存储库"。在这个发行版本中，这个问题已被解决。

在这个发行版本中，删除了特定于 Dev Spaces 的 devfile-registry 操作对象。要配置自定义 Getting-Started 示例，管理员应利用专用的 Kubernetes ConfigMap。

在 官方文档 中找到更多详细信息。

一个已知问题会影响使用 Microsoft Azure DevOps/Bitbucket/GitHub git 供应商与 CHE_FORCE_REFRESH_PERSONAL_ACCESS_TOKEN 属性的连接的工作区。每次启动工作区时，新的个人访问令牌(PAT)都会添加到之前的 PAT 中，它们 不会被删除。当现有 PAT 的数量超过 5 时，您无法运行工作区，且仪表板不可用。

使用 CHE_FORCE_REFRESH_PERSONAL_ACCESS_TOKEN 属性中存在一个已知问题。在使用属性后，以前的 Microsoft Azure DevOps/Bitbucket/GitHub 个人令牌不会被删除。这也可能会导致 访问仪表板 的问题。

目前，应用 Refused OAuth 授权时存在一个已知问题。当您使用 OAuth 设置启动工厂时，如果并应用 Refused OAuth 授权，则会再次出现 "Untrusted Repository" 弹出窗口。

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

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

集群启动并运行后，安装 OpenShift Dev Spaces 3.18 (3.18-36)，并验证最新的 DevWorkspace operator bundle 0.32 (0.32-2)或更新版本是否已安装和更新。请参阅 https://catalog.redhat.com/software/containers/devworkspace/devworkspace-operator-bundle/60ec9f48744684587e2186a3

生成的二进制文件可以被扫描，应无错误地传递。

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

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