I have a Visual Studio solution that contains 48 C# projects. Now, that I automatically want to version all projects, I just added the Nuget Package for GitVersionTask to all projects (Version 4.0.0-beta0012). When I build the solution locally, everything works fine. The freshly built binaries contain the version info generated by gitversion.
But when I try to build via our TFS build server then, it's doing something with the branches. Here is some squashed output from the build log:
2018-03-14T14:34:38.0434047Z UpdateAssemblyInfo:
2018-03-14T14:34:38.0434047Z INFO [03/14/18 15:34:38:04] Applicable build agent found: 'VsoAgent'.
2018-03-14T14:34:38.0434047Z INFO [03/14/18 15:34:38:04] Branch from build environment: refs/heads/sprint022/add-gitversion
2018-03-14T14:34:38.0590291Z INFO [03/14/18 15:34:38:05] Begin: Normalizing git directory for branch 'refs/heads/sprint022/add-gitversion'
2018-03-14T14:34:38.3402986Z INFO [03/14/18 15:34:38:34] One remote found (origin -> 'https://link-to-our-git-repo-on-tfs').
2018-03-14T14:34:38.3559076Z INFO [03/14/18 15:34:38:35] Skipping fetching, if GitVersion does not calculate your version as expected you might need to allow fetching or use dynamic repositories
2018-03-14T14:34:38.4652918Z INFO [03/14/18 15:34:38:46] Updating local branch refs/heads/sprint022/add-gitversion to point at e8d694a08080c8117b9c6cf93032c16057b05dab
2018-03-14T14:34:38.7621669Z INFO [03/14/18 15:34:38:76] Skipping update of 'refs/remotes/origin/3620_Error_Handling_Refactoring' as it already matches the remote ref.
...This last message "Skipping update of ... as it already matches the remote ref" is being repeated for EVERY branch that is on our remote repository. As this is quite a large amount of branches, this takes nearly one minute for one project in the solution. So, for the whole solution we would come near one full hour of time for this.
I already spent a lot of time researching for this, but I still could not find anything helpful on the web.
Does somebody have an idea why the TFS does this as part of the solution build, while the local Visual Studio build does not do it?
Related
I am new to the world of scripting with TFS2015. I created a script that builds all of the projects within my solution (it is a rather large solution) and puts it out in a shared folder (where each project has its own subfolder).
I would like to create a separate script for each project that simply copies the bin folder from the shared and pastes it out on my Test environment. I rarely need to deploy everything, so the idea is one build...multiple deploys.
However, when I run my deploy script using the Copy Files step it is doing another build. Although it copies the files that I expect, it is after a full build that creates the folder structure for the build.
Am I able to make the Copy Files step NOT do a Build?
Here is the steps that my script is curently doing:
As you can see, there is only one step (Copy Files) but it still does the Get sources and copies everything into a new folder on the build box like so (where the number keeps incrementing up with each run of the script):
I just want to copy the files from the Source to the Target and not do a build or Get Sources.
It looks like you're still on TFS 2015 RTM or Update 1. Which is already pretty old technology if you compare it to the lifetime of the new build system which was introduced with this version.
TFS 2015 update 2 has introduced a similar system to the Build pipelines to orchestrate Releases. This doesn't require you to map any workspaces or git repositories and can act on the artefacts of your builds or simply on the contents of file shares.
It makes sense that a Build has to build something and in order to build something, it has to get the things to build. If you're actually not building something, then you're probably deploying or releasing or packaging something else. Hence the distinction between Build and Release pipelines.
TFS 2017+ has an option to disable the syncing of sources. Primarily to allow people to get the sources themselves in creative ways (e.g. a custom powershell script that invokes git.exe).
My primary advice would be to upgrade to TFS 2018 update 3 or at least TFS 2017 update 3.1, worst case TFS 2015 update 4.1. The fact that versions older than update 2015.4.1 have a known XSS scripting security bug may be reason enough to convince your organisation to perform this update.
Barring that option you're left with one solution:
Link your build definition either to a git repository with only a single commit (If I remember correctly the 2015 agent still crashes when syncing an empty Git repo) or link it to a TFVC repository and set the workspace settings to cloak everything. This essentially causes the build to sync an empty folder, which it can cache, before calling your powershell script.
For one of our build definitions (Scheduled, from monday to friday, at 2:00 AM) we receive the following error message every night:
One or more of the steps defined in the build does not have an
associated task definition
Unfortunately no log is written. Manually queuing a new build works most of the time. The error occurs only for builds scheduled during the night.
I found a link:
https://github.com/Microsoft/vsts-tasks/issues/1170
but that link was not very helpful. They mailed to eachother and MS says they solved some caching issues. Not something we could do by our own.
So has someone the same issue and found a solution?
Additional inforamation:
We are using:
Visual Studio 2015 Update 3
Visual Studio TFS 2015
we are using 3 build servers, but before it starts on any of the build servers, it is already crashed.
There is no log wich can be downloaded: see picture ("Download all logs as zip" can't be clicked)
Only message we receive is: "One or more of the steps defined in the build does not have an associated task definition."
Source Version of failed builds is always "T". Source Version of successful builds is a number (int) -> most recent build has highest number.
Update 20160815:
We are using TFS 2015 update 2. Our architect has planned a meeting, to check if we can update to update 3, maybe the caching fixes from MS will do the thrick.
We have TFS 2015u3 with the same issues. We use scheduled builds and all builds (on 2 build agents) are crashing. As suggested in the GitHub thread I disabled SSH in the TFS Console. It works now again.
The source version "T" means the build agent are running tf get /version:T command which will get the latest version of your source code during build process. Please refer to tf get command for details:
Specifies the maximum version, or the minimum and the maximum
versions, to display in the history data. The default is /version:T
(the latest version).
According to your screen shot, the phenomenon looks like the build is not picked up by any agent. Another possibility is the build process hangs when obtaining the latest version.
You can set up a daily scheduled build to observe if there is such a phenomenon, and you can also go to the "_diag" folder in build agent folder and event view to check if there are any related the logs.
For me, this issue was a bug in SSH Service.
The fix was published by MS here:
https://blogs.msdn.microsoft.com/dstfs/2017/01/06/git-clone-ssh-ci-build-issue-in-tfs-2015-3/
I'm currently setting up continuous integration using TFS/Visual Studio Team Services (was VS Online), and I'm using the Team Foundation Build 2015 tasks. So not the XAML builds.
I'm using it to build a Xamarin Android project, but that's pretty irreverent I guess,
The process should be like this:
After a check-in:
TFS should download the sources
TFS should increment the version number within AndroidManifest.xml
I've managed to do this by making a PowerShell script for this.
After the AndroidManifest.xml file is modified, it should be committed back into the TFS repository
Then the rest, build deploy into hockeyapp etc
The first steps are all configured, but I'm struggling with the commit part. How do I get TFS to commit the file? I don't really see any task suitable for it. I've tried using the Copy and Publish Build Artifacts Utility - But that did not seem to work, and I'm not even sure if that's the right utility
I'm using the default hosted build agent btw. Any help would be appreciated
Warning
I do want to point out that checking in changes as part of the build can lead to some features of VSTS/TFS not working. Association of work items to the checkin, sources and symbol generation, tractability from changes to build to release and integration with Test Manager, remote debugging, will likely not yield the expected results because the Changeset/commit recorded in te build may not match the actual sources. This may lead to unexpected funny behavior.
Also, if any new changes have already been committed/checked-in after the build has started, the version number may be updated in Source Control for code that was not actually released under that version.
So: First of all, it's considered a bad practice to change the sources from the build process.
Alternatives
There are better ways of doing it, one is to use the build version (Build_BuildNumber or Build_BuildID variables). Alternatively you an use a task like GitVersion to generate the semantic version based on the branch and tag in your git repository. That way your build will generate the correct version number and will increment the revision in case the same sources are built multiple times.
I understand, but I still want to check in my code as part of the build
If these things don't work for you and you still want to check in the changes as part of the build, you can either use the TFVC Build Tasks if you're using TFVC or use the Git Build Tools to add the remote to the local repository and then use the git commandline tools to commit and push the changes back to the repository.
These extensions require TFS Update 2 to install. But you can push the individual build tasks using the tfx commandlien tool. For the TFVC tasks the process is explained here.
On mac
On the mac it's going to be harder since you're using TFVC. My TFVC tasks leverage the TFS Client Object Model and Powershell to communicate to the TFS Server. The tf.exe tool doesn't even work on windows when you're in the context of a build, which is why I need to call into the VersionControlServer object directly. Given I'm dependent on these technologies, the tasks won't run on a Mac or Linux agent.
You could try to see whether the Team explorer Everywhere X-platform commandline works from the build agent (using a shell script). I have no way to test this on an actual Mac.
Given the cross platform nature of your project I'd recommend to move to Git, it integrates into XCode and Android Studio, making it easier to do a native UI or build on top of native libraries.
Alternative 2
You could setup a build which does the required changes to the code and then checks in the modified code. Then have a (CI) build run the Android and the Mac builds using the modified code.
Hello i am trying to setup Jenkins to build my git hub rep, i have more than one branch, master and develop branch, they have the same code on it at the moment, and when i build my master branch and set up the archive the artifacts to /.ipa it builds and saves it just fine. I test my app and it works fine, but when i change my build branch to develop i get a error
ERROR: ‘/.ipa’ doesn’t match anything: ‘’ exists but not ‘/*.ipa’
to add i been working with this a few days so i am new with Jenkins, and if i did not explain this good , please say so i will try to give more details if needed, thank you.
It just means that the pattern you typed does not match any file in the Jenkins workspace. Reason for this could be that either you typed the pattern wrong (which is unlikely if it already worked) or maybe the workspace is currently empty. Try to trigger a build and see if it produces the file you want and archives it.
I am attempting to use CI on a Branch of one of my TFS projects. MSBuild only fails when I try to use a Branch. I point the same Build at the "trunk" project it works fine.
The error I receive from the build log:
Task "Label"
Label TeamFoundationServerUrl="http://TFSServer:8080/"
BuildUri="vstfs:///Build/Build/6763"
Name="Test_SF_20090619.1"
Scope="$/MyProject" Recursive=True
Comments="Label created by Team Build"
Version="BuildServer3D143_66"
Child="Replace" Files="$/" C:\Program
Files\MSBuild\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets(812,5,812,5):
error : No matching items found in $/
in your workspace.
Done executing task "Label" -- FAILED.
Done building target "CoreLabel" in project
"TFSBuild.proj" -- FAILED.
I believe this error is being caused by a lack of source files getting copied to the Build server.
Get task excerpt from build log:
Task "Get"
Get TeamFoundationServerUrl="http://TFSServer:8080/"
BuildUri="vstfs:///Build/Build/6768"
Force=True Overwrite=False
PopulateOutput=False Preview=False
Recursive=True Version="C204806"
Workspace="BuildServer3D143_66"
Done executing task "Get".
This is a full build. There should be about a thousand files listed in the GET.
General Information
TFS 2008
Visual Studio 2008
Established build server (been
running builds for the last year)
Project being branched is a ASP.NET
web stie (2.0 Framework).
Full Build Params
/p:SkipClean=false
/p:SkipInitializeWorkspace=false
/p:ForceGet=true
/p:IncrementalBuild=false
/p:IncrementalGet=false
note: I know IncrementalBuild is redundent but I just wanted to be sure.
Questions:
Are there restrictions on builds off a branch?
Any idea why MSBuild fails to pull files from the branch workspace?
If it's for CI then you're most likely doing an Incremental Get. TFS will only bother to get files it thinks have changed since its last get - e.g. if you delete any files from your server, it will still think you have those files so it won't get them again. In this case you'll need to run the build once with the incremental properties turned off so that it forces a full get of the source. You can do this by overriding the properties in the MSBuild command line box in the Queue Build dialog with:
/p:IncrementalGet=false;ForceGet=true
Another possibility that springs to mind is that the Label task is confused by your branch. It may be that your workspace is set up incorrectly, so check that you're mapping in everything it needs.
I had two issues in this case.
First, the branch security did not give rights to the build service account. I had restricted the branch to our team's Tech Leads and Release Engineers. The build service account needed access as well. What tipped me of was while searching the internet I stumbled upon a posting by someone who had made the same mistake.
The second issue was a little more involved. While cleaning up my build project file, I removed the following section.
<SolutionToBuild Include="$(BuildProjectFolderPath)/../../_stage/MyProject/MySolution.sln">
<Targets></Targets>
<Properties></Properties>
</SolutionToBuild>
Which worked fine on projects I had already built at least once, but if this was a new build, that had not copied source files to the build server, then there would be no files and the build would fail.
Some of you may wonder if my other builds were working either, after all wouldn’t they have old build files. Yes, but I had targets defined that did all the work I actually cared about. So the SolutionToBuild is a little frivalous.