CI/CD 工作流

相关源文件

• .github/workflows/docker.yml
• .github/workflows/pr.yml

本文档描述了 Base Node 仓库中使用的持续集成和持续部署（CI/CD）工作流。这些工作流自动化了 Base Node 支持的各种执行客户端的 Docker 镜像的测试、构建和发布。

有关这些工作流构建和发布的 Docker 基础架构的信息，请参阅 Docker 基础架构。

1. CI/CD 工作流概述

Base Node 仓库采用了两种主要 GitHub Actions 工作流：

1. PR 工作流：在拉取请求上验证 Docker 构建。
2. Docker 构建与推送工作流：为发布构建并发布官方 Docker 镜像。

这些工作流确保了所有支持的执行客户端（Geth、Reth 和 Nethermind）的 Docker 镜像都能在 amd64 和 arm64 架构上得到正确测试和发布。

来源：.github/workflows/pr.yml1-85 .github/workflows/docker.yml1-17

2. PR 工作流

PR 工作流在每次拉取请求时触发，也可手动触发。其主要目的是在合并更改之前，验证所有执行客户端和平台架构的 Docker 镜像是否能够成功构建。

2.1 工作流结构

PR 工作流包含三个并行作业：

1. geth：构建 Geth 执行客户端镜像。
2. reth：构建 Reth 执行客户端镜像。
3. nethermind：构建 Nethermind 执行客户端镜像。

每个作业都在包含 amd64 和 arm64 架构的平台矩阵上执行。

来源：.github/workflows/pr.yml3-84

2.2 构建过程

对于每个执行客户端，工作流会检出代码，设置 Docker Buildx，然后构建 Docker 镜像，但不将其推送到注册表。

Reth 构建包含特定的优化功能标志，amd64 (jemalloc,asm-keccak,optimism) 和 arm64 (jemalloc,optimism) 使用不同的设置。

Job: geth → Build with geth/Dockerfile
Job: reth → Build with reth/Dockerfile + features
Job: nethermind → Build with nethermind/Dockerfile

来源：.github/workflows/pr.yml27-32 .github/workflows/pr.yml53-60 .github/workflows/pr.yml79-84

3. Docker 构建与推送工作流

Docker 构建与推送工作流负责将官方 Docker 镜像构建、标记并发布到 GitHub Container Registry (GHCR)。它在以下情况触发：

• 推送到主分支
• 以“v”开头的标签推送（用于版本化发布）

3.1 镜像注册表和命名

工作流为 Docker 镜像使用以下命名约定：

执行客户端	镜像名称
Geth	ghcr.io/base/node-geth
Reth	ghcr.io/base/node-reth
Nethermind	ghcr.io/base/node-nethermind

为向后兼容，Geth 镜像也作为 ghcr.io/base/node 发布。

来源：.github/workflows/docker.yml10-16

3.2 工作流结构

Docker 工作流包含六个作业：

1. geth：为不同架构构建和推送 Geth 镜像。
2. reth：为不同架构构建和推送 Reth 镜像。
3. nethermind：为不同架构构建和推送 Nethermind 镜像。
4. merge-geth：为 Geth 镜像创建多架构清单。
5. merge-reth：为 Reth 镜像创建多架构清单。
6. merge-nethermind：为 Nethermind 镜像创建多架构清单。

来源：.github/workflows/docker.yml18-323

3.3 构建和推送过程

每个构建作业：

1. 登录到 GitHub Container Registry。
2. 提取 Docker 镜像的元数据。
3. 构建并推送特定架构的镜像。
4. 导出并上传多架构清单的摘要。

工作流使用 Docker Buildx 同时构建不同平台的镜像，并通过摘要将其推送到注册表。

来源：.github/workflows/docker.yml32-82 .github/workflows/docker.yml94-141 .github/workflows/docker.yml156-201

3.4 多架构清单创建

在构建并推送完所有特定架构的镜像后，合并作业会：

1. 下载所有特定架构构建的摘要。
2. 使用 Docker Buildx imagetools 创建多架构清单列表。
3. 将清单列表推送到注册表。
4. 检查生成的多架构镜像。

此过程确保当用户拉取镜像而不指定架构时，他们能获得适合其平台的镜像。

来源：.github/workflows/docker.yml204-323

4. CI/CD 与 Base Node 组件的集成

Base Node 仓库中的 CI/CD 工作流与系统的各个组件紧密集成。它们确保所有支持的执行客户端的 Docker 镜像都能得到正确的构建、测试和发布。

来源：.github/workflows/pr.yml1-85 .github/workflows/docker.yml1-324

5. 标签和发布流程

当 Base Node 发布新版本时，发布流程通过创建标签来触发 Docker 构建与推送工作流。

5.1 基于标签的版本控制

Docker 构建与推送工作流配置为在以“v”开头的标签（例如 v1.0.0）上触发。当推送此类标签时，工作流会：

1. 为所有执行客户端和架构构建镜像。
2. 使用从标签中提取的版本号标记镜像。
3. 创建带有版本标签的多架构清单。

这样可以确保用户能够使用版本标签拉取特定版本的 Base Node 镜像。

来源：.github/workflows/docker.yml3-8 .github/workflows/docker.yml41-46

6. 贡献者最佳实践

对于贡献 Base Node 仓库的开发人员来说，理解 CI/CD 工作流对于确保更改的顺利集成至关重要。

6.1 拉取请求指南

提交拉取请求时

1. 检查 PR 构建：确保 PR 工作流在所有执行客户端和架构上成功完成。
2. Dockerfile 更改：如果修改 Dockerfile，请尽可能在本地为 amd64 和 arm64 架构测试构建。
3. 功能标志：对于 Reth 特定更改，请注意不同架构使用的不同功能标志。

6.2 工作流修改

修改 CI/CD 工作流时：

1. 手动测试：在合并更改之前，使用“workflow_dispatch”触发器进行测试。
2. 考虑两种架构：确保更改对 amd64 和 arm64 都有效。
3. 保持向后兼容性：请记住，Geth 镜像需要在新旧名称下都发布。

有关更详细的贡献指南，请参阅 贡献指南。

来源：.github/workflows/pr.yml5 .github/workflows/docker.yml44-45