多组织共享集成测试环境问题分析与解决方案

[ZCShou]

多组织共享集成测试环境问题分析与解决方案

问题背景

当前架构

当前集成测试采用基于 GitHub Actions 的集成测试方案，通过自托管 Runner（Self-hosted Runner）连接本地硬件测试环境。整体架构如下：

graph TB
    subgraph GitHub["GitHub 平台层"]
        direction LR
        OrgA["组织 A<br/>(arceos-hypervisor)<br/>└─ 仓库: axvisor<br/>└─ .github/workflows/"]
        OrgB["组织 B"]
        OrgC["组织 C"]
        OrgN["..."]
    end

    subgraph Runners["自托管 Runner 层"]
        direction LR
        Runner1["Runner-1"]
        Runner2["Runner-2"]
        Runner3["Runner-3"]
        RunnerN["Runner-N"]
    end

    subgraph Hardware["本地测试环境（独占资源）"]
        direction TB
        subgraph Devices["硬件设备"]
            Dev1["开发板 1"]
            Dev2["开发板 2"]
            Dev3["开发板 3"]
            DevX["x86 设备"]
        end
        subgraph Control["控制设备"]
            Power["电源控制"]
            Router["路由器"]
            PXE["PXE 服务"]
        end
    end

    OrgA -->|Webhook| Runner1
    OrgB -->|Webhook| Runner2
    OrgC -->|Webhook| Runner3
    OrgN -->|Webhook| RunnerN

    Runner1 --> Hardware
    Runner2 --> Hardware
    Runner3 --> Hardware
    RunnerN --> Hardware

    style GitHub fill:#e1f5ff
    style Runners fill:#fff4e1
    style Hardware fill:#ffe1f5
    style Devices fill:#f0f0f0
    style Control fill:#f0f0f0

Loading

核心问题

由于当前我们组件化内核的各个组件和衍生的 OS 分布在不同的 GitHub 组织中（例如 arceos-hypervisor、arceos-org 等），而集成测试环境（硬件设备、测试服务器）是物理上唯一的独占资源。当多个组织的仓库同时触发 CI 时，会出现以下问题：

1. 资源竞争：多个 Runner 同时尝试访问同一硬件设备
2. 测试冲突：不同组织的测试任务并行执行，互相干扰
3. 结果不可靠：由于资源争用导致测试失败，但这是环境问题而非代码问题
4. 效率低下：需要手动协调不同组织的测试时间

技术原因：

• 每个 GitHub 组织的 Runner 是独立的，无法感知其他组织的任务状态
• GitHub Actions 的调度机制基于组织级别，无法跨组织协调
• 硬件测试设备（串口、网络、电源）不支持并发访问

影响范围：

• 跨组织的依赖测试无法自动化
• 需要人工干预协调测试执行顺序
• CI/CD 流程的可靠性降低
• 开发效率受到影响

---

详细问题分析

1. GitHub Actions 的多租户隔离机制

GitHub Actions 的设计天然支持多租户隔离：

graph LR
    subgraph OrgA["组织 A 的 Runner Pool"]
        direction TB
        RunnerA1["Runner A1<br/>只能执行组织 A 的任务"]
        RunnerA2["Runner A2<br/>只能执行组织 A 的任务"]
        RunnerAN["..."]
    end

    subgraph OrgB["组织 B 的 Runner Pool"]
        direction TB
        RunnerB1["Runner B1<br/>只能执行组织 B 的任务"]
        RunnerB2["Runner B2<br/>只能执行组织 B 的任务"]
        RunnerBN["..."]
    end

    style OrgA fill:#e1f5ff
    style OrgB fill:#ffe1f5
    style RunnerA1 fill:#ffffff
    style RunnerA2 fill:#ffffff
    style RunnerB1 fill:#ffffff
    style RunnerB2 fill:#ffffff

Loading

隔离特性：

• Runner 注册时绑定到特定的组织或仓库
• 不同组织的 Runner 无法共享任务队列
• 没有跨组织的任务调度机制

2. 硬件资源的独占性

测试环境的硬件设备具有独占性：

设备类型	独占原因	并发问题
开发板	单一固件运行空间	多个固件无法同时加载
串口 (USB-TTL)	物理端口唯一	同时写入导致数据混乱
电源控制模块	单一控制通道	无法同时控制多个状态
PXE 服务	网络端口绑定	多个 TFTP 请求冲突
网络路由器	IP 地址分配	IP 地址冲突

