I need to incorporate a task in my build to perform a Fortify Scan. My issue is I have one agent and scans take 1 to 2 hours, which ties up the one agent. I then tried to create a build that would start a scan of are TFS/SCM only to kill it after it ran for over 8 hours. Is there a way to create a task that only runs the changes for that day?
Since you are using Team Foundation Server 2017. As part of your build and release process you could execute Micro Focus Fortify security scans and upload the results to the Fortify SSC server.
It's also able to make the build/release fail whenever the scanner detects new critical or high findings in the code. We could use the Micro Focus Fortify plugin for TFS to configure the scan step and upload to SSC: (Fortify TFS plugin). Just add a PowerShell task afterward to attempt to query for findings and fail the build if needed.
Is there a way to create a task that only runs the changes for that day? There is also a concept called Scheduled Trigger which select the days and times when you want to run the build. Just make sure to check "Only schedule builds if the source and pipeline has changed" All support triggers are list here --Build pipeline triggers, please kindly take a look at it.
Related
we have around 300 TFS CI build definitions and now i want to change it into schedule build. Is it possible to change CI multiple Builds into scheduled.
Its really heck process to change one by one. I want some PowerShell or batch script to run the builds or any tool to change multiple TFS build definitions to schedule builds.
Thanks in advance.
You can use the TFS API to programmatically create and edit build definitions. Here is an example:
http://blog.ehn.nu/2010/04/creating-a-build-definition-using-the-tfs-2010-api/
Have a look at:
https://visualstudiogallery.msdn.microsoft.com/73bf2d8e-aec6-406c-8e7f-1c678e46557f
You should be able to change the trigger for multiple builds at once. I also created a set of powershell extensions to create/edit builds in bulk, but there is no CmdLet for the trigger yet, but have a look if you are interested in extending it (send me a pull request if you do ;)):
https://github.com/sanderaernouts/tfs-build-tools
I have created two build definition for two different builds in TFS 2015.
Ex - Build1 and Build2
Both the are getting executed without an error.
What I want to perform is, I want to provide an argument in build one
ex=Build2=True or False.
If the argument Build2=True after build definition Build1 successfully executed the build definition Build2 should get triggered.
And if Build2=False the build process should finish after execution of Build1.
I am able to do this in Jenkins by adding the Build2 to pipeline in postbuild tasks, since I am new in TFS 2015 so can anybody help me to accomplish this in TFS 2015
As #Yan Sklyarenko mentioned, this feature is not supported right now, please vote the User Voice at website below:
https://visualstudio.uservoice.com/forums/330519-team-services/suggestions/2165043-provide-build-configuration-dependencies-in-tfs-bu
I created a Build Task that should allow to support your described scenario. It uses the TFS REST API to queue new builds and supports conditions, for example a check if the last build of a specified build definition was successful or not.
You can download it from the Marketplace
Another option is to create Task Group for each build.
you can read about Task Groups here
and create one build that use some task group in his steps.
This seems simple enough, but I can't find a solution for this online.
I am integrating SonarQube into our build definitions that get triggered on check in. I want the version SonarQube uses to be tied back to the project number defined by the business side of things.
Ideally, I would like to be able to prompt the user for input. When you go to check in and it kicks off the build, it would ask you for the project number to be used as the version for SonarQube. Is this something TFS 2015 supports?
User input for build definitions
As far as I know, build definitions that are not manually triggered do not prompt for user input. A prompt allowing users to set build variables is shown for manually triggered builds from the VSTS web page.
SonarQube project version
I would recommend against you using the build or assembly version in your build tasks. This is because the SonarQube concept of version is quite different from the build concept. SonarQube uses versions as a baselining mechanism / to determine the leak period. If you up the version number often, the leak period is going to be too short to be actionable.
I'd recommend keeping the SonarQube project version in sync with your release schedule instead.
The short answer to this question is no, there is no way to prompt for input on a non-manually triggered CI build.
Here's what we did to work around this:
I wrote a Powershell script to read a config file and set the values to environment variables exposed to later build steps. Those variables are then what are specified in the Sonar Begin Analysis build task. I packaged that script up as a custom build task that will read a "sonar.config" file. This means all we have to do is add a "sonar.config" file to each solution we want to run Sonar analysis for, defining the key, name and version for the project, and then this build task will populate all necessary environment variables as the first step in the build.
So not a perfect solution, but it gets the job done without us having to add a lot of extra code to our solutions.
In TeamCity, you can create build dependencies where one build will not start until another finishes successfully. Is that possible with TFS 2012? Where can I find more information about how to set that up?
The short answer is that TFS doesn't have equivalent functionality, but you can achieve the same goals with a little work.
A common scenario I encounter is a team wants to do a build when they check-in that does some quick stuff (compile, fast unit tests), then immediately after wants to do another build that runs some slower stuff (integration tests, test deployments, etc). I do this often with my teams, and I'll setup a Gated Build that runs in say 5 mins, then have a CI build that is kicked off as soon as the Gated Build checks-in, which may take an hour to run. I like this approach as it gets the developers some feedback quickly, then more detailed feedback shortly thereafter.
Another supported scenario is having a build explicitly kickoff it's dependencies. If you look a the Lab Build Template it does exactly this, it will first kickoff the application TFS Build, and the Lab Build will sit and wait for it to finish, then the Lab Build will continue. In theory you could have Build A kickoff build B which kicks off C & D, etc.
If your needs are more complex than that (e.g. you have multiple applications that you have a build for each, then a Product that includes some applications that needs to be built after each application changes, then maybe a Product Suite build that needs to kickoff whenever a Product changes - this is the scenario I dealt with). I basically implemented a custom build dependency system to handle this. We made an XML file that described the build dependencies, then wrote a simple ISubscriber plug-in that we would deploy to TFS, and it would listen for Build Completed events then consult the dependency config and kickoff the appropriate build(s).
I am using MSBuild for building our test project from command prompt which inturn uses nunit and gives the results. I want to schedule it nightly so that it automatically runs the msbuild and get the results. Is there any way I can do that?
I would recommend using a Continuous integration server for this. You can set up your continuous integration server to schedule builds and a number of other tasks. Personally, I use Team City from Jetbrains, but there are other options available, such as Cruise Control.net and Hudson.
What exactly do you want to do with the results? If you just need to run your build script, a simple scheduled task should do it.
The way my company solved the problem was to use Powershell. We have a scheduled task that executes a powershell script that completely automates the process using MSBuild and devenv.exe.
We've been able to do away with the expense of many other continuous integration tools with this process. We have even connected it to our svn server so that it can checkout the latest revision, build it, send out an email if there was a build error and send the output of the screen as a result log.
I realize this might not be simple answer you're looking for, but Powershell was really easy for me to learn, exceedingly customizable, and very powerful. I had doubts when my Director said we were moving this way, but it's been a delight.