657 lines
17 KiB
Markdown
657 lines
17 KiB
Markdown
# Session: 2026-03-08 15:02:18 UTC
|
||
|
||
- **Session Key**: agent:thinker:main
|
||
- **Session ID**: b3e88073-2c5f-4e4f-b922-5678042fc955
|
||
- **Source**: feishu
|
||
|
||
## Conversation Summary
|
||
|
||
user: System: [2026-03-01 22:58:02 GMT+8] Feishu[feishu-qa] DM from ou_a0f6627b64d2dc8b0236671603d1e47b: 查看一下~/work/kb-web，重点是ci.yml，看看这个开发测试的ci流程是否有问题
|
||
|
||
[Feishu ou_a0f6627b64d2dc8b0236671603d1e47b Sun 2026-03-01 22:58 GMT+8] 张青: 查看一下~/work/kb-web，重点是ci.yml，看看这个开发测试的ci流程是否有问题
|
||
[message_id: om_x100b5571715160a0c26c18433229dc1]
|
||
assistant: 我来审查一下这个项目的 CI 流程。
|
||
assistant: ## 🔍 CI 流程审查报告
|
||
|
||
### 🚨 **严重问题**
|
||
|
||
#### 1. **测试失败被静默忽略** - 最严重！
|
||
|
||
```yaml
|
||
- name: 运行测试
|
||
run: |
|
||
if composer test 2>/dev/null; then
|
||
echo "✅ 测试通过"
|
||
else
|
||
echo "⚠️ 测试未配置"
|
||
fi
|
||
```
|
||
|
||
**问题分析：**
|
||
- `2>/dev/null` 隐藏了所有错误输出，你看不到测试失败的真实原因
|
||
- `composer test` 失败时只打印警告，**不会导致 job 失败**
|
||
- 这意味着：**即使所有测试都失败，CI 也会显示通过** ✅
|
||
|
||
**这完全违背了 CI 的核心目的！**
|
||
|
||
**修复建议：**
|
||
```yaml
|
||
- name: 运行测试
|
||
run: composer test
|
||
```
|
||
|
||
简单直接，让测试失败直接导致 CI 失败。
|
||
|
||
---
|
||
|
||
### ⚠️ **中等问题**
|
||
|
||
#### 2. **缺少依赖缓存**
|
||
|
||
每次运行都执行 `composer install`，没有缓存 `vendor/` 目录，浪费时间。
|
||
|
||
**建议添加：**
|
||
```yaml
|
||
- name: 缓存 Composer 依赖
|
||
uses: actions/cache@v4
|
||
with:
|
||
path: vendor
|
||
key: ${{ runner.os }}-composer-${{ hashFiles('**/composer.lock') }}
|
||
```
|
||
|
||
#### 3. **重复代码**
|
||
|
||
`lint` 和 `test` 两个 job 都有相同的检出和安装依赖步骤，考虑：
|
||
- 使用缓存共享 vendor 目录
|
||
- 或用 `actions/cache` 加速
|
||
|
||
#### 4. **ci-status job 冗余**
|
||
|
||
```yaml
|
||
ci-status:
|
||
needs: [lint, test]
|
||
if: always()
|
||
```
|
||
|
||
这个 job 的作用只是打印状态，实际上可以直接让 `test` job 失败就停止流程，不需要额外状态检查。
|
||
|
||
---
|
||
|
||
### 💡 **轻微问题**
|
||
|
||
#### 5. **手动 git clone 而非标准 action**
|
||
|
||
```yaml
|
||
run: |
|
||
git clone -b ${{ github.ref_name }} ${{ github.server_url }}/${{ github.repository }}.git .
|
||
git checkout ${{ github.sha }}
|
||
```
|
||
|
||
虽然 Gitea Actions 可能不支持 `actions/checkout`，但这种手动方式：
|
||
- 没有处理浅克隆优化
|
||
- 没有处理子模块（如果有）
|
||
|
||
#### 6. **phpunit.xml 配置范围过大**
|
||
|
||
```xml
|
||
<directory suffix=".php">.</directory>
|
||
```
|
||
|
||
这会把根目录所有 PHP 文件都纳入覆盖率分析，包括非业务代码（如 `add_user.php`, `logout.php` 等），建议只包含 `src/` 目录。
|
||
|
||
---
|
||
|
||
### ✅ **做得好的地方**
|
||
|
||
- 触发条件设置合理（push + PR 到 main/develop）
|
||
- job 依赖关系正确（test needs lint）
|
||
- PHP 语法检查逻辑完整
|
||
|
||
---
|
||
|
||
### 📋 **修复优先级**
|
||
|
||
| 优先级 | 问题 | 影响 |
|
||
|--------|------|------|
|
||
| **P0** | 测试失败被忽略 | CI 形同虚设 |
|
||
| P1 | 添加依赖缓存 | 效率问题 |
|
||
| P2 | 简化 ci-status | 代码冗余 |
|
||
|
||
需要我帮你修复这个 ci.yml 吗？
|
||
user: System: [2026-03-02 01:08:18 GMT+8] Feishu[feishu-qa] DM from ou_a0f6627b64d2dc8b0236671603d1e47b: 再次检查ci.yml的逻辑有没有问题
|
||
|
||
[Feishu ou_a0f6627b64d2dc8b0236671603d1e47b Mon 2026-03-02 01:08 GMT+8] 张青: 再次检查ci.yml的逻辑有没有问题
|
||
[message_id: om_x100b557366d334a0c3e38d36ed22a56]
|
||
assistant: 发现一个**隐蔽但严重**的问题。让我验证一下：
|
||
assistant: ## 🔍 再次审查 - 发现新的严重问题
|
||
|
||
### 🚨 **严重问题**
|
||
|
||
#### **PHP 语法检查形同虚设！**
|
||
|
||
```yaml
|
||
- name: PHP 语法检查
|
||
run: |
|
||
find . -name "*.php" -not -path "./vendor/*" -exec php -l {} \;
|
||
```
|
||
|
||
**问题分析：**
|
||
|
||
`find -exec` 命令的退出码只反映 **find 自身**是否成功执行，**不会传递被执行命令的失败状态**。
|
||
|
||
刚才的测试证明了这点：即使 `php -l` 执行失败（甚至找不到 php 命令），find 仍然返回 `Exit code: 0`。
|
||
|
||
**这意味着：即使有 PHP 语法错误，这个检查步骤也会显示通过 ✅**
|
||
|
||
**修复方案：**
|
||
|
||
```yaml
|
||
- name: PHP 语法检查
|
||
run: |
|
||
errors=0
|
||
for file in $(find . -name "*.php" -not -path "./vendor/*"); do
|
||
if ! php -l "$file" > /dev/null 2>&1; then
|
||
echo "❌ 语法错误: $file"
|
||
php -l "$file"
|
||
errors=$((errors + 1))
|
||
fi
|
||
done
|
||
if [ $errors -gt 0 ]; then
|
||
echo "发现 $errors 个语法错误"
|
||
exit 1
|
||
fi
|
||
echo "✅ 所有 PHP 文件语法正确"
|
||
```
|
||
|
||
---
|
||
|
||
### ⚠️ **中等问题**
|
||
|
||
#### **触发条件语义混乱**
|
||
|
||
```yaml
|
||
on:
|
||
push:
|
||
branches: [main, develop, "**"] # 所有分支
|
||
pull_request:
|
||
branches: [main, develop, "**"] # 所有分支
|
||
```
|
||
|
||
- `"**"` 已经匹配所有分支了，再列出 `main, develop` 是冗余的
|
||
- `pull_request.branches` 指的是**目标分支**（被合并到的分支），写 `"**"` 意味着"任何分支的 PR"都会触发
|
||
|
||
**建议简化为：**
|
||
```yaml
|
||
on:
|
||
push:
|
||
branches: ["**"]
|
||
pull_request:
|
||
branches: [main, develop] # 只针对合并到 main/develop 的 PR 触发
|
||
```
|
||
|
||
---
|
||
|
||
### ✅ **已修复的问题**（对比之前）
|
||
|
||
| 之前的问题 | 当前状态 |
|
||
|-----------|---------|
|
||
| `composer test` 失败被忽略 | ✅ 已修复，直接运行 |
|
||
| 手动 git clone | ✅ 已改用 `actions/checkout@v4` |
|
||
| ci-status 冗余 job | ✅ 已移除 |
|
||
|
||
---
|
||
|
||
### 📋 **当前问题优先级**
|
||
|
||
| 优先级 | 问题 | 影响 |
|
||
|--------|------|------|
|
||
| **P0** | `find -exec` 不传递退出码 | 语法检查完全失效 |
|
||
| P2 | 触发条件冗余 | 代码不清晰 |
|
||
|
||
需要我帮你修复语法检查的问题吗？
|
||
user: System: [2026-03-02 01:37:27 GMT+8] Feishu[feishu-qa] DM from ou_a0f6627b64d2dc8b0236671603d1e47b: 审查一下~/work/knowledge-base/archive下的ci流程有没有什么问题
|
||
|
||
[Feishu ou_a0f6627b64d2dc8b0236671603d1e47b Mon 2026-03-02 01:37 GMT+8] 张青: 审查一下~/work/knowledge-base/archive下的ci流程有没有什么问题
|
||
[message_id: om_x100b5573dba6ad34c2ed44725f7d367]
|
||
assistant: ## 🔍 CI/CD 流程审查报告
|
||
|
||
### 项目信息
|
||
- **路径**: `~/work/knowledge-base/archive`
|
||
- **配置**: 只有 `deploy.yml`，没有独立的 CI 流程
|
||
|
||
---
|
||
|
||
### 🚨 **严重问题**
|
||
|
||
#### 1. **部署源与触发源不一致** - 最严重的逻辑漏洞！
|
||
|
||
```yaml
|
||
# 触发条件：archive 仓库的 main 分支 push
|
||
on:
|
||
push:
|
||
branches: [main]
|
||
|
||
# 但实际部署的是：knowledge-base 仓库
|
||
- name: Checkout code
|
||
run: |
|
||
git clone sc-gitea@192.168.1.22:starmen1265/knowledge-base.git /tmp/workspace
|
||
```
|
||
|
||
**问题分析：**
|
||
- 当你推送 `archive` 仓库时，会触发部署
|
||
- 但部署的是 `knowledge-base` 仓库的代码
|
||
- **这两个仓库是不同的！** 这会导致：
|
||
- archive 仓库的修改不会触发正确的部署
|
||
- knowledge-base 仓库的修改不会自动部署（因为没在这个仓库配置 workflow）
|
||
|
||
**这完全是错误的配置！**
|
||
|
||
---
|
||
|
||
#### 2. **SSH 私钥写入文件系统** - 安全风险
|
||
|
||
```yaml
|
||
- name: Setup SSH key for git
|
||
run: |
|
||
echo "$DEPLOY_KEY" > ~/.ssh/id_rsa
|
||
```
|
||
|
||
**风险：**
|
||
- 私钥明文写入磁盘，可能被日志或意外泄露
|
||
- 如果 runner 被入侵，私钥可被窃取
|
||
|
||
**修复方案：** 使用 SSH agent
|
||
```yaml
|
||
- name: Setup SSH
|
||
uses: webfactory/ssh-agent@v0.8.0
|
||
with:
|
||
ssh-private-key: ${{ secrets.DEPLOY_KEY }}
|
||
```
|
||
|
||
---
|
||
|
||
#### 3. **rsync --delete 在错误的源上运行**
|
||
|
||
```yaml
|
||
rsync -avz --delete \
|
||
./ root@micecola.top:/www/wwwroot/kb-web-test/zhangqing/
|
||
```
|
||
|
||
**问题：**
|
||
- 当前目录 `./` 是 runner 的工作目录（archive 仓库），而不是克隆的 `/tmp/workspace`
|
||
- 应该 `cd /tmp/workspace && rsync ... ./ ...`
|
||
|
||
但更根本的问题是：**为什么要在 archive 仓库触发 knowledge-base 的部署？**
|
||
|
||
---
|
||
|
||
### ⚠️ **中等问题**
|
||
|
||
#### 4. **使用 root 用户部署**
|
||
|
||
```yaml
|
||
ssh root@micecola.top
|
||
rsync ... root@micecola.top:...
|
||
```
|
||
|
||
**风险：** root 权限过大，一旦密钥泄露或部署出错，后果严重。
|
||
|
||
**建议：** 创建专用的部署用户（如 `deploy` 或 `kb_admin`）
|
||
|
||
---
|
||
|
||
#### 5. **禁用 SSH 主机密钥验证**
|
||
|
||
```yaml
|
||
ssh-keyscan ... >> ~/.ssh/known_hosts 2>/dev/null
|
||
ssh -o StrictHostKeyChecking=no ...
|
||
```
|
||
|
||
`StrictHostKeyChecking=no` 可能导致中间人攻击，虽然有 ssh-keyscan 预先添加，但混合使用容易混淆。
|
||
|
||
---
|
||
|
||
#### 6. **缺少 CI 步骤**
|
||
|
||
这个 workflow 只有部署，没有：
|
||
- 代码检查
|
||
- 单元测试
|
||
- 构建验证
|
||
|
||
直接部署未经测试的代码到生产环境风险很高。
|
||
|
||
---
|
||
|
||
### 💡 **轻微问题**
|
||
|
||
#### 7. **备份文件未清理**
|
||
|
||
```
|
||
deploy.yml.bak
|
||
```
|
||
|
||
备份文件不应该提交到 git。
|
||
|
||
---
|
||
|
||
### 📋 **问题汇总**
|
||
|
||
| 优先级 | 问题 | 影响 |
|
||
|--------|------|------|
|
||
| **P0** | 部署源与触发源不一致 | 部署逻辑完全错误 |
|
||
| **P0** | SSH 私钥写入文件系统 | 安全漏洞 |
|
||
| **P1** | rsync 源目录错误 | 部署内容错误 |
|
||
| **P1** | 使用 root 部署 | 权限过大 |
|
||
| **P2** | 缺少 CI 测试步骤 | 质量保障缺失 |
|
||
|
||
---
|
||
|
||
### ✅ **建议方案**
|
||
|
||
这个 deploy.yml 应该移到 `knowledge-base` 仓库中，并添加 CI 测试步骤：
|
||
|
||
```yaml
|
||
name: CI/CD
|
||
|
||
on:
|
||
push:
|
||
branches: [main]
|
||
|
||
jobs:
|
||
test:
|
||
runs-on: [linux, amd64]
|
||
steps:
|
||
- uses: actions/checkout@v4
|
||
- name: Run tests
|
||
run: # 你的测试命令
|
||
|
||
deploy:
|
||
needs: test
|
||
runs-on: [linux, amd64]
|
||
steps:
|
||
- uses: actions/checkout@v4
|
||
- uses: webfactory/ssh-agent@v0.8.0
|
||
with:
|
||
ssh-private-key: ${{ secrets.DEPLOY_KEY }}
|
||
- name: Deploy
|
||
run: |
|
||
rsync -avz --delete \
|
||
--exclude='.git' \
|
||
./ deploy@micecola.top:/www/wwwroot/kb-web-test/zhangqing/
|
||
```
|
||
|
||
需要我帮你修复这些问题吗？
|
||
user: System: [2026-03-02 01:45:20 GMT+8] Feishu[feishu-qa] DM from ou_a0f6627b64d2dc8b0236671603d1e47b: 本地的archive目录实际上关联的就是这个knowledge-base仓库。带着这个前提再审查一次。
|
||
|
||
[Feishu ou_a0f6627b64d2dc8b0236671603d1e47b Mon 2026-03-02 01:45 GMT+8] 张青: 本地的archive目录实际上关联的就是这个knowledge-base仓库。带着这个前提再审查一次。
|
||
[message_id: om_x100b5573fc320ca0c32face404020c4]
|
||
assistant: 明白了，archive 就是 knowledge-base 仓库。重新审查：
|
||
assistant: ## 🔍 重新审查 - 修正后的分析
|
||
|
||
### 理解前提
|
||
- archive 目录 = knowledge-base 仓库的本地克隆
|
||
- 触发流程：push → Gitea runner → 克隆仓库 → rsync 部署
|
||
|
||
---
|
||
|
||
### 🚨 **严重问题**
|
||
|
||
#### 1. **SSH 私钥明文写入文件** - 安全风险
|
||
|
||
```yaml
|
||
echo "$DEPLOY_KEY" > ~/.ssh/id_rsa
|
||
```
|
||
|
||
私钥写入磁盘，可能通过日志、进程列表、意外泄露。
|
||
|
||
**修复方案：** 使用 SSH agent 或 `webfactory/ssh-agent` action。
|
||
|
||
---
|
||
|
||
### ⚠️ **中等问题**
|
||
|
||
#### 2. **冗余的 git checkout**
|
||
|
||
```yaml
|
||
git clone ... /tmp/workspace
|
||
cd /tmp/workspace
|
||
git checkout main # ← 多余！git clone 默认就是 main 分支
|
||
```
|
||
|
||
#### 3. **使用 root 用户部署**
|
||
|
||
```yaml
|
||
ssh root@micecola.top
|
||
rsync ... root@micecola.top:...
|
||
```
|
||
|
||
权限过大，建议使用专用部署账户（如之前的 `kb_admin`）。
|
||
|
||
---
|
||
|
||
### 💡 **轻微问题 / 建议改进**
|
||
|
||
#### 4. **缺少 CI 测试步骤**
|
||
|
||
只有部署没有测试，建议添加：
|
||
|
||
```yaml
|
||
jobs:
|
||
test:
|
||
runs-on: [linux, amd64]
|
||
steps:
|
||
- uses: actions/checkout@v4
|
||
- name: Run tests
|
||
run: # 测试命令
|
||
|
||
deploy:
|
||
needs: test # 测试通过后才部署
|
||
...
|
||
```
|
||
|
||
#### 5. **可以简化克隆步骤**
|
||
|
||
当前手动克隆到 `/tmp/workspace`，可以改用标准 action：
|
||
|
||
```yaml
|
||
- uses: actions/checkout@v4
|
||
```
|
||
|
||
如果需要 SSH 克隆，可以配置：
|
||
|
||
```yaml
|
||
- uses: actions/checkout@v4
|
||
with:
|
||
ssh-key: ${{ secrets.DEPLOY_KEY }}
|
||
```
|
||
|
||
#### 6. **rsync exclude 可以更完整**
|
||
|
||
```yaml
|
||
--exclude='.git' \
|
||
--exclude='.gitea' \
|
||
```
|
||
|
||
建议添加：
|
||
```yaml
|
||
--exclude='*.log' \
|
||
--exclude='.env' \
|
||
--exclude='node_modules' \
|
||
```
|
||
|
||
---
|
||
|
||
### 📋 **问题汇总（修正后）**
|
||
|
||
| 优先级 | 问题 | 影响 |
|
||
|--------|------|------|
|
||
| **P0** | SSH 私钥写入文件 | 安全漏洞 |
|
||
| **P1** | 使用 root 部署 | 权限过大 |
|
||
| **P1** | 缺少 CI 测试 | 质量保障缺失 |
|
||
| P2 | 冗余 git checkout | 代码冗余 |
|
||
| P3 | 可简化为 actions/checkout | 可维护性 |
|
||
|
||
---
|
||
|
||
### ✅ **整体评价**
|
||
|
||
流程逻辑是正确的（触发 → 克隆 → 部署），主要问题集中在**安全性**和**缺少测试环节**。核心部署逻辑没有问题。
|
||
|
||
需要我帮你优化这个配置吗？
|
||
user: System: [2026-03-02 01:48:40 GMT+8] Feishu[feishu-qa] DM from ou_a0f6627b64d2dc8b0236671603d1e47b: 另外，一个标准的gitea工作流网站部署步骤应该如何操作，由runner拉取之后在通过ssh推送到目标机器的指定位置吗？
|
||
|
||
[Feishu ou_a0f6627b64d2dc8b0236671603d1e47b Mon 2026-03-02 01:48 GMT+8] 张青: 另外，一个标准的gitea工作流网站部署步骤应该如何操作，由runner拉取之后在通过ssh推送到目标机器的指定位置吗？
|
||
[message_id: om_x100b5573f1b680a0c3ba3a5352ba389]
|
||
assistant: ## 标准的 Gitea Actions 网站部署流程
|
||
|
||
你理解的基本思路是对的：**Runner 拉取代码 → 构建/测试 → SSH 推送到目标服务器**。但有一些细节需要优化。
|
||
|
||
---
|
||
|
||
### 📋 推荐的标准流程
|
||
|
||
```yaml
|
||
name: CI/CD
|
||
|
||
on:
|
||
push:
|
||
branches: [main]
|
||
|
||
jobs:
|
||
# 1. 测试阶段
|
||
test:
|
||
runs-on: [linux, amd64]
|
||
steps:
|
||
- uses: actions/checkout@v4
|
||
|
||
- name: Install dependencies
|
||
run: composer install --prefer-dist --no-progress
|
||
|
||
- name: Run tests
|
||
run: composer test
|
||
|
||
# 2. 部署阶段
|
||
deploy:
|
||
runs-on: [linux, amd64]
|
||
needs: test # 测试通过才部署
|
||
steps:
|
||
- uses: actions/checkout@v4
|
||
|
||
# 使用 SSH agent（更安全）
|
||
- uses: webfactory/ssh-agent@v0.8.0
|
||
with:
|
||
ssh-private-key: ${{ secrets.DEPLOY_KEY }}
|
||
|
||
# 添加目标服务器到 known_hosts
|
||
- name: Setup known hosts
|
||
run: |
|
||
mkdir -p ~/.ssh
|
||
ssh-keyscan -H micecola.top >> ~/.ssh/known_hosts
|
||
|
||
# rsync 同步
|
||
- name: Deploy to server
|
||
run: |
|
||
rsync -avz --delete \
|
||
--exclude='.git' \
|
||
--exclude='.gitea' \
|
||
--exclude='.env' \
|
||
./ deploy@micecola.top:/www/wwwroot/kb-web-test/zhangqing/
|
||
```
|
||
|
||
---
|
||
|
||
### 🔑 关键点说明
|
||
|
||
#### 1. **SSH 密钥管理**
|
||
|
||
| 方式 | 安全性 | 推荐 |
|
||
|------|--------|------|
|
||
| `echo "$KEY" > id_rsa` | ❌ 写入文件，易泄露 | 不推荐 |
|
||
| `webfactory/ssh-agent` | ✅ 内存中，不写磁盘 | 推荐 |
|
||
| Runner 预装密钥 | ⚠️ 依赖 runner 环境 | 可用但不灵活 |
|
||
|
||
#### 2. **部署用户**
|
||
|
||
| 用户 | 风险 | 推荐 |
|
||
|------|------|------|
|
||
| `root` | ❌ 权限过大 | 不推荐 |
|
||
| 专用用户（如 `deploy`） | ✅ 最小权限 | 推荐 |
|
||
|
||
创建部署用户：
|
||
```bash
|
||
# 在目标服务器上
|
||
useradd -m deploy
|
||
mkdir -p /www/wwwroot/kb-web-test/zhangqing
|
||
chown -R deploy:deploy /www/wwwroot/kb-web-test/zhangqing
|
||
```
|
||
|
||
#### 3. **rsync vs 其他方案**
|
||
|
||
| 方案 | 优点 | 缺点 |
|
||
|------|------|------|
|
||
| **rsync** | 增量同步、快速 | 需要配置 SSH |
|
||
| scp | 简单 | 每次全量覆盖 |
|
||
| ssh + tar | 灵活 | 命令复杂 |
|
||
| Docker | 标准化 | 需要容器环境 |
|
||
|
||
**rsync 是最常用的方案**，参数解释：
|
||
|
||
```bash
|
||
rsync -avz --delete \
|
||
--exclude='.git' \ # 排除 git 目录
|
||
--exclude='.env' \ # 排除环境配置（服务器有自己的）
|
||
--exclude='*.log' \ # 排除日志文件
|
||
./ user@host:/path/ # 源 → 目标
|
||
```
|
||
|
||
- `-a`: 归档模式（保留权限、时间戳等）
|
||
- `-v`: 显示详情
|
||
- `-z`: 压缩传输
|
||
- `--delete`: 删除目标中源没有的文件（保持同步）
|
||
|
||
---
|
||
|
||
### 🔄 两种常见的部署架构
|
||
|
||
#### 架构 A：Runner Push（你当前的方式）
|
||
|
||
```
|
||
Gitea → Runner 拉取代码 → Runner 通过 SSH/rsync 推送到目标服务器
|
||
```
|
||
|
||
**优点：** 简单，目标服务器不需要安装额外软件
|
||
**缺点：** Runner 需要有目标服务器的 SSH 访问权限
|
||
|
||
#### 架构 B：目标服务器 Pull
|
||
|
||
```
|
||
Gitea → Runner 通知 → 目标服务器主动拉取代码
|
||
```
|
||
|
||
```yaml
|
||
- name: Trigger pull on server
|
||
run: |
|
||
ssh deploy@micecola.top "cd /www/wwwroot/kb-web-test && git pull"
|
||
```
|
||
|
||
**优点：** 目标服务器控制拉取时机，可以做本地构建
|
||
**缺点：** 目标服务器需要 git 环境
|
||
|
||
---
|
||
|
||
### ✅ 你的场景推荐
|
||
|
||
对于 PHP 静态网站，**架构 A（Runner Push）+ rsync** 是最合适的：
|
||
|
||
```yaml
|
||
- uses: actions/checkout@v4
|
||
- uses: webfactory/ssh-agent@v0.8.0
|
||
with:
|
||
ssh-private-key: ${{ secrets.DEPLOY_KEY }}
|
||
- run: rsync -avz --delete ./ deploy@micecola.top:/path/
|
||
```
|
||
|
||
简单、高效、安全。
|
||
|
||
需要我帮你按这个标准优化现有的 deploy.yml 吗？
|