Okay, I have a couple inquiries:
1 - Let's say I have a solution that references several external projects. I want to reference specific Labels (that represent stable versions) on those external projects. I know that you can do this by doing a Get Specific Version by Label on those projects. But once you've done that, is there a convenient way to do a Get on the whole solution, and have it preserve all of the specific versions?
Ultimately, I would like to do a single Get and have it get latest where that is applicable and get specific versions where that is applicable. It seems frustrating to have to do separate Gets on all the projects.
2 - Is it possible to build binaries from labels? When an external project is a stable version that isn't going to change, it makes sense to just reference the binary. When you create a label and build it, does it generate binaries in a specific location for that label that can be referenced?
On your first question: While TFS allows you to grab sources by Label, there is no way to setup a a workspace configuration that is bound to a specific Label or Changeset for a specific path. The only thing I can think of would be to create a batch file which fetches the latest version:
tf get $/Project/Sources /Version:T /recusive
tf get $/Project/ComponentA /version:LMyLabelName1 /recursive
tf get $/Project/ComponentB /version:LMyLabelName2 /recursive
The way forward to do this is to publish your external references to a NuGet repository (can be your own) and then configure NuGet to get a specific version. A CI build can publish a new version to your NuGet server. And you can setup your own server so that you don't need to publish all your binaries to a public server.
On your second question: yes you can build by label in the Queue Build screen you can setup the version to build which will be built:
You can specify a Changeset number (C######), Label (LLabelname) etc. Any version spec will do (see the commandline docs for a explanation on version specs).
By default, no easy referencable name is generated if you build by label. I suspect that some clever build customization will allow you to drop the build output in a predefined folder based on the label name, but there is no such out-of-the-box functionality.
Related
We have multiple repos and whenever the developer runs the sonarQube scanner through Jenkins job, it is creating one project with build number along with the date, is there anyway I can re-use the same project name ..?
developers are running sonarQube reports through Jenkins jobs.
sonar.projectKey=portal1-sonar:1stiteration-${BUILD_NUMBER}
sonar.projectName=SonarQube nodeJS portal1 Build : ${BUILD_NUMBER}_${BUILD_TIMESTAMP}
anyway, I can change and use same project name, whenever developer runs sonarQube.
every project is defined in SonarQube with it's own key. That means if the key is the same, it is the same Project, and you will have a "history" of analyses and can compare parameters.
Although the idea of buildnumbers seems to be interesting, i recommend to use Branch names instead. There are currently two ways of doing this, for the first one, you need to have a SonarQube installation with a paid price. Than you are entitled to use the branch plugin. Which is actually the more superior way, because your project will show branches. The sonarQube docs are quiet helpful regarding this.
The old/Deprecated way will create a new project per branch, which you can than compare. the property you need to set is sonar.branch and this will be automatically added to your project key. So if the project key is Project and the sonar.branch is set to develop your new project will have the key Project:develop. This parameter is deprecated, and i am not sure, how long it will stay in the system.
We are starting to use TFS2013 (we use svn still, but for a number of reasons we're putting new code on TFS).
I have a solution that contains a project with an EF database model and I would like to share it with a different solution (to be more specific: there is a client website solution and a separate one for backend).
On SVN I would have created svn externals - I would be able to share the code easily and if I branched, the shared project would have a nice copy on branch as well. Moreover, both projects would have the most up-to-date version of the db model, which suits me perfectly.
TFS 2013 seems to push be pushing towards NuGets. That means, that if I create a nuget package of the db project:
I will have to update the db projec separately each time there is a db change, release it and then update all projects that use it
If I branch, I'll probably have to create a different nuget package for the branched version and amend the nuget reference on merge
It pollutes the nuget repo with things that are not exactly worth a repository (in case of a DB model, you want to have the latest possible version because a website will probably break if you don't, no point for versioning so that the build doesn't break)
I spent some time trying to find a suitable solution, but the best idea I found is just referencing the project from a different solution - the problem with it is, I would have to make the root folder for the build be higher than just the solution and that would add several more projects that I don't need. Another idea is referencing by branching, which was good for TFS 2010 with multiple projects, but I can't fit it into my scenario (we have a single 'Main' node where we put all solutions).
So, how would you share a DB project on TFS 2013?
I have been working with a TFS project that supports copying build output to source control. If I open the build definition, this is under "Build Defaults". There is an option to copy build output to a source control folder.
I have just installed TFS Server 2013 (with update 2) and I want to use this feature with a new Team Project. However, if I create new build in VS 2012 or VS 2013 on the new server, I am not given the option to copy build output to source control. What gives?
I am not looking for a workaround, I want to know what to change so that my server acts like the first one I described. Thanks!
Screenshots of what I'm talking about: http://imgur.com/a/mhDNQ
This was a feature that was temporarily present in TFS, but I believe has since been removed. If I recall it was put in there specifically to support the cloud-hosted elastic build servers which didn't have access to network shares to drop the builds in.
Most people recommend against putting your build outputs into TFS. The best approach is to publish them to a NuGet feed.
In any case if you want to put your build outputs into TFS (or a NuGet feed) you'll have to modify the build workflow to do that yourself.
Open a new build definition > process.
Under template select new and you should be able to choose project and folder. Find your original template and link it. Your option should appear.
In TFS 2013 this has changed to be "store drops in TFS". When you select this option the drop I'd stored in a new inversioned store that you can access.
While you can easily get the files out as indecision or zips the built in tools like release management do not support it yet. I would recommend that you use this option but publish your assets to a nugget repository.
If your TFS is available online (VSO or https) then you can use MyGet to dynamically load the nugget packages that you are publish and make them available on a feed.
http://docs.myget.org/docs/how-to/use-tfs-online-git-with-myget-build-services
I want to use SubWCRev to include the SVN revision number as part of the version number in my project, but we're using TeamCity and it doesn't seem to include the .svn directories when it pulls the source for a new build. Is there any way to force TeamCity to leave those directories in place for the build? We're currently using TeamCity 6, but upgrading to 7 may be possible if it's necessary.
Just use agent checkout mode:
Agent-side checkout ... provides the ability to access version
control-specific directories (.svn, CVS); that is, the build script
can perform VCS operations
As Lazy Badger noted, you can use agent-side checkout. Also, when build is run in TeamCity even for server-side checkout you can get the revision used to update the sources from "build.vcs.number." build parameters (you can get the exact name using "completion" in the webUI when defining value for a new build parameter.
I Have managed to create a CI project that uses GIT as it's source control, and an MSBuild extension to label the assemblies based on the CCNet build label, and commit that changed label
I have other projects that are manually triggered to publish this version to particular sites etc.
I would like the project status in the dashboard to display the build label (eg 2.1.345.0) from the assembly, or from a built dll, so that we can easily see which revision was published at the last manual trigger.
There's plentyof info on updating assembly info for a build, but nothing on using a assemby ifnfo version for the displayed 'last build label'
Any Ideas anybody ? Do I need to create a task to manually update the state file ? that sounds a bit dodgy.
Thanks in advance
None of the built-in labellers does what you need, but you should probably be able to write your own custom labeller to that.
You can find two custom labellers with source code here and here to get you started.