3. 当前方案的局限性

基于现有实现：

# 每个 Runner 独立注册到一个组织
./config.sh --url https://github.com/arceos-hypervisor/axvisor \
            --token TOKEN_A \
            --name runner-1

./config.sh --url https://github.com/another-org/repo \
            --token TOKEN_B \
            --name runner-2

导致问题场景：

时间线：
T1: 组织 A 的仓库触发 CI → Runner-1 开始使用开发板 1
T2: 组织 B 的仓库触发 CI → Runner-2 尝试使用开发板 1 (冲突!)
T3: 两个任务同时写入串口 → 数据混乱 → 测试失败

---

主流解决方案

方案一：GitHub Enterprise Server（企业版）

方案概述

使用 GitHub Enterprise Server 将所有组织纳入统一的企业账号下，将 Runner 注册到 Enterprise 而非单个组织，通过企业级 Runner Pool 实现跨组织的资源共享和统一调度。

架构设计

与 GitHub Actions（开源版）的不同，企业版可以利用 GitHub 原生的任务调度机制实现并发控制，完全兼容 GitHub Actions 的工作流语法，无需修改现有的 CI 配置文件。

特性	GitHub Actions（开源版）	GitHub Enterprise
Runner 作用域	组织或仓库级别	企业级别
资源共享	不支持跨组织	原生支持
任务调度	组织独立调度	企业统一调度
权限控制	组织级别	企业 + 组织多级
并发控制	仅组织内	企业级别

graph TB
    subgraph Enterprise["GitHub Enterprise Server"]
        direction TB

        subgraph Orgs["组织层"]
            direction LR
            OrgA["组织 A<br/>(axvisor-core)"]
            OrgB["组织 B<br/>(axvisor-apps)"]
            OrgC["组织 C<br/>(axvisor-drivers)"]
        end

        subgraph RunnerPool["企业级 Runner Pool<br/>(共享资源池)"]
            direction LR
            SharedRunner1["共享 Runner-1<br/>(hardware-test)"]
            SharedRunner2["共享 Runner-2<br/>(hardware-test)"]
            SharedRunnerN["共享 Runner-N"]
        end
        
        subgraph Scheduler["企业级调度器"]
            Sched["统一任务调度<br/>并发控制"]
        end
    end

    subgraph Hardware["本地测试环境"]
        direction TB
        HW1["硬件设备 1"]
        HW2["硬件设备 2"]
        HWN["..."]
    end

    OrgA --> Scheduler
    OrgB --> Scheduler
    OrgC --> Scheduler
    
    Scheduler --> RunnerPool
    RunnerPool --> Hardware

    style Enterprise fill:#e1f5ff
    style Orgs fill:#ffffff
    style RunnerPool fill:#fff4e1
    style Scheduler fill:#f0f0f0
    style Hardware fill:#ffe1f5
    style OrgA fill:#e8f4f8
    style OrgB fill:#e8f4f8
    style OrgC fill:#e8f4f8

Loading

实施步骤

1. 申请和部署 GitHub Enterprise

选择部署方式：

选项 A：GitHub Enterprise Cloud（云端托管）

• 访问 https://github.com/enterprise
• 选择 Enterprise Cloud 计划
• 按用户数付费（约 $21/用户/月）
• 无需自行维护基础设施

选项 B：GitHub Enterprise Server（自托管）

• 下载并在自己的服务器上部署
• 需要购买许可证（起价 $21/用户/月，最低 20 用户）
• 需要自行维护和升级

2. 迁移组织到企业

# 使用 GitHub API 迁移现有组织到企业
curl -X POST \
  -H "Authorization: token YOUR_ADMIN_TOKEN" \
  -H "Accept: application/vnd.github.v3+json" \
  https://api.github.com/admin/organizations \
  -d '{
    "login": "axvisor-core",
    "admin": "admin_user",
    "profile_name": "AxVisor Core"
  }'

3. 配置企业级 Runner

步骤 3.1：创建 Runner Group

# 通过 GitHub UI 配置
# 1. 进入 Enterprise Settings > Actions > Runner groups
# 2. 点击 "New runner group"
# 3. 输入名称：hardware-test-runners
# 4. 设置访问权限：
#    - Public：所有组织都可以访问
#    - Selected：仅指定组织可以访问

