发行注记和已知问题

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

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

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

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

在这个版本中，对于 DevWorkspace 容器，可以使用专用的 CheCluster CR 字段设置 ImagePullPolicy。

apiVersion: org.eclipse.che/v2
kind: CheCluster
spec:
  devEnvironments:
    imagePullPolicy: <Always|IfNotPresent>

在这个版本中，kubedock 是 UDI (OpenShift Dev Spaces 默认镜像)的一部分。如果在工作区中将环境变量 KUBEDOCK_ENABLED 设置为 true （这可以通过 devfile 进行），则 kubedock 服务器在启动时启动。

当 KUBEDOCK_ENABLED=true 时，将用 kubedock 执行以下命令。剩余的命令（特别是 podman build ）将由本地 Podman 执行：

在这个版本中，以下 CheCluster CR 字段可用：* spec.devEnvironments.security * spec.devEnvironments.security.containerSecurityContext * spec.devEnvironments.security.podSecurityContext

通过设置对应的 'DevWorkspaceOperatorConfiguration 字段，使用 spec.devEnvironments.security.containerSecurityContext 和 spec.devEnvironments.security.podSecurityContext'fields 来配置工作区使用的 pod 和安全上下文。

在这个版本中，您可以使用专用 ConfigMap 对象在 User Dashboard 上配置"Getting Started"示例：

apiVersion: v1
kind: ConfigMap
metadata:
  name: getting-started-sample
  namespace: openshift-devspaces
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: getting-started-samples
data:
  my-samples: |-
    [
      {
        "displayName": "Eclipse Che Dashboard",
        "description": "Cloud Development Environment for the Eclipse Che Dashboard.",
        "tags": ["Eclipse Che", "Dashboard"],
        "url": "https://github.com/eclipse-che/che-dashboard"
      }
    ]

现在，您可以从 User Dashboard 上的 Workspace Details → DevWorkspace 视图导航到 OpenShift 控制台来检查或编辑 DevWorkspace 对象。

在这个版本中，您可以使用专用的 CheCluster 自定义资源属性更改 OpenShift Dev Spaces 徽标：

apiVersion: org.eclipse.che/v2
kind: CheCluster
spec:
  components:
    dashboard:
      branding
        logo:
          base64data: <base64-encoded-data>
          mediatype: image/png

在此次更新之前，在使用 Bitbucket OAuth 集成的 OpenShift Dev Spaces 安装的工作区中包括 Bitbucket 个人访问令牌(PAT)会导致 "Backend is not available" 错误消息。在这个版本中，工作区会在没有问题的情况下启动。

在此次更新之前，OpenShift Dev Spaces 无法在 GitLab 私有存储库的根目录中找到 devfile。这个版本解决了这个问题。

在此次更新之前，devfile 中的卷大小会被忽略。在这个版本中，如果 DevWorkspace 中至少有一个卷指定了其大小，并且计算的 PVC 大小大于默认的 per-workspace PVC 大小，则会使用计算的 PVC 大小。

在此次更新之前，当提供的 URL 以 .git 后缀结尾时，OpenShift Dev Spaces 无法在 Azure DevOps Git 存储库中找到 devfile.yaml。这个版本已解决此行为。

在此次更新之前，当导航到 OpenShift Dev Spaces 用户仪表板中的 "Existing Workspace" 页面时，您可以很快遇到页面。这个版本已解决。

在此次更新之前，用户仪表板有时会创建一个工作区两次，从而导致 "409 Conflict" 错误。这个版本已解决此行为。

在此次更新之前，当原始 devfile 的文件名不是 devfile.yaml 或 . devfile.yaml 时，工作区启动会失败。 在这个版本中，原始 devfile 的名称不会阻止成功启动工作区。

在此次更新之前，从外部 devfile registry 下载项目 zip 文件会失败，并显示 "x509: certificate signed by unknown authority" 错误。在这个版本中，project-clone init 容器读取存储在 /public-certs 中的任何 .crt 或 .pem 文件。这些证书被添加到用于在 DevWorkspace 中准备基于 zip 的项目的 HTTP 客户端中，并允许您从 default-untrusted 源下载项目 zips，如自动挂载证书到容器中的 /public-certs。

在此次更新之前，路由创建过程中会出现失败。在这个版本中，DevWorkspace operator 中的路由处理有所改进。

在此次更新之前，为 Bitbucket OAuth 应用授予额外权限会破坏工作区启动流。在这个版本中，这个问题已被解决。

在此次更新之前，无法基于不包含元数据的 Devfiles 启动工作区。在这个版本中，没有 .metadata.name 的 devfile 被视为有效。这与 规格 一致。

在此次更新之前，OpenShift Dev Spaces 在成功 OAuth 身份验证后缺少 factory URL 参数。这会导致工作区没有启动。在这个版本中，这个问题已被解决。

在此次更新之前，GitLab OAuth 令牌在 2 小时后过期，且不会在工作区重启后刷新。在这个版本中，这个问题已被解决。

在此次更新之前，临时模式用于 'Restart 带有默认 devfile' 功能。重启时，工作区中的所有更改都会丢失。在这个版本中，使用默认 devfile 重启工作区不会清除之前所做的更改。

存在一个已知问题：如果您使用 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 示例中工作。