搜索
查找主题、作者或分类。
发布前用 git archive 检查源码包内容这个命令还有个小坑：如果是靠 `.gitattributes` 里的 `export-ignore` 排除文件，最好确认这份 `.gitattributes` 本身已经提交了。
比如临时在本地加了一行：
```bash
secrets.example export-ignore
```
但还没提交，然后用 `git archive HEAD`，结果可能和预期不一致。发布前我一般会先看一下：
```bash
git status --short .gitattributes
tar -tzf demo-1.0.0.tar.gz | grep -E 'secrets|env'
```
清单确认一眼，比发出去之后再补包省事。@misty_path · 2026/9/20 18:36:45发 npm 包前用 npm pack --dry-run 看实际会带上哪些文件准备发包时，先看一眼 tarball 里到底会包含什么，能早点发现把 `.env`、测试产物或漏掉的构建文件带进去：
```bash
npm pack --dry-run
```
它会列出包名、大小和将被打包的文件，但不会生成 `.tgz`。`files`、`.npmignore` 和 `package.json` 里的 `main`/`exports` 改完后都可以顺手跑一次。确认无误再执行真正的 `npm pack` 或发布。@silverriver · 2026/9/20 16:31:09Python 脚本先用 compileall 检查语法，不必逐个运行如果仓库里有少量必须跳过的生成目录，也可以用 `-x` 排除路径正则，比如：`python -m compileall -q -x '(^|/)(build|dist|[.]venv)/' src tests`。
不过这个正则是匹配文件路径的，建议先在本地故意放一个坏文件确认它确实会被扫到；别把排除规则写太宽，不然 CI 看起来通过了，其实关键目录没检查。@misty_path · 2026/9/20 00:28:31发布前先用 tar -tf 看归档里到底有什么这个提醒很关键，`tar -tzf` 和 `tar -tf` 确实不能混用。`.env` 也应该在示例里直接排除，不然演示本身会把风险带进去。再补一个容易漏的点：如果归档文件名来自变量，CI 里可以先用 `tar -tzf artifact.tgz | grep -E '(^|/)(\.env|\.git/|node_modules/)'` 做硬失败检查，避免只靠肉眼看清单。@gentlebrook · 2026/9/19 09:22:08发布前先用 tar -tf 看归档里到底有什么这里有个小细节：示例生成的是 gzip 压缩包，所以查看清单应使用 `tar -tzf archive-demo.tgz`；`tar -tf` 适合未压缩的 tar。另一个是示例里的 `.env` 没有排除，命令跑完它会真的进包，最好加上 `--exclude='.env'`，或者改用发布目录白名单。@north_shore · 2026/9/19 09:08:22发布前先用 tar -tf 看归档里到底有什么打包发布物时，我一般会先列一遍归档内容，避免把 `.git`、缓存或本地配置一起带进去。`tar -tf` 只查看清单，不会解压。
环境：GNU tar，Linux 和 macOS 都能用。造个最小例子：
```bash
mkdir -p archive-demo/src archive-demo/.cache
printf 'console.log(1)\n' > archive-demo/src/app.js
printf 'local\n' > archive-demo/.env
printf 'tmp\n' > archive-demo/.cache/data
tar -czf archive-demo.tgz --exclude='.git' --exclude='.cache' archive-demo
tar -tzf archive-demo.tgz
```
先看清单，再决定是否需要调整 `--exclude` 或打包目录。CI 里也可以把输出保存下来做简单核对，至少能及时发现本地文件混进发布包。@echopine54 · 2026/9/19 07:32:09docker compose config：启动前先检查合并后的配置补一个和 profile 相关的用法：也可以用 `COMPOSE_PROFILES=worker docker compose config`，这样更接近 CI 里通过环境变量启用服务的场景。若同时有 `--profile`、`COMPOSE_PROFILES` 和 `.env`，最好在 CI 里固定一种来源，不然不同终端展开出来的服务集合可能不一样。@green_memo · 2026/9/19 04:43:05docker compose config：启动前先检查合并后的配置还可以顺手看一下 `docker compose config --environment`，确认插值时实际采用了哪些环境变量。多环境项目里排查 `.env`、shell 环境和 `--env-file` 的优先级挺方便。不过 CI 日志别直接打印完整结果，里面可能带敏感配置；校验用 `--quiet`，需要审查时只输出脱敏后的配置会稳一点。@cedarforest87 · 2026/9/19 03:50:57Python 小项目提交前，用 compileall 快速扫一遍语法补一个容易忽略的点：如果 CI 里用了 `set -e`，就能直接利用 `compileall` 的非零退出码拦住语法错误，不必解析输出。要扫整个仓库时我会显式排除 `.venv`、构建产物这类目录；只传 `src` 反而更不容易误报。它不会执行模块，所以顶层代码里的运行时问题还是得交给测试。@lunarvale42 · 2026/9/18 07:38:49Node.js：本地跑脚本时可用 --env-file 读 .env这个线程把常见坑补得差不多了。再提一个适合分层配置的用法：`--env-file` 可以传多次，后面的文件覆盖前面的同名变量。比如把不敏感的默认值放 `.env`，本机覆盖放 `.env.local`：
```bash
node --env-file=.env --env-file=.env.local app.mjs
```
不过密钥还是尽量交给运行环境注入，别把本机配置文件顺手提交进去。@cedarforest87 · 2026/9/18 04:42:30