Understanding how multiple local TeamCity build agents work together - teamcity

So far I have been using Travis and was quite happy about it (although it only provides Linux environments) however I am considering to give TeamCity a try and work with YouTrack as well. My current scenario is the following:
I have a project that consists of multiple applications and libraries that should are platform independant targeting Windows, macOS and Linux and bundled together for each of those platforms. Everytime I finish a feature branch and merge it to the development branch I need to manually pull the new changes, compile and run test suites on Windows and macOS separately.
I'd like to be able to push changes to the development branch and have the CI tool handle all platforms simultaneously. Therefore I noticed that I can setup an online TeamCity server (for example on DigitalOcean) and have a Linux build agent running besides it while having a Windows build agent on my local desktop computer and a macOS build agent on my (local) Macbook in order to let those machines use the local toolchains native to their systems.
First of all I'd like to know whether this is a feasible setup in general. I considered using Docker images of build agents until I noticed that a Windows build agent only runs on Windows servers and I'd have to configure the container myself with installing msbuild and such. Therefore I considered just using my local machines with their already setup toolchains as build slaves in this case.
Finally, I'd like to know whether TeamCity provides build queues or something similiar. What I am referring to is the following situation: I am on the train and finishing something on my Macbook and merge it into the branch. However my desktop with the Windows build agent is offline at the moment. Does it work through the queued commits/builds once I boot it up again?

Everything in your scenario seems feasible to accomplish with teamcity. You could have a set up with 3 builds all with the same trigger. Each build would have the build steps for a specific operating system. If you had all machines and agents running they would likely all be triggered at the same time and perform their builds in parallel.
I"m not sure what you are trying to say in paragraph 4 about the "windows build agents only runs on windows servers". Windows build agents can run on desktop versions on windows such as windows 7 or windows 10.
Yes, teamcity has a queue. If an agent is offline the build will be held in the queue until the agent is back online or the build is cancelled.

Related

Run Linux containers in an Azure DevOps Windows hosted build agent

I'm using Azure DevOps, and have a Linux build pipeline (ubuntu-16.04) setup that builds the code, starts containers with Docker Compose, then runs integration tests using the containers. This all works great.
Now I want to setup a Windows build pipline that does the same thing. However, with both the windows-2019 and win-1803 images, when I do docker stack up, I get this error message:
image operating system "linux" cannot be used on this platform
So, I guess Docker is installed in Windows mode, and thought to switch it to Linux containers using:
DockerCli.exe" -SwitchLinuxEngine
or
"%ProgramFiles%\Docker\Docker\DockerCli.exe" -SwitchLinuxEngine
However, the DockerCli.exe executable doesn't seem to be installed at all.
The only 2 things I can think of are:
Setup a self-hosted build agent
Somehow start the required containers somewhere else
But both of these will be a lot of work to setup, which I really don't need, neither do I want the running costs, or the job of maintaining it.
Are there any workarounds to run Linux containers on hosted Windows build agents?
Run Linux containers in an Azure DevOps Windows hosted build agent
Firstly, see the images listed which installed on Windows hosted agent: Docker images in Windows hosted agent. Docker EE on Server does not support Linux containers at all. So, it is impossible to build Linux docker image on Hosted Win-1803 agent. It can only build Windows docker image.
Until now, the only two workarounds is using self-hosted agent which based on Windows machine, or run a build which has two separate agent jobs(Pass the build artifacts back and forth between one agent job which run on Hosted Linux agent and the other is running on Hosted Windows agent) .
But since these two workarounds are all not convenient for you, there will not any other work around can achieve what you want.
In addition, there has a such suggestion feature raised on our official forum: Support for Docker with Linux Containers on Windows (LCOW) on hosted agent pool . You could vote and comment there, our Product Group team will review these suggestions regularly and consider taking it as Developer Roadmap. If this feature can be true, I think it will be very convenient to build Linux Container and without considering about which agent can only support.

Configure Hosted Macos image

Is there any way to manually configure a Hosted Macos agent in Azure Devops? I mean, download the agent, install several dependencies, applications, frameworks and utilities to build the application that I need and then upload this image to use it in my agent pool. As I can see, just only predefined agents with predefined softwares are available.
No, it's not able to do this. Software on Microsoft-hosted agents is updated once each month.
For detail software and frameworks on hosted Mac OS image you could refer this link.
Microsoft-hosted agents do not offer:
The ability to log on.
The ability to drop artifacts to a UNC file share.
The ability to run XAML builds.
Potential performance advantages that you might get by using
self-hosted agents which might start and run builds faster.
If Microsoft-hosted agents don't meet your needs, then you should deploy your own self-hosted MacOS agents.

How to run LibTool?

Currently I have tested my tool with clang-llvm installed on the machine I'm developing it on. All I have to do is go into build/bin to run my tool.
However, I now want to try running this tool on another machine.
What should I be doing here to run the tool I develop?
Do I have to setup the entire clang-llvm environment too? That's very time consuming and the entire folder is about 22+ GB in size..
The tool I'm creating is running RecursiveASTVisitor (same environment as the link below)
http://clang.llvm.org/docs/LibASTMatchersTutorial.html
Since you are just trying to run the tools on another machine, you can just transfer the whole llvm files and build files. IF you are running it on a different OS, you have to build the whole llvm and clang again as different OS (such as Windows) need extra tools such as cygwin .

how to check mac machine is busy with some taco build of cordova project on windows machine

My problem is that, I have 3 windows machines and 3 mac machines. I can make build on any mac machine using any windows machine using taco build command. Suppose Mac 1 machine is busy with windows 1 machine for making ios build. if windows 2 machine want to make build on mac 1 it should automatically switch on mac 2 or mac 3. Please let me know how I can do that.
I don't know if there's a great answer to this question. Here's just some suggestions - a couple things to consider:
Load Balancers - if you have the infrastructure in place, you can setup a load balancer to front the multiple different mac build machines. Then, point your windows machines to that load balancer.
Consider a third party solution like http://www.macincloud.com/.
Consider a third party build solution like using VSTS to build your source for IOS. https://msdn.microsoft.com/en-us/library/vs/alm/build/xcode/xcode-projects
Point your individual Windows machines to their own individual mac build machines.

Roadmap for Apache Mesos on Windows

I see that there is now an effort to make Mesos available on Windows (servers at least).
https://mesosphere.com/blog/2015/08/20/mesos-everywhere-apache-mesos-for-windows-server/
Does anyone know of updates/roadmap on this effort? I tried looking in https://github.com/apache/mesos/search?q=&type=Issues but don't see any issues for Windows support.
Mesos uses JIRA to track issues, that's why nothing shows up in GitHub. The Windows port is now very actively being worked on. There are two JIRA epics that track the effort:
Introduce CMake as an alternative build system.
Mesos on Windows
The plan is to first port the Mesos Agent. Once it's done, it will become possible to have a cluster with Master(s) running on Linux and Agents running on either Linux or Windows (or both).
The current implementation of CMake-based build system is pretty functional. It allows to rope in all the dependencies for building the Agent as well as produces the Agent binary. The work on porting Mesos build system tooling (post-reviews script, bootstrap script, etc.) is currently under way.
You could check out this thread http://search-hadoop.com/m/0Vlr6bGrJMIwE1j Alex reply his plan in this thread.

Resources