在 Jenkins CI 中将文件从最新的 svn 版本上传到 SFTP
我正在配置 Jenkins 作业以将文件从 Subversion 上传到 SFTP。 Publish Over SSH 做得很好，但它会上传每个版本上的所有文件。
对于某些项目，我们有数千个文件，上传时间超过 1 小时，因此这不是一个选择。
谁能建议一种仅上传上次修订中更改的文件的方法？
I am configuring Jenkins job for uploading files from Subversion to SFTP. Publish Over SSH is doing quite well, but it uploads all files on every build.
For some projects we have thousands of files and upload cost more than 1 hour so that's not an option.
Can anyone suggest a way to upload only files changed in last revision?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您可以使用 Subversion 插件 轮询 SVN 更改并运行一个作业没有做任何特别的事情。我们将其命名为YourPollingJob。然后通过 http 调用 Jenkins API，如下所示：
其中
BUILD_ID是您刚刚运行的作业的实际构建 ID（通常的格式类似于2012-02-21_16-15-49 ）。检查结果。请注意，自上次构建以来已更改的文件的所有信息都在那里 - 您只需将其解析出来。因此，现在您可以执行以下操作：YourPollingJob 将调用另一个作业 - 让我们将其称为 CopyJob - 并将其
BUILD_ID作为参数传递给它（通过参数化触发器插件； CopyJob 作为构建后步骤，而不是构建步骤）。然后，CopyJob 将通过 http 查询 Jenkins（如上所述，最好的方法是通过wget进行查询），解析结果，然后进行复制。您可以在一项工作中完成所有工作，但它有点复杂并且难以调试。
另外，每天（每晚）复制整个存储库一次可能是谨慎的做法。
You can use Subversion Plugin to poll for SVN changes and run a job that does nothing in particular. Let's call it YourPollingJob. Then call Jenkins API via http like this:
where
BUILD_IDis the actual build id of the job you've just run (the usual format is something like2012-02-21_16-15-49). Examine the result. Note that all the information about the files that have changed since the previous build is there - you just need to parse it out.So now you can do the following: YourPollingJob will call another job - let's call it CopyJob - and pass to it its
BUILD_IDas a parameter (via the Parameterized Trigger Plugin; make sure to call CopyJob as a post-build step, not as a build step). CopyJob will then query Jenkins via http (as above, the best way is to do it viawget), parse the results, and do the copy.You can do it all in one job, but it's a bit more complicated and hard to debug.
Also, it is probably prudent to copy the whole repository once a day (nightly).
您可以将这些文件保存在单独的存储库中。听起来像 Mercurial 或 git 这样的分布式 VCS 最适合您的情况。您可以在工作区中进行设置，并添加一个构建步骤来提交更改的文件，并将提交推送到要发布它的服务器（只要您不清除工作区或在多个文件上构建，这应该可以工作）机）或添加额外的步骤来克隆/拉取包含来自您保存它们的服务器的工件的存储库。
You could keep those files in a separate repository. It sounds like a distributed VCS like mercurial or git would be best for that in your case. You could either set it up in the workspace and add a build step to commit changed files and push the commit to the server where you want to publish it (which should work as long as you don't wipe out the workspace or build on several machines) or add additional steps to clone/pull the repo with the artifacts from the server you keep them on.