我在TFS中使用Workspace.Checkin命令时遇到错误,因为我尝试检入的文件是Gated构建定义的一部分。有很多人在询问如何使用TFS API覆盖门控签入。但是一个非常不同的问题是:如果我实际 想要 以编程方式执行gated check-in怎么办?如何在TFS API中触发?
我想做的是:
我找不到任何答案来回答这个问题;也许这是一个边缘情况,我是唯一一个疯狂到想要这样做的人。也就是说,我对此的需求是合法的。我唯一可以想到的是,我需要通过门控签入过程的低级功能: 1)遍历构建定义,以查看任何文件的路径是否与任何门控构建中的任何路径一致。 2)如果存在交集,则创建待定更改的搁置集 3)使用shelveset对门控定义的新构建进行排队 4)查询构建定义并刷新信息,直到构建状态完成 5)如果构建成功,则取消搁置挂起的更改,然后使用覆盖签入。
但请注意,即使我执行了这些步骤,生成的构建也不会像门控构建一样。将发送策略覆盖通知,并且让某人知道实际执行构建的唯一方法是将此类信息包含在策略覆盖注释中。有没有更直接的方法来使它看起来像任何其他门控构建?
答案 0 :(得分:7)
Scordo的帖子提示我能够弄清楚如何做到这一点。这是代码:
//Initialize connection to server
TfsTeamProjectCollection tpc = new TfsTeamProjectCollection(new Uri(ServerAddress));
try
{
tpc.EnsureAuthenticated();
}
catch (Exception e)
{
System.Environment.Exit(-1);
}
VersionControlServer vcServer = tpc.GetService<VersionControlServer>();
IBuildServer buildServer = tpc.GetService<IBuildServer>();
//.
//.
//Program logic goes here...
//.
//.
//Get the workspace and the respective changes
Workspace workspace = vcServer.TryGetWorkspace(LocalProjectPath);
PendingChange[] changes = workspace.GetPendingChanges();
//Perform the check-in
bool checkedIn = false;
//Either wait for the gated check-in or continue asynchronously...
bool waitForGatedCheckin = true;
//Attempt a normal check-in
try
{
//First, see what policy failures exist, and override them if necessary
CheckinEvaluationResult result = workspace.EvaluateCheckin(CheckinEvaluationOptions.All,
changes, changes, "Test", null, null);
//Perform the check-in, with overrides if necessary, including Work Item policies
//or include additional code to comply with those policies
PolicyOverrideInfo override = null;
if (result.PolicyFailures != null)
{
override = new PolicyOverrideInfo("override reason", result.PolicyFailures);
}
workspace.CheckIn(changes, comment, null, null, override);
checkedIn = true;
}
catch (GatedCheckinException gatedException)
{
//This exception tells us that a gated check-in is required.
//First, we get the list of build definitions affected by the check-in
ICollection<KeyValuePair<string, Uri>> buildDefs = gatedException.AffectedBuildDefinitions;
if (buildDefs.Count == 1)
{
//If only one affected build definition exists, then we have everything we need to proceed
IEnumerator<KeyValuePair<string, Uri>> buildEnum = buildDefs.GetEnumerator();
buildEnum.MoveNext();
KeyValuePair<string, Uri> buildDef = buildEnum.Current;
String gatedBuildDefName = buildDef.Key;
Uri gatedBuildDefUri = buildDef.Value;
string shelvesetSpecName = gatedException.ShelvesetName;
string[] shelvesetTokens = shelvesetSpecName.Split(new char[] { ';' });
//Create a build request for the gated check-in build
IBuildRequest buildRequest = buildServer.CreateBuildRequest(gatedBuildDefUri);
buildRequest.ShelvesetName = shelvesetTokens[0]; //Specify the name of the existing shelveset
buildRequest.Reason = BuildReason.CheckInShelveset; //Check-in the shelveset if successful
buildRequest.GatedCheckInTicket = gatedException.CheckInTicket; //Associate the check-in
//Queue the build request
IQueuedBuild queuedBuild = buildServer.QueueBuild(buildRequest);
//Wait for the build to complete, or continue asynchronously
if (waitForGatedCheckin)
{
while (!queuedBuild.Build.BuildFinished)
{
//Get the latest status of the build, and pause to yield CPU
queuedBuild.Refresh(QueryOptions.Process);
System.Threading.Thread.Sleep(1000)
}
if (queuedBuild.Build.Status == BuildStatus.Succeeded)
{
checkedIn = true;
}
}
}
else
{
//Determine a method for specifying the appropriate build definition
//if multiple build definitions are affected
}
}
catch (CheckinException checkinException)
{
//Handle other checkin exceptions such as those occurring with locked files,
//permissions issues, etc.
}
if (checkedIn)
{
//Additional logic here, if the check-in was successful
}
答案 1 :(得分:3)
我之前从未这样做过,但这对你有所帮助:
当您使用工作区签入更改并且此签入受门控构建保护时,将引发GatedCheckinException。此异常应具有创建搁置集并使用该搁置集触发正确构建的所有必要信息。例如,AffectedBuildDefinitions
属性应该包含作为gated build defnitions的builddefinitions。
希望有所帮助。