I am using TFS 2017 on-premise.
I have a team project (call it "proj1") which contains the code and the build.
I have another Team project(call it "releases") which contains no code but it contains all the releases of all the different team projects (proj1,proj2...). each release process is connected to an artifact from a build (e.g. proj1)
Everything works as expected except the "Commits" Tab which says "build definition XXX was not found". XXX is of course the definition number of the build in the origin team project (proj1).
Is it a bug a feature or any idea how to bypass this?
That is because the build definition is not in the current team project.
Build and release on different Team-projects is not the Normal/Recommanded behavior.
So, just as Daniel said "Keep everything related in the same team project"
However, if you insist on that, then you can try retrieve the build definition information by calling the REST API (Definitions - Get)
Related
We just upgraded from TFS 2013 to TFS 2017 and I was excited to go in and create a new build definition, but I can't seem to do it at the collection level. I can only create a new build definition once I've selected a project and then when defining the Get Sources page I can't seem to access other projects within the collection. The highest level it will allow me to get is the current project. In the Repository drop-down the only option is the current project. How can I create a new build definition across projects in TFS 2017?
The TFS build is project level for now, it's not able to create a build definition at collection level and across projects. For 2015 you could, instead of using the trigger path '$/{team project}', also insert just '$/', which would result in that the continuous integration build triggers on all check-ins in that team project collection. It's more like a backdoor.
However, In TFS 2017, it 's no longer possible to freely edit this field, and that you can only add a trigger for the team project that the build definition resides in.
There had been a uservoice and got started:
VSO build vnext: share build templates between projects
https://visualstudio.uservoice.com/forums/330519-visual-studio-team-services/suggestions/8468566-vso-build-vnext-share-build-templates-between-pro
As a workaround you could export your existing build definition in the project to other project. However, this just avoid you manually duplicating the definition in another team project. It's not able to get source from another project which different with the build definition belongs to.
There is an Export/Import Build Definition extension in Visual Studio Marketplace you can use now. Also available from within the TFS2017 update1 Build Definitions web UI:
.
Is there a way in TFS 2012 to set Project (not .csproj projects but TFS projects) build priority?
Currently we have many projects in TFS, one of which is a core project that many other projects reference. If someone checks in changes to both core and another project at once, the core project build doesn't always kick off first (I think they build in alphabetical order). It would be nice to be able to set the core project as the highest priority so that its build always runs first when changes to multiple projects are checked in. Is this possible?
There is no way to set the default build priority for a Build Definition. Since a Build Definition isn't bound to a Team project, but to a collection, there is also no way to configure the Queue to pick up builds from one Team Project before any others.
What you can do is to set a tag on an agent and then assign that tag to the build you want to take precedence. This will exclusively reserve the Build Agent to that specific build definition, causing it to jump in the queue.
Is there a way in TFS 2012 to set Project (not .csproj projects but TFS projects) build priority?
A project in TFS is quite a loose term which does not correspond to a VS project, it's actually used to refer to a product which can contain many branches. The high level project management tools then operate on the TFS "project".
If someone checks in changes to both core and another project at once, the core project build doesn't always kick off first (I think they build in alphabetical order).
Nope, assuming you don't have a custom build then they (the VS projects) don't build in alphabetic order at all, they build in order of dependency. Solutions are built in the order they are returned from the evaluation of the $(SolutionsToBuild) property (this does a wildcard search of the filesystem for .sln files, so maybe that's where your alphabetic observation comes from). Note that dependencies are evaluated on projects within a solution, there is no evaluation of dependencies across solutions.
For the following statements I'm going to assume that you have standard CI style builds gated upon checkin.
If a developer checks in everything at once then the checkin will happen as an atomic unit of work and the build will commence once the checkin is successfully committed. If this is not your experience then I would suggest that you either have funky stuff happening in a custom build, or the developer is checking blocks of work in separately rather than all at once.
Note that this happens per checkin per workspace - if two different developers check stuff in at the same time then whoever checks-in first will trigger the build, and the submission of the second developer will miss the build.
We have a build definition in TFS 2008 that builds one of our solutions on request (not using CI) and this works fine.
I navigate to the Build Explorer for this definition and double-click a completed build to view the summary. In the summary I expand "Associated changesets" to examine the list of changesets that were committed between the previous build and this one.
On close inspection, it appears that TFS simply lists all changesets between the two builds regardless of whether they were part of the solution being built or not.
Is there something wrong with our configuration, or is this simply how TFS works?
I believe it shows all changesets that were checked into somewhere in the workspace associated with the build definition. If you are seeing unrelated changesets, you might want to try narrowing your workspace for the build definition.
Currently we have a team project setup like below (in regards to branches)
Team Project
|__Developement
|__Development - Isolated Feature Dev
|__Main
|__Production
The issue that i have, is that when we want to do a team build on the production branch solution, it copies the entire team project down to the build server (so 4x copies, 1 for each branch) As the project is rather large, and the other branches are not required to be built, i'm wondering if there is any way to only build the single branch required?
When you configure the build, on the workspace tab, choose the correct branch in source control.
If you only want to check out the Development branch, configure the build to check out
$/Team Project/Development
If you want to check out a particular folder, but not sub-folders, you can 'Cloak' the sub-folders. Right click on the build from Team Explorer, chose "Edit Build Definition", and click the 'Workspace' tab.
From there you can cloak/add as many folders (branches are just folders) from as many places as you like
I have a Team Foundation Server 2008 Installation and a separate machine with the Team Build service.
I can create team builds and trigger them manually in Visual Studio or via the command line (where they complete successfully). However check ins to the source tree do not cause a build to trigger despite the option to build every check in being ticked on the build definition. Update: To be clear I had a fully working build definition with the CI option enabled.
The source tree is configured is a pretty straight forward manner with code either under a Main folder or under a Branch\branchName folder. Each branch of code (including main) has a standard Team Build definition relating to the solution file contained within. The only thing that is slightly changed from default settings is that the build server working folder; i.e. for main this is Server:"$\main" Local:"c:\build\main" due to path length.
The only thing I've been able to guess at (possible red herring) is that there might be some oddity with the developer workspaces. Currently each developer maps Server:"$\" to local:"c:\tfs\" so that there is only one workspace for all branches. This is mainly to avoid re-mapping problems that some of the developers had previously gotten themselves into. But I can't see how this would affect CI.
UPDATE: Ifound the answer indirectly; please read below
Ok I have found the answer myself after several dead ends. In the end I fixed this unintentionally while fixing another issue. Basically we had just turned on the automatic execution of unit tests for our builds. The test would run sucessfully but then immediately the build would bomb out with a message saying it was unable to report to the build drop folder.
What was happening was that while the Build service runs under one account and has a set of rights; some of the functionality is actually driven through the TFSService account. fter wading a heap of permissions I had my tests being reported. Then I noticed that builds had started to trigger on check-ins; I can't tell you exactly which permission fixed this but hopefully this answer will at least set people down the right path.
One other note a few of the builds started failing due to conflicting workspace mappings - this was a separate issue that I resolved by deleting some obsolete workspaces using the Attrice Sidekicks for Team Foundation tool.
Hope this helps somebody else.
Select your team project from team explorer, then right click on the Builds folder. Select a new build definition and then select the trigger tab. Move the radio button to "Build each check-in (more builds)"
More info can be found here
MSDN How to: Create a Build Definition
Are there any errors in the log on the TFS application server? Anything that indicates that it tried to fire but failed?