Jenkins环境下fs.appendFile覆盖文件而非追加问题求助

你遇到的这个情况在Jenkins部署Node.js脚本时挺常见的，结合Jenkins的运行特性，主要有这几个可能的原因，咱们一个个拆解：

1. Jenkins工作空间被自动清空 #

很多Jenkins任务默认配置了构建前清空工作空间的选项——每次构建开始时，Jenkins会把工作目录里的文件全部删除，再重新拉取你的代码。这样一来，你本地运行时持续追加的timing.txt，在Jenkins里每次构建都是从零开始创建新文件，自然看起来像是“覆盖”了之前的内容。

你可以去Jenkins任务的配置页面，找到“构建环境”或“源码管理”相关选项，看看是否勾选了“清空工作空间”类的设置，取消后再测试。如果需要保留历史记录，也可以把timing.txt的路径改成Jenkins工作空间之外的固定目录（比如/var/jenkins_home/timing.txt），避开构建清空的影响。

2. 相对路径解析不一致 #

Node.js里的相对路径是基于process.cwd()（当前工作目录）解析的，你本地运行脚本时，cwd是项目根目录，但Jenkins执行脚本时，当前工作目录可能不是你预期的位置。比如Jenkins可能在临时子目录里运行你的脚本，导致每次写入的timing.txt其实是不同位置的文件，你查看的是最新构建生成的那个，就会误以为是覆盖。

解决办法很直接：把相对路径改成绝对路径，用__dirname来拼接确保路径准确：

const path = require('path');
const filePath = path.join(__dirname, 'timing.txt');
fs.appendFile(filePath, new Date().toISOString() + ' ' + timing + '\n', function(err) {
  if(err) { console.log('Something went wrong when writing to the file'); }
});

这样不管在哪里运行，都会定位到脚本所在目录下的timing.txt，路径不会出错。

3. 文件未被纳入版本控制且工作空间重置 #

如果你的timing.txt没被添加到Git（或其他版本库）的跟踪列表里，Jenkins每次拉取代码时，工作空间里不会有这个文件。脚本执行时会创建新文件写入内容，而本地因为文件一直存在，所以是追加逻辑。这种情况本质和第一个原因类似，区别是没有主动清空，只是每次拉取的代码里没有这个文件，导致每次都是新文件。

如果需要在Jenkins里保留历史记录，要么取消工作空间清空，要么把timing.txt放到版本库之外的固定路径，或者在构建前从存储位置把历史文件拷贝到工作空间。

4. 权限问题导致的意外创建 #

虽然可能性相对小，但Jenkins运行脚本的系统用户（比如jenkins用户）可能没有对当前目录下timing.txt的追加权限，这时候fs.appendFile会尝试创建新文件（如果旧文件无法访问），看起来就像是覆盖了原文件。

你可以在Jenkins构建步骤里加一条命令：ls -l timing.txt，查看文件的所有者和权限设置，确保运行Jenkins的用户有读写权限。

内容的提问来源于stack exchange，提问作者Homewrecker