步骤 3.2：获取注册令牌

# Enterprise Settings > Actions > Runners > New runner
# 生成企业级 Runner 的注册令牌

步骤 3.3：注册 Runner 到企业级别

# 下载 Runner 配置脚本
# 在 Runner 服务器上执行

# 配置 Runner（注册到企业级别）
./config.sh \
  --url https://github.yourdomain.com/enterprises/your-enterprise \
  --token ENTERPRISE_RUNNER_TOKEN \
  --name shared-runner-1 \
  --labels "self-hosted,hardware,test,device-1" \
  --runnergroup hardware-test-runners

# 启动 Runner
./run.sh

步骤 3.4：配置并发控制

# 在 Enterprise Settings 中配置
# Actions > General > Runner concurrency
# 设置：Limit concurrent jobs to 1（确保硬件资源独占）

4. 配置访问控制策略

创建 Runner Group 并限制访问

# 通过 GitHub UI 或 API 配置
# Runner Group: hardware-test-runners
# 访问策略：Selected organizations
# 允许的组织：
#   - axvisor-core
#   - axvisor-apps
#   - axvisor-drivers

设置组织级别权限

# Enterprise Settings > Organizations
# 为每个组织配置：
# - 基础访问权限
# - Runner 使用权限
# - 仓库管理权限

5. 更新工作流配置

对于已经支持使用当前的测试环境的组织，例如 AxVisor，则无需任何更改；对于其他组织，参考 AxVisor 的 CI 更新使用自托管 runner 即可。

6. 验证配置

测试跨组织访问

# 在组织 A 的仓库中触发 CI
git push origin main

# 在组织 B 的仓库中触发 CI（同时）
git push origin main

# 验证：
# 1. 两个任务都进入企业级队列
# 2. 由于并发限制，一个任务执行，另一个等待
# 3. 第一个任务完成后，第二个任务自动开始

监控 Runner 状态

# 通过 GitHub UI 查看
# Enterprise Settings > Actions > Runners
# 可以看到：
# - 所有 Runner 的状态
# - 当前执行的任务
# - 排队中的任务

---

方案二：第三方 CI/CD 平台

方案概述

使用支持自托管和并发控制的第三方 CI/CD 平台（如 GitLab CI、Jenkins、CircleCI 等）替代 GitHub Actions，通过统一任务队列和集中式调度解决多组织共享硬件资源的问题。

架构设计

所有组织的代码仍然托管在 GitHub，无需迁移代码仓库，通过 Webhook 触发 CI/CD 平台。CI 平台层接收来自 GitHub 的推送事件，然后执行处理。所有组织的任务进入同一个队列，根据并发限制配置分配任务给 Agent。

graph TB
    subgraph GitHub["GitHub 仓库层"]
        direction LR
        OrgA["org-a/repo"]
        OrgB["org-b/repo"]
        OrgC["org-c/repo"]
    end

    subgraph CI["第三方 CI 平台<br/>(GitLab CI / Jenkins)"]
        direction TB
        subgraph Webhook["Webhook 接收"]
            WH["Webhook Server"]
        end
        
        subgraph Queue["统一任务队列"]
            Task1["Task 1<br/>(org-a/repo)<br/>[执行中]"]
            Task2["Task 2<br/>(org-b/repo)<br/>[排队中]"]
            Task3["Task 3<br/>(org-c/repo)<br/>[排队中]"]
        end
        
        subgraph Scheduler["中央调度器"]
            Sched["调度器<br/>concurrent=1"]
        end
    end

    subgraph Agents["自托管 Executor/Agent"]
        direction LR
        Agent1["Agent-1<br/>串行执行任务"]
        Agent2["Agent-2"]
        AgentN["..."]
    end

    subgraph Hardware["本地测试环境"]
        direction TB
        HW1["硬件设备 1"]
        HW2["硬件设备 2"]
        HWN["..."]
    end

    OrgA -->|Webhook| Webhook
    OrgB -->|Webhook| Webhook
    OrgC -->|Webhook| Webhook
    
    Webhook --> Queue
    Queue --> Scheduler
    Scheduler --> Agents
    Agents --> Hardware

    style GitHub fill:#e1f5ff
    style CI fill:#fff4e1
    style Queue fill:#ffffff
    style Scheduler fill:#f0f0f0
    style Agents fill:#e1f5ff
    style Hardware fill:#ffe1f5
    style Task1 fill:#d4edda
    style Task2 fill:#fff3cd
    style Task3 fill:#fff3cd

