我们的 jenkins 部署过程将我们的 git repo 检出到工作区,然后使用通过 SSH 发布插件将文件从工作区复制到我们的暂存环境中。
2 天前,我们在上午 10:34 和下午 02:13 进行了提交和自动部署。上午的提交部署良好,自下午的提交以来,发布作业报告了以下内容:
BUILD SUCCESSFUL
Total time: 15 seconds
SSH: Connecting from host [...]
SSH: Connecting with configuration [...] ...
SSH: Disconnecting configuration [...] ...
ERROR: Exception when publishing, exception message [Permission denied]
Build step 'Send files or execute commands over SSH' changed build result to UNSTABLE
提交本身是次要提交,包含前端的 css 和 javascript 文件。没什么特别的。
整个暂存环境已递归设置为 chmod 777,并将其 chown 设置为通过 ssh 配置进行部署所使用的用户和组(暂时,以确保我们不会遇到文件权限问题)
任务仍然报告权限被拒绝。
在过去 2 个月中,通过 ssh 部署任务的配置没有改变。相同的密钥、相同的用户、相同的密码等。
遗憾的是,错误信息不包含任何有用的详细信息。
另一项工作是将不同的项目部署到同一个 Web 服务器中,只不过是在不同的 Web 根目录中,这样就工作正常了。
服务器运行 FreeBSD 并且驻扎在主机上。
在联系他们之前,我们要确保我们已经检查了所有情况。
答案1
问题是我们的 Jenkins 作业不会清理其工作区。永远都不会。
工作区中有一个文件夹原本在 git 上,但被移除了,并且位于 Web 根目录之外。但由于它没有被清理,该文件夹的工件仍然留在工作区中。
现在有人在暂存区对该文件夹进行了更改(直接通过 SSH),但忘记正确设置权限。因此,当“通过 ssh 发布”作业启动时,它尝试复制旧工件,但没有权限。
由于该文件夹位于 webroot 之外(我们已将其 chown 并设置为 777 以进行测试),因此我们无法看到它。
Jenkins 作业已更改为在每次作业后清除工作区,并且权限已正确设置。部署现在再次正常运行。
@Others:请注意对原始问题的评论艾奥尼。这对于弄清事情的真相非常有帮助。
此外,在通过 ssh 发布作业的高级选项卡中,您可以选择“详细输出”。这将使正在运行的作业的控制台输出详细。请参阅发布 - jenkins-ci.org 上的插件 Wiki