ghcr.io/eclipse-score/devcontainer:latest

Eclipse S-CORE 的通用开发容器

本仓库包含 Eclipse S-CORE 的通用开发容器。它包含开发（修改、构建等）Eclipse S-CORE 所需的所有工具。所有工具版本均已明确定义，且所有工具均已预先配置，可按预期用于 Eclipse S-CORE 开发。该容器作为本仓库的一部分在 GitHub Actions 中预先构建、测试、发布，可供直接使用。

在 Eclipse S-CORE 仓库中使用预构建容器的方法在使用部分中描述。

容器内容的修改方法在开发部分中说明。

仓库结构

按重要性排序：

• src/s-core-devcontainer/ 包含 Eclipse S-CORE DevContainer 的源代码。它使用已有的 DevContainer 功能提供一些标准工具，如 Git、LLVM 等。此外，它使用所谓的“本地”功能（参见 src/s-core-devcontainer/.devcontainer/s-core-local）来提供其余工具和配置。
• scripts/ 包含用于构建和测试容器的脚本。
• .devcontainer/ 包含此仓库的 DevContainer 定义，即“devcontainer devcontainer”。通常很少需要修改此目录。
• .github/ 包含常规的 GitHub 配置，包括代码所有者和 CI。
• resources/ 包含一些截图。

仓库中的 QNX 支持

QNX 支持无法在这个共享的开发容器镜像中以通用方式提供，必须按仓库进行配置。基本原因是 QNX 许可证可能与用户名绑定，这对于通用容器镜像是无法支持的。更多详细信息请参见 https://github.com/eclipse-score/devcontainer/issues/49#issuecomment-4217458769%E3%80%82

推荐的方法如下：

1. 基于 ghcr.io/eclipse-score/devcontainer: 构建一个小型的仓库本地 Dockerfile。
2. 通过构建参数将默认的 vscode 用户重命名为主机用户名。
3. 将 QNX 许可证和凭据绑定挂载到容器中。
4. 在 initializeCommand 中创建缺失的主机文件，以确保启动顺利。

在仓库中使用以下设置：

.devcontainer/Dockerfile

FROM ghcr.io/eclipse-score/devcontainer:

ARG USERNAME=vscode

# 将 'vscode' 重命名为主机用户名，以满足 QNX 相关的用户预期。
# 在使用许可证服务器的环境中，QNX 许可证可能与用户名绑定。
RUN if [ "$USERNAME" != "vscode" ]; then \
usermod -l ${USERNAME} vscode \
&& groupmod -n ${USERNAME} vscode \
&& usermod -d /home/${USERNAME} -m ${USERNAME} \
&& ln -s /home/${USERNAME} /home/vscode \
&& echo "${USERNAME} ALL=(ALL) NOPASSWD:ALL"
> /etc/sudoers.d/${USERNAME} \
&& chmod 0440 /etc/sudoers.d/${USERNAME}; \
fi

USER ${USERNAME}

.devcontainer/devcontainer.json

{
"name": "eclipse-s-core",
"build": {
"dockerfile": "Dockerfile",
"args": {
"USERNAME": "${localEnv:USER}"
}
},
"remoteUser": "${localEnv:USER}",
"mounts": [
{
"source": "${localEnv:HOME}${localEnv:USERPROFILE}/.qnx/license/licenses",
"target": "/opt/score_qnx/license/licenses",
"type": "bind"
},
{
"source": "${localEnv:HOME}${localEnv:USERPROFILE}/.netrc",
"target": "/home/${localEnv:USER}/.netrc",
"type": "bind"
}
],
"initializeCommand": {
"Make sure QNX license exists": "mkdir -p ~/.qnx/license && touch -a ~/.qnx/license/licenses",
"Make sure .netrc exists": "touch -a ~/.netrc"
}
}

[!NOTE]

• .netrc 是一种实用的方式，可提供 myQNX 凭据，而无需将密钥提交到仓库中。

$ ./scripts/test.sh
[... test output...]
💯 All passed!

现在你也可以在本地机器上使用这个新构建的开发容器，例如将其作为Eclipse S-CORE模块的一部分进行测试。 为此，你需要了解当前的情况如下：

+---------------------------------+
| Development Container A |
| +---------------------------+ |
| | S-CORE DevContainer image | |
| +---------------------------+ |
+---------------------------------+

Development Container A 是你当前运行的容器，用于开发 S-CORE DevContainer。

因此，要在主机上执行 S-CORE DevContainer（并将其作为S-CORE模块的一部分进行测试），你需要：

• 导出这个新构建的S-CORE DevContainer镜像
• 在主机上导入该镜像
• 在目标S-CORE模块的 .devcontainer/devcontainer.json 中使用镜像名称和标签 latest

具体操作步骤如下：

• 在 Development Container A 中运行 `docker save "ghcr.io/eclipse-score/devcontainer:local-amd64"

export.img`。

• 在你的主机机器（!!）上，打开控制台并运行 docker load，然后按 Ctrl + Shift + P 并从中运行 "Dev Containers: Rebuild Container Without Cache"。 完成上述操作后，你将拥有一个与目标S-CORE模块相关的 S-CORE DevContainer 运行实例。

消费者测试

要在拉取请求中启用消费者测试，请阅读ci.md文档。

版本固定

S-CORE DevContainer 固定了功能和工具版本。 对于不属于可信发行版的工具（即直接下载的工具），它还固定了SHA256哈希。 虽然这不是工具更新最便捷的选择，但能显著增强我们的供应链安全性。 此外，这也避免了“意外更新”导致的意外故障。