Using TFS 2018 update 3, a step was defined to be executed only on scheduled builds., the custom condition was defined:
eq(variables['Build.Reason'], 'Schedule')
A build was queued, Despite the fact that the variable Build.Reason = 'Manual'. the step was executed, then the condition was changed to :
and(succeeded(), eq(variables['Build.Reason'], 'Schedule'))
The result was the same: the step is executed even in gated check-in and or manual builds.
Related
I have a Jenkins job set up to poll for a change in a git repository every 10 minutes. If it doesn't find one (99/100 times, this is what happens) it aborts the build early and marks it as UNSTABLE . If it finds a change, it goes through with it and marks it as SUCCESS, storing its artifacts. I know I can use a plugin to discard old builds, but it only allows for these options:
As you can see, there is no option to filter by completion status.
Ideally, I want to discard all but the latest UNSTABLE build and keep all SUCCESS or FAILED builds and their artifacts. If this is not possible, simply discarding all UNSTABLE builds would also work.
Note: I am using a declarative Pipeline
One possibility would be to discard builds programmatically. Get your job object with def job = Jenkins.instance.getItem("JobName") Since you are using declarative pipeline, job is of type WorkflowJob [1] and you can get all its builds with
job.getBuilds(). Now you can check the result of each build (WorkflowRun objects [2]) and decide if you want to delete it or not. Something like follows should work
def job = Jenkins.instance.getItem("JobName")
job.getBuilds().each {
if(it.result.toString() == "UNSTABLE") {
it.delete()
job.save()
}
}
You could create a new job that executes the code above and is triggered after YourJob has been built.
[1] https://javadoc.jenkins.io/plugin/workflow-job/org/jenkinsci/plugins/workflow/job/WorkflowJob.html
[2] https://javadoc.jenkins.io/plugin/workflow-job/org/jenkinsci/plugins/workflow/job/WorkflowRun.html
I have a Microsoft Visual Studio Team Foundation Server (Version 15.117.26714.0) with predefined variable $(ProjectBuildNumber).
Is there any way to increment, during build process, value of variable with minor build number by +1?
$(ProjectBuildNumber) = 663
So, that on next build it will be:
$(ProjectBuildNumber) = 664
You can't reference variables in the build number of the Build Definition. But what you can do is override the build number in the build itself. You can either use a magic log command or use my VSTS Variables Task to set the Build.BuildNumber in the build itself. The Variables Task does expand variable references. You could probably just set the value to the current value to get it expanded.
To issue the log command yourself use a batch script, PowerShell or bash to output the following specific string to the console:
##vso[build.updatebuildnumber]build number
Update build number for current build. Example:
##vso[build.updatebuildnumber]my-new-build-number
Minimum agent version: 1.88
source: https://github.com/Microsoft/vsts-tasks/blob/master/docs/authoring/commands.md
An alternative option is to use the $(Rev) option:
Build.BuildNumber = 1.1.$(Rev:.r)
That will automatically increase the variable each time the build runs.
To update a variable in a Build Definition use yet another extension:
These things combined should be able to get what you want.
In the variable section,
set the value of ProjectBuildNumber to $[counter('', 663)].
This will queue build starting with 663 as ProjectBuildNumber and increments by 1 for the subsequent queue of builds.
Unfortunately counter function (Expressions) is not available in TFS 2018. In this old version the best solution for me is to use a PowerShell script as the first Task of the build. You can than have your parameter
$(ProjectBuildNumber)
as an input argument, and place this inline script:
$ProjectBuildNumber=$args[0]
$ProjectBuildNumber++
Write-Host "##vso[task.setvariable variable=ProjectBuildNumber;]$ProjectBuildNumber"
After this Task you can use your incremented ProjectBuildNumber variable in all subsequent Tasks.
Is it possible to succeed the failure build through TFS Build Definition even though it has some build errors ? like it should continue on build error
If yes, please provide MSBuild arguments ...
Thanks in advance :)
You can tell MSBuild to execute a task and continue on errors (see MSDN articles):
https://msdn.microsoft.com/en-us/library/77f2hx1s.aspx
https://msdn.microsoft.com/en-us/library/ms171484.aspx
ContinueOnError
Optional attribute. Can contain one of the following values:
WarnAndContinue or true. When a task fails, subsequent tasks in the Target element and the build continue to execute, and all errors from the task are treated as warnings.
ErrorAndContinue. When a task fails, subsequent tasks in the Target element and the build continue to execute, and all errors from the task are treated as errors.
ErrorAndStop or false (default). When a task fails, the remaining tasks in the Target element and the build aren't executed, and the entire Target element and the build is considered to have failed.
Versions of the .NET Framework before 4.5 supported only the true and false values.
Short Version:
I am setting the Status=Failed and TestStatus = Failed on a custom build template (.xaml).
When the build is setup as a Gated Check In (CheckIn), the code still commits.
Long Version:
I have some custom logic in the build workflow that is setting the below properties.
<!--the below is a result if a custom code activity I wrote returns a "true" for Code Coverage being lower than expected -->
<mtbwa:SetBuildProperties DisplayName="Set Status and TestStatus to Failed" Status="[Microsoft.TeamFoundation.Build.Client.BuildStatus.Failed]" TestStatus="[Microsoft.TeamFoundation.Build.Client.BuildPhaseStatus.Failed]" sap2010:WorkflowViewState.IdRef="SetBuildProperties_7" />
My build "goes orange", but the code still gets checked in. The check-in of the code is the undesired result.
Some other "setup" screens:
Other articles I found:
TFS Gated check-in -- How to reject check-in on Partial Build Success?
Fail a build if code coverage is below a threshold in TFS2012
APPEND:
My template was from a Microsoft default one.
My custom check is defined between
If CompilationStatus = Unknown
and
If TestStatus = Unknown
At the end of the workflow there should be a task that checks in the shelfset. Make sure that is encapsulated in the proper logic to skip the checkin when the compilation status, test status or overall build status isn't what you want.
Original Gated Checkin might look like this:
<mtbwa:InvokeForReason DisplayName="Check In Gated Changes for CheckInShelveset Builds" sap2010:WorkflowViewState.IdRef="InvokeForReason_6" Reason="CheckInShelveset">
<mtbwa:CheckInGatedChanges DisplayName="Check In Gated Changes" sap2010:WorkflowViewState.IdRef="CheckInGatedChanges_1" />
</mtbwa:InvokeForReason>
With an IF condition around it:
<If Condition="[BuildDetail.TestStatus = Microsoft.TeamFoundation.Build.Client.BuildPhaseStatus.Succeeded]" DisplayName="BuildDetail.TestStatus = Microsoft.TeamFoundation.Build.Client.BuildPhaseStatus.Succeeded" sap2010:WorkflowViewState.IdRef="If_41">
<If.Then>
<mtbwa:InvokeForReason DisplayName="Check In Gated Changes for CheckInShelveset Builds" sap2010:WorkflowViewState.IdRef="InvokeForReason_6" Reason="CheckInShelveset">
<mtbwa:CheckInGatedChanges DisplayName="Check In Gated Changes" sap2010:WorkflowViewState.IdRef="CheckInGatedChanges_1" />
</mtbwa:InvokeForReason>
</If.Then>
<If.Else>
<mtbwa:WriteBuildWarning DisplayName="Write BuildDetail.TestStatus" sap2010:WorkflowViewState.IdRef="WriteBuildWarning_5" Importance="[Microsoft.TeamFoundation.Build.Client.BuildMessageImportance.High]" Message="["Gated Checkin Failed, BuildDetail.TestStatus=" & System.Enum.GetName(GetType(Microsoft.TeamFoundation.Build.Client.BuildPhaseStatus), BuildDetail.TestStatus)]" mva:VisualBasic.Settings="Assembly references and imported namespaces serialized as XML namespaces" />
</If.Else>
</If>
Note. The BuildStatus will be set back to "InProgress" by TFS. Piggyback on BuildDetail.TestStatus is probably the better bet.
I have 3 Jenkins jobs. Smoke tests, critical path test (part 1), critical path test (part 2).
Now it starts one by one. I need create build PipeLine depends on test result. I need to take into account the results of a single test (#Test annotation in TestNG), ignoring the overall result of test suite.
I want to get the configuration like this:
Smoke tests -> If specified test passed then run critical path test Part 1 and Part 2 on different nodes
So, please tell me how depends in Jenkins only on one tests result (not all suite)?
You can try to use some of build log analysis plugins:
https://wiki.jenkins-ci.org/display/JENKINS/Text-finder+Plugin
https://wiki.jenkins-ci.org/display/JENKINS/Post+build+task
Scan build output, and downgrade build result to failure on specific text.
Next in downstream item check option "Build after other projects are built" in build triggers section. Set proper upstream item name and set proper trigger result.
I solved that task by using 2 Jenkins extensions:
https://wiki.jenkins-ci.org/display/JENKINS/EnvInject+Plugin
https://wiki.jenkins-ci.org/display/JENKINS/Build+Flow+Plugin
Create properties file from test. File contains property, that indicate result of test step status
With EnvInject Plugin add new step into Jenkins Job (step must be after test run) and inject parameter value (from file created at first step)
Create build flow with Build Flow Plugin
Write groovy script:
smokeTest = build( "Run_Smoke_Test" )
def isTestStepSuccessful = smokeTest.environment.get( "TestStepSuccessful" )
if (isTestStepSuccessful != "false") {
parallel (
{
build("Run_Critical_Path_Part_1_Test")
build("Run_Critical_Path_Part_3_Test")
},
{
build("Run_Critical_Path_Part_2_Test")
}
)
}
build( "Run_Critical_Path_Final_Test" )