I have a solution in TFS 2015 that using continues integration build method, what i want is every check-in triggers a build that selectively only output changed dlls, exe, into the artifact folder. Is there a such configuration to do so?
Unfortunately, there is no this built-in configuration with vNext build in TFS2015.
However, a obvious solution is adding a Powershell Script on what to publish as artifacts. Using a PowerShell script to organize everything and pre-compressing in single files is the best approach for your situation.
Detail step and screenshot please take a look at this blog: Manage Artifacts with TFS Build vNext
Related
My Visual Studio 2019 solution contains several projects, some of which I don't want to be built as part of continuous integration. Specifically, I'm trying to exclude tooling and unit tests.
In Visual Studio, I have created a new solution configuration and unchecked the "Build" box for each project I don't want to be built.
In TeamCity, I have specified the name of the new solution configuration to use. However, TeamCity continues to attempt to build all projects within the solution.
[I had included screenshots of my solution configuration, TeamCity build configuration, and resulting TeamCity log but I do not have enough reputation to post images apparently.]
From everything I could find so far, unchecking "Build" from the solution configuration used by TeamCity is supposed to exclude that project from building.
I figured it out by finally noticing that the TeamCity log was showing the build configuration as "ReleaseCI|Mixed Platforms" instead of "ReleaseCI|Any CPU". On other projects, I only needed to specify the configuration. For this project, I apparently have to specify the platform as well.
I am building my solution in Visual Studio Online Build, the default 'steps' are build/test/index+publish/publish build artifacts. I want the build to be placed in a folder in my source control (rootfolder/builds). However, I don't see an option to enter an output-path anywhere.
EDIT: I see that next to 'timeline' on the build screen there is the option to view the 'Artifacts', but, I want to see/copy the drop to my TFS online project folder like '$myproject/mybranch/builds/'
The option to store the build drop on the TFS server is no longer supported. It was introduced as a temporary measure in 2012 and replaced with server drops in 2013.
Server drops are stored in an unversioned store in TFS/VSO and does not incur the overhead of versioning.
In TFS 2015 this transitioned to the new Artifacts repository. All build output is stored on the server and is accessible in the web, and through an API.
The way things stand right now, this is not possible. You have two options to drop your build outputs
Team Foundation Server
UNC file share if you use a on-prem agent.
See the Artifact Type argument on Publish build artifacts.
I it is possible with a custom powershell task. I have recently created a powershell build task that could "check-in" your drop artifacts into a folder like $myproject/mybranch/builds.
Have a look : https://github.com/skuvnar/visual-studio-team-services-scripts.
Although its possible, I would suggest against it - could lead to all sorts of trouble with the builds.
TeamCity 8.1's build steps configuration page has a tantalising looking button:
Sadly, I am not worthy:
I can't find much documentation on what actually needs to be in the repository to have the step autodetected. There's a brief mention in the "What's new" for TeamCity 8.1:
TeamCity auto-detection mechanism supports most popular version
control systems and a wide range of build tools and technologies,
including: Maven, Gradle, Ant, NAnt, MSBuild, Visual Studio solution,
Powershell, Xcode, Rake, IntelliJ IDEA, as well as various command
line scripts.
and it's mentioned in the general manual:
Build steps are configured on the Build Steps section of the Build
Configuration Settings page: the steps can be auto-detected by
TeamCity or added manually.
but none of this tells me how it decides whether a particular MSBuild project/PowerShell script etc should be selected.
What does TeamCity look for when auto-detecting build steps?
When auto-detecting build steps, TeamCity peeks into version control system. For this process to take reasonable time, TeamCity only looks 2 levels deep into the source code tree. Moreover, if some suitable files were found on the first level, it does not go to second.
As for criteria for the build steps to be discovered:
For PowerShell build step, TeamCity looks for files with .ps1 extension
For MSBuild build step, TeamCity looks for files with .targets, .proj and .build extensions
For VisualStudio solution step, TeamCity looks for files with .sln extension
Please note, that if any files discovered were already configured by hand in some previous steps, they will not be discovered again
I have a c# solution with multiple projects. I have a .sln file I build the solution with in VS2012.
I am looking to set up TFS Build and want to include some custom msbuild actions, such as running stylecop and fxcop rules. I want these tasks to fire when building the solution locally and within tfs build.
I have looked at creating a .proj file for the solution. However, I am not sure how this can be setup locally and to run the tasks locally.
What is the correct setup for tasks to be run within tfs build and visual studio?
My best guess is to set the flag "Enable Code Analysis on Build" in the project settings "Code Analysis". More on that here.
I suppose that running StyleCop is better fitted in the IDE (check R#) or the VCS (check SVNStyleCop) on commit. I am not sure if the same exists for GIT or other repositories.
I'm running Visual Studio 2010, VisualSVN and TortoiseSVN.
Each time I use webdeploy to deploy the website, I'd like it to commit all of my files to SVN. What's the best way to accomplish this?
Visual Studio does a build when you hit the publish button. You can create a build configuration in VS2010 that executes commands after a successful build. You should install the command line SVN client and use that to execute a commit. Call the SVN command line client from the Build Configuration.
A more common approach would be to commit your change to the version control system instead of using WebDeploy. Then have a build server get the source from version control and incorporate the changes into the server. CruiseControl.NET is a good tool for doing that.
You should investigate https://github.com/loresoft/msbuildtasks which once installed and integrated into your project file, offer support for creating custom msbuild actions.
With it installed you can create 'SvnCommit' actions and associate it with a beforebuild or afterbuild target in your project file.
probably this is not the answer you are looking for - but I do not think you can get this out-of-box. I would suggest you to create a visual studio plugin and integrate it with SharpSVN (subversion client API) to achieve what you want.
UPDATE:
as #maddoxej mentioned, post-build action might work as well. However, I find it's easy to miss what configuration is selected - and press F5. And committing to SVN by accident is not generally a good thing.
Another option I thought about could be VS macro. Just record a macro which clicks deploy and then commits to SVN.
The answers that suggest making the check-in a build action is slightly flawed because the publication process will presumably increment a published build number as part of the publication process. This will modify the source code which will then need checking-in.