I have a CI build in TeamCity that runs on check-in. I have a QA build that is run manually. I would like to specify which ChangeSet the QA build should use so it doesn't inadvertantly push changes that are not ready. Is there a way to tell TeamCity to tell TFS that we want to pull xyz changeset?
Yes, use the "Run ..." button to the right of the build configuration you want to run (ie. click on the ... part).
In that dialog you should be able to pick exactly which changeset TeamCity should use. Note that it seems TeamCity only sees changesets which have occured in TFS after TeamCity started monitoring the repository, so if you want to build against an old changeset you might still be out of luck.
Related
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.
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 a pending changelist that I want to test in the build on our Jenkins server. I tried to do this using a P4 label but syncing to the label does not pick up my pending changelist.
Is there any way to do this with Jenkins SCM configuration?
In general, unless you have some very special circumstances, no other workspace can sync your pending changelist's changes, because they exist ONLY on your own workstation, not on the server. The server knows the names of the files in your pending changelist, but not their contents.
To make your changes accessible to the automated build tools, there are generally two approaches:
You can shelve the changes, then instruct the build tool to build from the shelf, or
You can check your changes into a development branch, then instruct the build tool to build the branch.
Or, of course, you could check your changes into the mainline, and have the build tools build them normally, but I'm guessing from your question you don't want to do that.
You can use the P4 Plugin. Follow the below steps
Create a Jenkins Job
Select checkbox: This project is parameterized
Add parameter name as Changelist
For the first step of build, select the option perforce unshelve and use ${changelist} as Changelist and resolve type as per your requirement
Under Build Trigger, select Trigger builds remotely (e.g., from scripts)
To trigger the build:
Shelve the Changelist
Trigger build with URL http://jenkinurl/projectname/buildWithParam?changelist=< shelved_cl >