I'm using TFS 2010 and Visual Studio 2013. When I queue build I can select option "Latest sources with shelveset" and select shelveset and it is working ok.
I can also set given version on Parameters tab as MSBuild Arguments for eg. by changeset CXXXXXX and it's working ok too.
I'm trying to combine these two options and it's not working. Changes from shelveset are not downloaded during Get task. How can I combine these two options?
No, it is impossible for you to combine these two options.
It is impossible.Why would you like to combine these two options?
Queue a build through shelveset is a private build. The other way you achieved is public build. More info from Microsoft: https://msdn.microsoft.com/en-us/library/ms181722(v=vs.120).aspx
If you want to build a shelveset with "specific changeset" , you can roll back a changeset and put what you want to build in a shelveset. At last ,build the shelveset.
Related
I have a TFS build that runs on a schedule. Within the build process I have a step that checks out that project's properties file, increments the assembly's version number, then checks in the file bypassing any gated check-ins. This is creating a problem as the check-in of the properties file automatically sets the scheduled build to run the next day, causing an infinite loop.
My question is, is there a way to associate changesets made within the build process to the current running build?
I've tried refreshing the build detail and re-associating changesets after the msbuild compiles the project, but before the build finishes, without success.
Our projects are for Visual Studio 2010 and we are running against TFS 2013.
EDIT 12/21/15: For clarification:
I know about the NO_CI for bypassing CI Builds and including the /bypass in the command line. Overall my check-in that I am doing looks like the following:
"C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\tf.exe" Checkin %My_FILE% /comment:"***NO_CI*** Version Updated to %NewVersion%" /noprompt /bypass
I"m having trouble with scheduled builds kicking off, because my check-in is telling it that there is a changeset to build.
You need to check in without triggering the build.
To tell the build system to ignore the check-in operation, a check-in comment value***NO_CI*** is specified to indicate "No Continuous Integration" meaning "please don't start a CI build because of this check in". Place the following into the comment field:***NO_CI***and when you check-in TFS will not kick off a build. More details for your reference: http://bartwullems.blogspot.hk/2012/08/tfs-do-check-in-without-triggering.html
update
You could customize your build template and add in the custom TFSVersion activity from the TFS Community Build Extensions that will handle this. Detailed steps for your reference:http://tfsbuildextensions.codeplex.com/wikipage?title=How%20to%20integrate%20the%20TfsVersion%20build%20activity&referringTitle=Documentation
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.
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.
Hi and thanks for your time.
I work with a small development group and we are working on a project using Team Foundation Server on Visual Studio 2010.
We would like to know what we have to use to go back and work with a previous version or build of the project.
Can we use TFS Version Control, TFS Build Server or TFS Source Control ???
How can I do this???
Does this help? --> tf rollback
Thank your very much four your help !
If you want to get the previous version of a directory for instance, in the Source Control Explorer right click on the directory, then choose "Get specific version..." then select the way you want to choose the version you want to get.
Typically you'll have to come up with a older changeset id then its version will be retrieved locally.
tf rollback is used to "cancel" a given changeset (a changeset is the result of a check-in operation) by creating another one that negate the changes. So it's used when you did a wrong check-in on some files and you want to revert to the previous state.
We have a 50 projects solution in VS 2005.
Is any way to get incremental build if nothing was changed?
It is kind of doing it now, but it executes all prebuild and post build events for each project.
Is any way to prevent it?
Have a look at the Build Events tab. Notice the dropdown at the bottom that says Run the post-build event:. Does it say "On successful build"? Try changing it to "When the build updates the project output".
Visual studio does what you describe by default, custom build steps are not executed for up to date projects.
Something in your dependancies or build settings are causing it to update all builds. Unfortunately it's hard to track down without additional infromation.
If you know ahead of time which ones you would like to build or not build, you could create different build configurations that only build specified projects.
This solution doesn't use dependencies at all, so it will only work if you have a few different distinct groups of projects.