Loading

方案 2.1：GitLab CI with Self-Hosted Runners

实施步骤

1. 安装 GitLab CE/EE

   # 使用 Docker 安装 GitLab
   docker run -d \
     --hostname gitlab.example.com \
     --publish 443:443 --publish 80:80 --publish 22:22 \
     --name gitlab \
     --restart always \
     --volume /srv/gitlab/config:/etc/gitlab \
     --volume /srv/gitlab/logs:/var/log/gitlab \
     --volume /srv/gitlab/data:/var/opt/gitlab \
     gitlab/gitlab-ce:latest

2. 配置 GitLab Runner

   # 注册 Runner
   sudo gitlab-runner register \
     --url https://gitlab.example.com \
     --registration-token REGISTRATION_TOKEN \
     --executor shell \
     --description "Hardware Test Runner" \
     --tag-list "hardware,test" \
     --run-untagged=false \
     --locked=false

3. 配置并发控制

   # /etc/gitlab-runner/config.toml
   concurrent = 1  # 限制并发任务数为 1
   check_interval = 0
   
   [[runners]]
     name = "hardware-test-runner"
     url = "https://gitlab.example.com"
     token = "RUNNER_TOKEN"
     executor = "shell"
     limit = 1  # 每个 Runner 最多执行 1 个任务
     [runners.custom_build_dir]
       enabled = true

4. 创建 CI 配置

   # .gitlab-ci.yml
   stages:
     - hardware-test
   
   hardware-test:
     stage: hardware-test
     tags:
       - hardware
       - test
     script:
       - ./scripts/hardware-test.sh
     only:
       - main
       - develop

5. 配置 GitHub 集成

   • 在 GitLab 中配置 GitHub 仓库镜像
   • 或使用 Webhook 触发 GitLab CI

方案 2.2：Jenkins with Shared Agents

实施步骤

1. 安装 Jenkins

   # 使用 Docker 安装
   docker run -d \
     --name jenkins \
     -p 8080:8080 -p 50000:50000 \
     -v jenkins_home:/var/jenkins_home \
     jenkins/jenkins:lts

2. 配置 GitHub 集成

   • 安装 "GitHub Integration Plugin"
   • 配置 GitHub Webhook
   • 设置仓库连接

3. 配置共享 Agent

   // Jenkinsfile
   pipeline {
     agent {
       label 'hardware-test'
     }
     
     options {
       // 限制并发构建
       disableConcurrentBuilds()
     }
     
     stages {
       stage('Hardware Test') {
         steps {
           sh './scripts/hardware-test.sh'
         }
       }
     }
   }

4. 设置 Agent 并发限制

   // Jenkins 系统配置
   // Manage Jenkins > Manage Nodes > hardware-test-agent
   // # of executors: 1

方案 2.3：CircleCI Self-Hosted Runner

实施步骤

1. 安装 CircleCI Self-Hosted Runner

   # 下载 Runner
   curl -o circleci-launcher \
     https://circleci-binary-releases.s3.amazonaws.com/circleci-launcher/linux-amd64/latest/circleci-launcher
   
   chmod +x circleci-launcher
   
   # 配置 Runner
   ./circleci-launcher setup \
     --token YOUR_CIRCLECI_TOKEN \
     --agent circleci-runner

2. 配置并发控制

   # config.yml
   version: 2.1
   
   executors:
     hardware-executor:
       resource_class: axvisor/hardware-test
       machine:
         image: ubuntu-2204:2023.04.2
   
   jobs:
     hardware-test:
       executor: hardware-executor
       parallelism: 1  # 限制并行度
       steps:
         - checkout
         - run: ./scripts/hardware-test.sh

---

方案三：修改自托管 Runner 程序

方案概述

通过修改 GitHub Actions 自托管 Runner 的行为，实现跨组织的任务排队和串行执行。

架构设计

GitHub Actions Runner 是完全开源的，开源地址: https://github.com/actions/runner，许可证: MIT License。

