I've got the latest update of TFS (Version 16.131.27701.1), this link seems to imply that the build pipeline trigger is available: build pipeline triggers
It does not show up on the triggers page for a given build just the Scheduled option.
triggers page
Is there something I need to enable or maybe I am misunderstanding the link.
That feature hasn't made its way on-prem yet. It's slated for "2019" (the next major release of TFS), per the Features Timeline page.
Related
Does anyone know if the feature to tag agents has dissapeared?
I could not find anything related to over the internet.
My idea is to have certain builds use a specific agent. On TFS 2013 I would use tagging, but i no longer see that option.
On the other hand, I see that it is possible to connect a build definition to a certain agent queue.
There is no more agent tags for TFS 2015 or later version. If you want to use a particular build definition and a specific build Agent which used to run the build.
You could add a user Capability to that specific build agent then in the build definition you put that capability as a demand (General tab).
Another way is directly using Agent.Name or Agent.ComputerName demands in build def or when queuing a build. Take a look at this blog: How to send TFS build to a specific agent or server, which also support on TFS2015.
Oren: Is this feature works in TFS15 SP3?
Reply Eric Parvin: Yes, this should work on TFS 2015 to the newest version.
Use demands and capabilities for this. Add a custom capability to the build agent, and then add a matching demand to the build definition.
Demands and capabilities would work, and you could also create a specific queue, with a single available agent in it, and set the queue to your desired build, so you would achieve the same behavior as desired one.
I have just setup a basic multibranch pipeline build job and have a feature branch with a jenkinsfile present which I am experimenting with.
I have the job configured to poll the scm every 5 mins and trigger a build if necessary.
I am finding however at times when I manually start a build for my branch after I have pushed up a tweak on my Jenkinsfile for example (as I don't want to wait for the next scm poll interval), the branch re-indexing activity can still trigger another build to be performed.
See the image below for what I mean, so here build 7 is one I kicked off manually on jenkins, so it picked up my commit, but then the branch indexing kicked off build 8 but there were no new changes for the branch.
Is there a way to prevent this from happening? Other than me being patient and waiting 5 mins of course!
Thanks
I experienced this also. I tried playing with the polling settings in the Multibranch pipeline to see if this could fix it but that only led to no builds being spawned at all in response to SCM changes.
So this behaviour to which you refer was the best of a bad lot.
At time of writing, I think this behaviour is a bug with no current resolution.
Can't remember if I raised a ticket or not as I am in Azure DevOps world now.
We are using TFS and the TFS Build Service. We are considering to migrate the Build service to Jenkins but we came across some issues. According to this site, there are some things that do not work very well with the TFS and Jenkins plugins. All of them we use a lot:
Associated Change sets – Team Build automatically associates a list of change sets that are included in the build
Associated Work Items – Team Build analysis the relationships and also associates Work Items with a build. Indeed it walks the work item tree (parent) and maintains that association in the chain.
Is this still true? We have this scenario:
A developer checks in a code that fix a bug or resolve a User Story. It does that by associating his check in with the work item ID.
His check in triggers a build that will associate the work item with his changeset. For bugs, the build will update the "Integrated in Build" field with the build number. We use this field to know in witch version the bug was fixed.
Is there any way to make Jenkins behave and do what TFS build service does?
Another option is to mix the two using dummy builds on the TFS side that set the records straight and kick-off the Jenkins' builds. Some hints
How to trigger Jenkins builds remotely and to pass parameters and “Fake” a TFS Build.
This approach requires a bit of effort but has many advantages:
No big-bang, use Jenkins opportunistically
Can continue using existing builds
Having a build identifier in TFS allows you an overall monitoring and to use the Test features
I have a VSTS build definition for one of our projects that requires jenkins to build, but we still have all our other products using VSTS natively. To maintain consistency, this build definition triggers a jenkins build. We configured the build definition to not sync code as jenkins will download it (save time) and not to publish the artifacts back to the agent (i have another script for that found here). This allows developers to continue to use git as normal, and the build/release process is consistent with our other products. Along with task tracking and such.
I have searched many links but could not find the appropriate answer. I need to know when should I use "trigger builds remotely". I have gone through Integration Jenkins with SVN, there I saw that I need to check this option. I am not getting any idea regarding this.
This is used when someone commits to the source control (SVN) it shall ping Jenkins to trigger a build.
The "trigger builds remotely" option is used when you want to trigger a build from another tool:
As explain, you can trigger a job using the Jenkins URL:
http://your-jenkins-url/jobs/your-job/build
You can secure this URL by using an authentication token.
I hope it helps :)
You don't have to use it. There are multiple ways a build can be triggered
Build periodically - based on repeating cron schedule.
Poll SCM - based on SCM commits. This is also required when building on SCM hooks.
Build after/before other projects / Various - multiple ways to setup cross-project dependencies for selecting when to build.
Trigger builds remotely - to delegate the logic for monitoring/triggering builds to 3rd party applications/scripts.
The last one is used when you don't want Jenkins to be doing the triggering of the jobs (but Jenkins will still do the execution). It allows you to trigger a build through a specific URL. To avoid unauthorized triggering (since there is no login at this point), an authentication token can be provided.
This URL can be invoked any way you want: manually, command-line script, or some other 3rd-party application.
We have a nightly TeamCity build which releases the latest code to our test website, restores the database to match production, then applies any schema and data changes we have in TFS.
If this nightly build fails, the website is down until we manually fix the code and/or the database scripts and restart the build.
What I'd like is to automatically rollback to the last successful build so the website is available despite of any build break.
After spending a bit of time investigating, here's my proposed solution:
Nightly build runs, creating a new label in TFS (something like Nightly-build-{build number})
Create a new TeamCity build which triggers after the nightly build runs
Find the last successful nightly build number
Get the version relating to that build number's label in TFS
Rollback builds (it doesn't matter if the nightly build just finished successfully)
What I don't know is how to have the rollback build get the version based off a label.
Any help for this, or another solution, would be appreciated.
Cheers.
A judicious use of the TeamCity REST API might work here. I'm cribbing a bit from this question, which covers some of this same territory. You might could do something like this (and I'm just spitballing here):
Create your VerifyBuild configuration as per your Step 2.
Create a RollbackBuild configuration that can deploy from a given label, the build number of which is parameterized as %rollback.buildnumber%
In VerifyBuild:
Use the Rest API to list the most recent nightly production deployments
If the most recent deployment was a SUCCESS, then you're done.
If the most recent deployment was a FAILURE, then get the build number of the last successful build.
Use the Rest API to set the %rollback.buildnumber% of the RollbackBuild to the last successful build number.
Use the Rest API to queue a RollbackBuild.
I'm proposing this method because I don't know how you would dynamically fetch the correct label for RollbackBuild prior to the checkout, so I'm using VerifyBuild to pre-populate it.