3.18.0 发行注记和已知问题

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

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

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

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

与外部服务的通信通过 TLS 加密，需要由受信任的证书颁发机构(CA)签名的证书。因此，外部服务使用的所有不受信任的 CA 链都应导入到 Dev Spaces。

从这个版本开始，从安装命名空间中标记的 ConfigMap 用作 TLS 证书的源。ConfigMap 可以有任意数量的键，每个键都有任意数量的证书。操作器将所有 ConfigMap 合并到标题为 ca-certs-merged 的单个 ConfigMap 中，并在操作对象和 Cloud Development Environment (CDE) pod 中作为卷挂载。

默认情况下，Operator 将 ca-certs-merged ConfigMap 挂载到用户的 CDE 中，位于两个位置： /public-certs 和 /etc/pki/ca-trust/extracted/pem。/etc/pki/ca-trust/extracted/pem 目录是系统在红帽（如 CentOS、Fedora）上为可信证书颁发机构提取的 CA 证书的位置。当用户的 CDE 启动并运行时，CLI 工具会自动使用来自系统可信位置的证书。

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

从这个版本开始，您可以在单个 Dev Spaces 实例中配置两个 Gitlab OAuth 供应商。当开发人员处理托管在 GitLab SaaS 和内部的代码库时，这特别有用。

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

在这个版本中，无论集群中的身份验证方法设置是什么，可以从 User Dashboard 创建或导入 .gitconfig 文件。

在此版本之前，如果您通过 LDAP 或本地身份验证登录，则无法创建或导入 .gitconfig 文件。反之，您必须在命名空间中为 .gitconfig 文件手动创建专用配置映射。

此 官方文档 定义了从这个版本开始，使用 CLI 或 Web 控制台 UI 在 OpenShift 集群上安装 Dev Spaces 的最小权限。

当在 devfile 容器组件 端点 上设置 discoverable: true 属性时，会创建一个专用服务并用于端点。对于没有设置 discoverable: true 属性的所有其他端点，将使用通用工作区服务。

为端点创建的专用服务将具有静态名称，对应于端点的名称。例如，名为 http-python 的服务将在以下示例端点中生成：

# Example endpoint with discoverable attribute
- exposure: public
  targetPort: 8080
  name: http-python
  protocol: http
  secure: true
  attributes:
    discoverable: true

# Example endpoint with discoverable attribute
- exposure: public
  targetPort: 8080
  name: http-python
  protocol: http
  secure: true
  attributes:
    discoverable: true

在这个版本中，您可以利用 OpenShift Template 对象，并在所有用户的命名空间中复制其中定义的资源，例如：

*LimitRange *ResourceQuota *NetworkPolicy *Role *RoleBinding

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

从这个版本开始，如果集群自动扩展在 Cloud Developer Environment (CDE)启动过程中置备新的 worker 节点，则会出现专用警告信息的通知。

在这个版本中，您可以使用 devfile postStart 事件和 automount ConfigMap 组合安装默认的 Visual Studio Code - Open Source ("Code - OSS")扩展：

  - id: add-default-extensions
    exec:
      # put your tooling container name here
      component: runtime
      commandLine: |
        # download regular binary
        curl open-vsx.org/api/atlassian/atlascode/3.0.10/file/atlassian.atlascode-3.0.10.vsix --location -o /tmp/atlassian.atlascode-3.0.10.vsix
        curl open-vsx.org/api/snowflake/snowflake-vsc/1.9.1/file/snowflake.snowflake-vsc-1.9.1.vsix --location -o /tmp/snowflake.snowflake-vsc-1.9.1.vsix

events:
  postStart:
    - add-default-extensions

  - id: add-default-extensions
    exec:
      # put your tooling container name here
      component: runtime
      commandLine: |
        # download regular binary
        curl open-vsx.org/api/atlassian/atlascode/3.0.10/file/atlassian.atlascode-3.0.10.vsix --location -o /tmp/atlassian.atlascode-3.0.10.vsix
        curl open-vsx.org/api/snowflake/snowflake-vsc/1.9.1/file/snowflake.snowflake-vsc-1.9.1.vsix --location -o /tmp/snowflake.snowflake-vsc-1.9.1.vsix

events:
  postStart:
    - add-default-extensions

在这个版本中，Dev Spaces 的安全最佳实践信息包括在 官方文档 中。

当活动跟踪器扩展无法 ping idler 服务时，不会显示面向用户的错误消息。这可能会导致您的云环境(CDE)因为空闲程序被终止，即使您主动使用 CDE 时也是如此。在这个版本中，当无法访问空闲服务时，错误通知会发出警告。

在这个版本中，所有工作区文档的 Enabling fuse-overlayfs 已被更新，使其包含对 Podman 5.x 的支持。

在以前的版本中，"Temporary Storage"交换机在用户仪表板上无法正常工作。这个版本解决了这个缺陷。

在以前的版本中，如果 admin 为 Cloud Development Environments (CDEs)配置允许 URL，则在点击用户点击"信任存储库作者"弹出窗口中的"继续"按钮后，工作区创建会被停止。这个版本解决了这个缺陷。

在以前的版本中，如果您拒绝 OAuth 授权，Cloud Development Environment (CDE)将不会启动。这个版本解决了这个缺陷。

在此发行版本中，在 Cloud Development Environment (CDE)启动过程中可能会出现错误消息："No IDE URL after 20 sec startup'。这个版本解决了这个缺陷。

"Workspace Details"下拉菜单项返回至导航栏。

在此版本之前，无法从内部托管的 Gitlab 存储库中的 .devfile.yaml 创建云环境(CDE)。在这个版本中，这个问题已被解决。

存在一个已知问题：一个已知问题，它会影响使用基于 ubi-9- 的工作区，而无需 libbrotli 库作为工具容器。如果您启动工作区，则会出现以下出错信息："Failed to open the workspace: The workspace status remains the "Starting" （最后 300 秒）。

在将 Dev Spaces 从版本 3.17.0 升级到 3.18.0 后，存在一个已知问题会影响 Visual Studio Code - Open Source ("CODE - OSS")。如果您在 Dev Spaces 3.17.0 中的示例中打开了之前创建的工作区，则 Visual Studio Code 的旧版本(1.93.0)会显示它而不是新版本(1.96.0)。

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

存在一个已知问题：在没有 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.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 示例中工作。