graph TB
    subgraph Orgs["多个 GitHub 组织"]
        direction LR
        OrgA["组织 A"]
        OrgB["组织 B"]
        OrgC["组织 C"]
        OrgN["..."]
    end

    subgraph Wrapper["自定义 Runner 包装层"]
        direction TB
        subgraph LockService["分布式锁服务<br/>(Redis / etcd / 文件锁)"]
            Lock1["Lock: hardware-dev-1<br/>(org-a) [持有中]"]
            Lock2["Lock: hardware-dev-2<br/>(org-b) [等待中]"]
            Lock3["Lock: serial-port-1<br/>(org-c) [等待中]"]
        end
    end

    subgraph Runners["实际 Runner 执行层"]
        direction LR
        Runner1["Runner-1"]
        Runner2["Runner-2"]
        Runner3["Runner-3"]
        RunnerN["..."]
    end

    subgraph Hardware["本地测试环境"]
        direction TB
        HW1["硬件设备 1"]
        HW2["硬件设备 2"]
        HWN["..."]
    end

    OrgA --> Wrapper
    OrgB --> Wrapper
    OrgC --> Wrapper
    OrgN --> Wrapper

    Wrapper --> Runners
    Runners --> Hardware

    style Orgs fill:#e1f5ff
    style Wrapper fill:#fff4e1
    style LockService fill:#ffffff
    style Runners fill:#e1f5ff
    style Hardware fill:#ffe1f5
    style Lock1 fill:#d4edda
    style Lock2 fill:#fff3cd
    style Lock3 fill:#fff3cd

Loading

实施方案 3.1：基于 Redis 的分布式锁

系统架构

# runner-wrapper.py
import redis
import sys
import subprocess
import os
from datetime import datetime, timedelta

class RunnerLockManager:
    def __init__(self, redis_host='localhost', redis_port=6379):
        self.redis_client = redis.StrictRedis(
            host=redis_host, 
            port=redis_port, 
            decode_responses=True
        )
        self.lock_timeout = 3600  # 1小时超时
    
    def acquire_lock(self, resource_id, org_name, repo_name):
        """获取资源锁"""
        lock_key = f"runner:lock:{resource_id}"
        lock_value = f"{org_name}/{repo_name}:{datetime.now().isoformat()}"
        
        # 尝试获取锁，如果锁已被持有则等待
        while True:
            acquired = self.redis_client.set(
                lock_key, 
                lock_value, 
                nx=True, 
                ex=self.lock_timeout
            )
            
            if acquired:
                print(f"✅ Acquired lock for {resource_id}")
                return True
            
            # 锁已被持有，显示等待信息
            current_value = self.redis_client.get(lock_key)
            print(f"⏳ Waiting for lock {resource_id}...")
            print(f"   Currently held by: {current_value}")
            
            # 等待 5 秒后重试
            import time
            time.sleep(5)
    
    def release_lock(self, resource_id):
        """释放资源锁"""
        lock_key = f"runner:lock:{resource_id}"
        self.redis_client.delete(lock_key)
        print(f"🔓 Released lock for {resource_id}")

def main():
    # 从环境变量获取任务信息
    org_name = os.getenv('GITHUB_REPOSITORY_OWNER', 'unknown')
    repo_name = os.getenv('GITHUB_REPOSITORY', 'unknown').split('/')[-1]
    resource_id = os.getenv('RUNNER_RESOURCE_ID', 'default-hardware')
    
    lock_manager = RunnerLockManager()
    
    try:
        # 获取锁
        lock_manager.acquire_lock(resource_id, org_name, repo_name)
        
        # 执行实际的 Runner 任务
        print(f"🚀 Starting task for {org_name}/{repo_name}")
        result = subprocess.run(
            ['./run.sh'],  # GitHub Runner 的实际执行脚本
            capture_output=True,
            text=True
        )
        
        print(result.stdout)
        if result.stderr:
            print(result.stderr, file=sys.stderr)
        
        return result.returncode
        
    finally:
        # 释放锁
        lock_manager.release_lock(resource_id)

if __name__ == '__main__':
    sys.exit(main())

部署步骤

1. 安装 Redis

   # Ubuntu/Debian
   sudo apt-get update
   sudo apt-get install redis-server
   
   # 启动 Redis
   sudo systemctl start redis
   sudo systemctl enable redis

