Is there any options to lock TFS check-ins when the build is failing or three consequent times in Jenkins?
Not totally sure about your meaning of lock TFS check-ins. If you just want a developer checks in changes that break the build. We do not have any build in feature to support this integrate with Jenkins.
However, you can guard some or all of your code base against these problems by creating a gated check-in build definition(TFVC) or pull request(Git) through TFS own build system.
If you are using TFVC, by using Gated build, when developers try to check-in, they are prompted to build their changes. More details please take a look at our official tutorial.
If you are using Git, you could use pull request and branch policy. There is a Build validation setting in branch.
Validate code by pre-merging and building pull request changes
With using both of above method, you could only check in codes/changes when build succeed.
Related
I would like to know what is the equivalent of "Continuous Integration - build each check-in" (XAML definition) in VNext definitions.
1- Is it "Run continuous integration triggers for commited changes" in Gated trigger?
2-Or it is a "Continuous Integration trigger with batch changes checked" in build definition.
I ask this question because I was not able to launch a CI build after successfully Gated Check-in. My CI build does different steps than Gated.
I'm over TFS 2017 (15.117.27414.0).
The equivalent of "Continuous Integration - build each check-in" (XAML definition) in VNext definitions is Continuous Integration trigger:
Enable CI trigger if you want the build to run whenever someone checks
in code.
Select Batch changes check box if you have a lot of team members
uploading changes often and you want to reduce the number of builds
you are running. If you select this option, when a build is running,
the system waits until the build is completed and then queues another
build of all changes that have not yet been built.
Select the version control paths you want to include and exclude. In
most cases, you should make sure that these filters are consistent
with your TFVC mappings on the Repository tab.
You can get more details in the link below:
https://learn.microsoft.com/en-us/vsts/build-release/concepts/definitions/build/triggers?view=vsts
All our Jenkins jobs are configured to build changes on all branches in a repository. There are times where we want to re-run a specific build that ran against a specific commit.
a build fails because some external resource was unavailable and we want to re-run that commit once the resource is up again;
a job depends on an internal package and we need to be able to re-build specific branches to pick up the latest version of that package.
Jenkins' "Build Now" command, however, builds on the branch of the last build. It doesn't let the user choose what branch to build on. In order to rebuild a branch, users have to commit and push a change to that branch.
Is there a plugin that will allow the user to re-run a specific build or choose the branch to build on? If you've used TeamCity, I want the "Re-run with same revisions" feature.
We've tried both the Naginator and Rebuilder plugins. Naginator only lets you rebuild failed builds, but also automatically re-builds failed builds at least once (not desireable). Rebuilder always rebuilds the last commit. It behaves just like the "Build Now" button.
The Rebuild plugin is probably the closest plugin to what you want however as you have found it only will get HEAD and not a specific git revision.
This is an open feature request.
The comment on this question notes the same thing.
All that being so I would still suggest that you should perhaps reconsider the idea of depending on the git revision to drive the outcome of your build. You should want to build the HEAD.
Is it possible to trigger personal builds using TFS and Jenkins? Similar to what can be achieved using Teamcity. Can a developer trigger a build without checking-in so that his/her changes can be tested before checkin?
thanks,
You can do this with TFS. Assuming you are using TFS Build, available in TFS 2015 and in VSTS, and your source control is Git, you can setup a build policy for a specific branch that triggers a build any time a pull request happens. Details here.
If you are using the older XAML builds, look at Gated Checkins.
I am having an issue with the new TFS 2015 Update 2 Gated Builds.
After attempting a check-in the gated build queues just fine, every part of the build is successful until it reaches the last step of "Check in gated changes".
When I look at the log for that step I get:
[Error]The shelveset _Build_5427;Build\ad8fe058-f936-4908-91de-57e7bc6a2f9d could not be found for check-in
When I look at the 'Get Sources' log, I see:
2016-04-01T19:11:12.3062092Z tf get /version:C6213
2016-04-01T19:11:13.2125013Z tf shelve _Build_5427 /replace
2016-04-01T19:11:13.3218610Z Successfully created new shelveset _Build_5427;Domain\BuildServiceUser
I recognize the username as the service user (and have thus redacted it here). It looks like it is trying to find the correct shelveset name, but for the wrong user.
Update 4/20/2016 :
I ended up having to create a brand new project.
The failed reason: your are trying to check in files with your own account. But the build agent try to check in the changes with the service account.
It seems there are something wrong with your build agent. After you update your TFS server to TFS update2, you also need to update your build agent. If still not work , try to download the agent and deploy a new one. Detail steps from MSDN: Deploy a Windows build agent
I experienced this issue using on-premise TFS 2015 Update 2. As a workaround I settled with a regular CI-build instead of the Gated trigger and I scheduled a release buiild nightly.
However, we have recently installed TFS 2015 Update 3 and that solved the issue. We now use the configuration that we wanted: 1 Gated build that checks in the changes and 1 Continuous Integration build for the release.
I have one build controller and it has 4 build agents in it. When I run more than one build at a time it queues the build. Why it doesn't run 4 builds parallel? Is there any settings that I should change?
I am running TFS 2012.
running gated checkin
it also runs all the tests after the build is done.
Thanks for the help!
This is 'by design'. From Use a gated check-in build process to validate changes
Each gated check-in build definition can have only one running build at a time.
This is necessary to preserve the logic coherence of you version control.
If this is slowing your dev organization, you have many options (some are in the doc linked):
Change from Gated to Batched gated
Have multiple Build definitions (mapped on different portions of you sources)
Minimize the checks during build
Feed more resources to the Build server