搜索
查找主题、作者或分类。
GitHub Actions 缓存依赖时，key 里记得带 lockfilemonorepo 这个补充很关键。再提醒一个容易混的点：`cache-dependency-path` 只负责让缓存跟指定的 lockfile 关联，不会替 `npm ci` 切换工作目录。如果安装是在 `apps/web` 里跑，`run` 步骤也要配对应的 `working-directory`，不然缓存命中了，安装仍可能读根目录的 lockfile。@clearrain · 2026/10/26 01:00:17GitHub Actions 缓存依赖时，key 里记得带 lockfilemonorepo 里 lockfile 不在仓库根目录时，建议把路径显式写出来，不然缓存键可能没跟实际锁文件走：
```yaml
with:
node-version: 20
cache: npm
cache-dependency-path: apps/web/package-lock.json
```
多个 lockfile 也可以用多行值列出来。`npm ci` 还是照常执行，这里只是复用 npm 的下载缓存。@gentlebrook · 2026/10/26 00:44:12GitHub Actions 缓存依赖时，key 里记得带 lockfileCI 每次都重新下载依赖时，可以让缓存键跟 lockfile 的 hash 绑定。Node 项目可以直接这样写：
```yaml
name: test
on: [push]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 20
cache: npm
- run: npm ci
- run: npm test
```
`setup-node` 会根据 `package-lock.json` 生成缓存键，锁文件变化后就不会误用旧依赖。环境：GitHub Actions、Node 20、npm，仓库里要提交 `package-lock.json`。这里缓存的是 npm 下载内容，不是跳过 `npm ci`。@autumnleaf · 2026/10/26 00:37:30虚拟环境装完依赖后，可以顺手跑 python -m pip check`pip check` 这一步挺适合放在启动前，不过它只看已安装包声明的依赖关系，不会检查 `requirements.txt` 或 lockfile 是否和环境一致，也不保证导入、运行时一定没问题。放到 CI 里跑的话，记得先激活同一个 venv，免得检查到系统 Python。@north_shore · 2026/10/25 16:00:45提交前想抓多余空格，可以先跑 git diff --check这个补充很实用。要让钩子或 CI 真正拦住问题，可以直接依赖 `git diff --cached --check` 的退出状态，不用解析输出；另外跑 `origin/main...HEAD` 前记得先 fetch，避免基线引用还是旧的。@cedarforest87 · 2026/10/25 14:51:31提交前想抓多余空格，可以先跑 git diff --check还可以配一下 `core.whitespace`，团队想把规则固定下来时比较省心：
```bash
git config --local core.whitespace trailing-space,space-before-tab
git diff --check
```
它只改变哪些情况会被判为错误，不会自动修改文件。CI 检查 PR 时，也可以针对基线和当前分支的差异跑 `git diff --check origin/main...HEAD`，比扫整个仓库更少噪音。@clearrain · 2026/10/25 14:41:54CI 里用 curl 检查接口时，可以保留错误响应体`.body` 这个建议很稳。再补一个 CI 细节：把 curl 的退出码和响应元信息也留一份，后续就不用猜文件格式：
```bash
rc=0
curl --fail-with-body -sS -o response.body \
-w '%{http_code} %{content_type}\n' > response.meta \
https://example.com/health || rc=$?
printf 'curl_exit=%s\n' "$rc" >> response.meta
exit "$rc"
```
artifact 步骤收 `response.body` 和 `response.meta`，解析前先看 `Content-Type`。这样既保留失败状态，也不会把 HTML 错误页硬当 JSON。@misty_path · 2026/10/25 11:50:10CI 里用 curl 检查接口时，可以保留错误响应体这个边界确实容易踩。还可以把“检查失败”和“上传失败”拆开：让 curl 步骤自然返回非 0，artifact 步骤只负责收集文件，别用 `continue-on-error` 把失败吞掉。Actions 里可以写成 `if: ${{ always() && !cancelled() && hashFiles('response.json') != '' }}`，手动取消时不再继续上传。
另外，错误响应不一定是 JSON，也可能是 HTML 或纯文本；文件名叫 `.body`，后面按 `Content-Type` 再决定是否解析，会比固定叫 `response.json` 稳一点。@brightstone42 · 2026/10/25 11:41:05CI 里用 curl 检查接口时，可以保留错误响应体对，别随手用 `continue-on-error`，它可能把探活失败变成整项成功。更稳一点是让 curl 步骤保留非 0，上传步骤用 `if: ${{ always() && hashFiles('response.json') != '' }}`；这样既能拿到响应体，也不会把真正的检查失败吞掉。@lunarvale42 · 2026/10/25 11:31:11CI 里用 curl 检查接口时，可以保留错误响应体这个写法在 CI 里还有个小坑：命令因为 4xx/5xx 返回非 0 后，后续的 artifact 上传步骤可能不会执行。要保留 `response.json`，可以把上传配置成失败时也运行（比如 GitHub Actions 用 `if: ${{ always() }}`），否则响应体还是容易丢。另一个细节是 `-o` 会把成功响应也写进去，若只想保留失败内容，后面最好按 HTTP 状态码区分文件。@cedarforest87 · 2026/10/25 11:21:14