2. 修改 Runner 启动脚本

   # 原始启动方式
   ./run.sh
   
   # 修改为使用包装脚本
   python3 runner-wrapper.py

3. 配置 Docker Compose

   version: '3.8'
   
   services:
     redis:
       image: redis:7-alpine
       container_name: runner-lock-redis
       restart: unless-stopped
       ports:
         - "6379:6379"
       volumes:
         - redis-data:/data
   
     github-runner:
       image: ghcr.io/actions/actions-runner:latest
       container_name: github-runner-wrapper
       restart: unless-stopped
       environment:
         - REPO_URL=${REPO_URL}
         - RUNNER_TOKEN=${RUNNER_TOKEN}
         - RUNNER_NAME=${RUNNER_NAME}
         - RUNNER_RESOURCE_ID=${RUNNER_RESOURCE_ID:-hardware-test-1}
       volumes:
         - ./runner-wrapper.py:/home/runner/runner-wrapper.py
         - /var/run/docker.sock:/var/run/docker.sock
       depends_on:
         - redis
       command: python3 /home/runner/runner-wrapper.py
   
   volumes:
     redis-data:

4. 配置多个 Runner

   # 为不同组织注册多个 Runner，但使用相同的资源 ID
   export RUNNER_RESOURCE_ID=hardware-test-1
   
   # 组织 A 的 Runner
   export REPO_URL=https://github.com/org-a/repo
   export RUNNER_TOKEN=TOKEN_A
   export RUNNER_NAME=runner-org-a
   docker-compose up -d
   
   # 组织 B 的 Runner
   export REPO_URL=https://github.com/org-b/repo
   export RUNNER_TOKEN=TOKEN_B
   export RUNNER_NAME=runner-org-b
   docker-compose up -d

实施方案 3.2：基于文件锁的简单方案

系统架构

#!/bin/bash
# runner-wrapper.sh

LOCK_DIR="/tmp/github-runner-locks"
RESOURCE_ID="${RUNNER_RESOURCE_ID:-default-hardware}"
LOCK_FILE="${LOCK_DIR}/${RESOURCE_ID}.lock"
ORG_NAME="${GITHUB_REPOSITORY_OWNER:-unknown}"
REPO_NAME="${GITHUB_REPOSITORY##*/}"

# 创建锁目录
mkdir -p "${LOCK_DIR}"

# 清理函数
cleanup() {
    echo "🔓 Releasing lock for ${RESOURCE_ID}"
    flock -u 200
    rm -f "${LOCK_FILE}"
    exit
}

# 设置信号处理
trap cleanup EXIT INT TERM

# 获取文件锁
echo "⏳ Waiting for lock ${RESOURCE_ID}..."
echo "   Requested by: ${ORG_NAME}/${REPO_NAME}"

exec 200>"${LOCK_FILE}"
flock -x 200

echo "✅ Acquired lock for ${RESOURCE_ID}"
echo "   Owner: ${ORG_NAME}/${REPO_NAME}"
echo "   Started at: $(date)"

# 执行实际的 Runner 任务
./run.sh

echo "✅ Task completed at: $(date)"

部署步骤

1. 创建包装脚本

   # 保存为 runner-wrapper.sh
   chmod +x runner-wrapper.sh

2. 修改 Runner 服务

   # 修改服务配置
   sudo vim /etc/systemd/system/github-runner.service
   
   # 修改 ExecStart
   ExecStart=/home/runner/runner-wrapper.sh

3. 重启服务

   sudo systemctl daemon-reload
   sudo systemctl restart github-runner

实施方案 3.3：基于 etcd 的分布式锁

系统架构

// main.go
package main

import (
	"context"
	"fmt"
	"log"
	"os"
	"os/exec"
	"time"

	"go.etcd.io/etcd/client/v3/concurrency"
	clientv3 "go.etcd.io/etcd/client/v3"
)

type LockManager struct {
	client *clientv3.Client
}

func NewLockManager(endpoints []string) (*LockManager, error) {
	cli, err := clientv3.New(clientv3.Config{
		Endpoints:   endpoints,
		DialTimeout: 5 * time.Second,
	})
	if err != nil {
		return nil, err
	}
	return &LockManager{client: cli}, nil
}

