为什么 ***NO_CI*** 仍然导致持续集成构建? [英] Why is ***NO_CI*** still causing a continuous intregration build?

查看:23
本文介绍了为什么 ***NO_CI*** 仍然导致持续集成构建?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我最近发现了 TFS 的隐藏功能",如果您的评论包含 ***NO_CI***,它允许您阻止 CI 构建启动.

I've recently discovered the "hidden feature" of TFS that allows you to prevent a CI build from kicking off if your comment contains ***NO_CI***.

我在家里运行 TFS,这个小技巧很有效.

I have TFS running at home and this works little trick works like a charm.

在工作中,我们也在使用 TFS 2010.我发现这仍然不能阻止 CI 构建在我们的设置中启动.

At work we are also using TFS 2010. I'm finding that this still does not prevent CI builds from kicking off in our setup.

我的问题是,实际上是什么进程检查注释中是否存在***NO_CI***来确定是否阻止CI构建?我最初的想法是查看构建模板.我没有看到任何太明显的东西.有没有人遇到过这个?你能指出我正确的方向吗?

My question is, what process actually checks to see if ***NO_CI*** exists in the comment to determine whether or not to block the CI build? My initial thought was to look at the build template. I didn't see anything too obvious. Has anyone ran into this? Can you point me in the right direction?

推荐答案

这个问题后来证明是我的一个错误.在我的构建成功后,我提交了几个自动签入.第一个包含 ***NO_CI*** 而第二个没有.我没有意识到第二次签入正在成为第二次构建在其工作区中映射的路径.因此,第一次签入并没有导致 CI​​ 构建开始,而是第二次签入.

This issue turned out to be a mistake on my end. After my build succeeds I have a couple of automatic check-ins submitted. The first one included ***NO_CI*** and the second didn't. I had not realized the second check-in was being made into a path that a second build had mapped in it's workspace. Thus, the first check-in wasn't causing the CI build to kick off, it was the second check-in.

这篇关于为什么 ***NO_CI*** 仍然导致持续集成构建?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