Hudson 构建脚本位置 - 推荐吗？
我已经与 Hudson 和 Nant 一起完成了我的项目构建自动化:)。
我的项目结构类似于
$/Project
build.scripts
script1.build
script2.build
build.properties.xml
Code
Project1
Project2
So Hudson 从根 $/Project 下载到工作区文件夹。
一切都很好，因为 build.scripts 在工作区中，我很容易运行它们，但是困扰我的是，由于构建脚本在工作区中，所以我无法对 Hudson 进行编程以自动运行准时或更改，因为它总是会检测到文件的更改（请注意 build.properties.xml，我在构建时签出并签入以存储一些统计信息）。
您建议将这些文件放在哪里，并且仍能获得源代码控制的优势？
I'm already finishing my project build automation :) with Hudson and Nant.
My project structure is something like
$/Project
build.scripts
script1.build
script2.build
build.properties.xml
Code
Project1
Project2
So Hudson downloads from the root $/Project to the workspace folder.
And everything is ok since the build.scripts are in the workspace, I run them very easily, however what is bugging me is the fact that since the build scripts are inside the workspace, then I can't program Hudson to run automatically either based on time or changes because it will always detect changes to the files (note build.properties.xml which I check out and check in at build time to store some stats).
Where do you recommend these files to go in and still get the advantage of having them source-controlled?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我最终做的是不签入对这些文件的更改。我更改了 CI 工作流程以创建另一个文件（仅限工作区本地），并将更改写入其中。
这样，我仍然可以在某个地方写入最后的构建信息来获取它，并避免 Jenkins 检测到更改的问题。
PS：我从 Hudson 改为 Jenkins，因为我看到大多数插件都摆脱了前者。过渡过程过于顺利，令人难以置信。
What I ended up doing is to NOT check-in changes to those files. I changed my CI workflow to create another file (local to the workspace only) where the changes are written to.
This way, I still get the last build info written somewhere to pick it up, and avoid the issue of Jenkins detecting the change.
PS: I changed from Hudson to Jenkins since I saw that most plugins ran away from the former. The transition was too smooth to be true.