# Gitea Actions 配置说明

本目录为本项目的 Gitea CI/CD 工作流。运行环境为 **self-hosted Linux runner**，且 runner 必须能在目标主机上以 root 身份执行 eBPF/bcc。

## 工作流

- [`workflows/ci.yml`](workflows/ci.yml) — push / PR 到 `main` 触发。语法检查 + 干净 venv 安装依赖。**不**需要 root。
- [`workflows/cd.yml`](workflows/cd.yml) — 推送 `v*` tag 或手动触发。流程：
  1. `stop.sh` 停掉旧实例（若存在）
  2. `rsync --delete` 当前 checkout 到固定目录 `/opt/syscall_monitor`，排除 `.git` / `.venv` / `.venv-ci` / `logs` / `.pid`，并 `chmod +x` 三个部署脚本
  3. `setup.sh` 装 venv 依赖
  4. `run.sh` 启动
  5. `sleep 5` 后校验 `.pid` 进程存活，最多重试 3 次（每次间隔 2 秒）
  6. 重试 10 次 `curl http://127.0.0.1:5000` 做健康检查（每次间隔 2 秒）
  7. `tail` 启动日志（无论成功失败都执行）

  **需要 root**。部署目录和健康检查 URL 在 workflow 顶部 `env:` 块里改。

## Runner 准备

1. 在目标 Linux 主机上注册 act_runner，labels 至少包含 `self-hosted`。
2. 安装系统依赖：

   ```bash
   sudo apt install -y python3-venv python3-bpfcc bpfcc-tools rsync curl linux-headers-$(uname -r)
   ```

3. 创建固定部署目录（脚本以 root 运行，目录所有权保持 root）：

   ```bash
   sudo mkdir -p /opt/syscall_monitor
   ```

4. 给 runner 用户配置免密 sudo。写 `/etc/sudoers.d/syscall-monitor`（用 `sudo visudo -f` 编辑，文件权限 `0440`）：

   ```
   gitea-runner ALL=(root) NOPASSWD: ALL
   ```

   - 用户名以实际 runner 进程身份为准（`id -un` 查看），不一定是 `gitea-runner`。
   - `rsync` 实际路径以 `which rsync` 为准（一般是 `/usr/bin/rsync`）。

## 触发方式

- 日常 push / PR → 自动跑 CI。
- 发版部署 → 打 tag → 自动跑 CD：

  ```bash
  git tag v0.1.0 && git push origin v0.1.0
  ```

  也可在 Gitea Actions 页面用 `workflow_dispatch` 手动触发（无需打 tag）。

## 注意

- 部署目录固定为 `/opt/syscall_monitor`。每次 CD 用 `rsync --delete` 全量同步代码，但排除 `.venv` / `.venv-ci` / `logs` / `.pid` / `.git`，所以 venv 不会每次重建，依赖增量装。
- 健康检查 URL 由 `HEALTH_URL` 控制，默认 `http://127.0.0.1:5000`，重试 10 次每次间隔 2 秒。
- `run.sh` 是 `nohup` 后台启动，runner 当前 workspace 跟部署目录是分开的——`.pid` 落在 `/opt/syscall_monitor/.pid`，CD 校验的就是这个。
- 失败时 CD 会 `tail` `/opt/syscall_monitor/logs/app.log` 末尾若干行到 stderr，便于在 Actions 页面直接看启动日志。