func (lm *LockManager) RunWithLock(ctx context.Context, resourceID string, task func() error) error {
	session, err := concurrency.NewSession(lm.client, concurrency.WithTTL(60))
	if err != nil {
		return fmt.Errorf("failed to create session: %w", err)
	}
	defer session.Close()

	mutex := concurrency.NewMutex(session, "/github-runners/locks/"+resourceID)

	org := os.Getenv("GITHUB_REPOSITORY_OWNER")
	repo := os.Getenv("GITHUB_REPOSITORY")

	log.Printf("⏳ [%s/%s] Waiting for lock: %s", org, repo, resourceID)

	if err := mutex.Lock(ctx); err != nil {
		return fmt.Errorf("failed to acquire lock: %w", err)
	}

	log.Printf("✅ [%s/%s] Acquired lock: %s", org, repo, resourceID)
	defer func() {
		mutex.Unlock(ctx)
		log.Printf("🔓 [%s/%s] Released lock: %s", org, repo, resourceID)
	}()

	return task()
}

func main() {
	endpoints := []string{"http://localhost:2379"}
	lm, err := NewLockManager(endpoints)
	if err != nil {
		log.Fatalf("Failed to create lock manager: %v", err)
	}
	defer lm.client.Close()

	resourceID := os.Getenv("RUNNER_RESOURCE_ID")
	if resourceID == "" {
		resourceID = "default-hardware"
	}

	ctx, cancel := context.WithTimeout(context.Background(), 2*time.Hour)
	defer cancel()

	task := func() error {
		cmd := exec.Command("./run.sh")
		cmd.Stdout = os.Stdout
		cmd.Stderr = os.Stderr
		return cmd.Run()
	}

	if err := lm.RunWithLock(ctx, resourceID, task); err != nil {
		log.Fatalf("Task failed: %v", err)
	}
}

部署步骤

1. 安装 etcd

   # 使用 Docker 安装 etcd
   docker run -d \
     --name etcd \
     -p 2379:2379 \
     -p 2380:2380 \
     -e ETCD_NAME=etcd0 \
     -e ETCD_INITIAL_ADVERTISE_PEER_URLS=http://localhost:2380 \
     -e ETCD_LISTEN_PEER_URLS=http://0.0.0.0:2380 \
     -e ETCD_LISTEN_CLIENT_URLS=http://0.0.0.0:2379 \
     -e ETCD_ADVERTISE_CLIENT_URLS=http://localhost:2379 \
     -e ETCD_INITIAL_CLUSTER=etcd0=http://localhost:2380 \
     -e ETCD_INITIAL_CLUSTER_STATE=new \
     -e ETCD_INITIAL_CLUSTER_TOKEN=etcd-cluster \
     bitnami/etcd:latest

2. 编译包装程序

   go mod init runner-wrapper
   go get go.etcd.io/etcd/client/v3
   go build -o runner-wrapper main.go

3. 配置 Runner

   version: '3.8'
   
   services:
     etcd:
       image: bitnami/etcd:latest
       container_name: runner-etcd
       restart: unless-stopped
       environment:
         - ALLOW_NONE_AUTHENTICATION=yes
         - ETCD_ADVERTISE_CLIENT_URLS=http://localhost:2379
       ports:
         - "2379:2379"
   
     github-runner:
       image: ghcr.io/actions/actions-runner:latest
       container_name: github-runner-etcd
       restart: unless-stopped
       environment:
         - REPO_URL=${REPO_URL}
         - RUNNER_TOKEN=${RUNNER_TOKEN}
         - RUNNER_NAME=${RUNNER_NAME}
         - RUNNER_RESOURCE_ID=${RUNNER_RESOURCE_ID:-hardware-test-1}
         - GITHUB_REPOSITORY_OWNER=${GITHUB_REPOSITORY_OWNER}
         - GITHUB_REPOSITORY=${GITHUB_REPOSITORY}
       volumes:
         - ./runner-wrapper:/home/runner/runner-wrapper
         - /var/run/docker.sock:/var/run/docker.sock
       depends_on:
         - etcd
       command: /home/runner/runner-wrapper

---

方案四：为每个组织部署一套独立测试环境

如题

附录

A. 相关文档

• GitHub Actions Self-hosted Runner 官方文档
• GitLab CI/CD 官方文档
• Jenkins 官方文档
• Redis 官方文档
• etcd 官方文档

B. 示例代码仓库

• github-runners - Runner 管理脚本
• axvisor - 主项目仓库