I've got TeamCity installed and working, and I need to have a build step run on a particular build agent (everything's running on Windows, but we have a Mac portion I need to build as well).
How do I tell the build step what agent I want it to run on? I've seen this, but that references an entire build; I just want a particular step to run on a given agent.
Is this even possible?
From what I am aware of, it is not possible. You may want a separate build configuration to build for mac.
Sharma is somewhat correct, and KIR has it completely correct.
I needed a build configuration for each server, Mac and Windows. Then I set a snapshot dependency from the Windows build on the Mac build (to make sure the Mac version builds completely first) and a artifact dependency from the same (to copy the resulting build output from the Mac to the Windows box). Then I modified the build process on the Windows box to include the artifacts, and voila, works like a charm.
Related
I've recently installed TeamCity 2017.2.3 (build 541047) and Octopus Deploy 2018.1.5 and originally was having success running builds and creating packages in TeamCity, but now my build agent shows all of my build steps as incompatible after a service restart.
I've uninstalled and reinstalled the buildagent, plugins (I use Node.JS build runner, Octopus Deploy integration, and xUnit) and rebuilt each of the build steps, but still run into the same problem
Build Step List
Anyone know what would be causing this issue?
Each agent should have a list of global parameters that are picked up from the OS or manually configured from the agent properties file on the machine. These are things like the path, dotnet versions, npm etc.
http(s)://<tc root>/agentDetails.html?id=<agent id>&tab=agentParameters
(You can get to the above by clicking on the agent you want to inspect)
You can then override or add to these from the root project all the way up the project tree to the build configuration.
The message you are getting is saying is that in order for the build to run it needs to have an agent with those parameters configured. Could you give a screen grab of what your build agent parameters are.
Here is an example from one of my build agents which shows some of the configuration parameters that you need.
You should not need to add these, they should be picked up automatically by the agent.
First make sure these dependencies are actually installed.
If missing install and restart the agent service (required to pick up new configuration properties).
Possibly try a machine restart in case newly installed components require a reboot.
Failing that check to see what permissions the build agent service is running under. It might not have permissions needed to poll the system but I have never seen that.
I'm sure this is a dumb mistake on my part but I can't find the right answer.
I have a project that has a snapshot dependency on another project. For sake of discussion website is dependent on toolkit.
Monitoring the build folder:
c:\programs\Teamcity\buildagent\work
I see the toolkit get built and the folders all exist as expected:
c:\programs\teamcity\buildagent\work\toolkit
Then the website build kicks off and the folder above gets deleted before the website build starts.
This results in the website saying the reference couldn't be found. What setting am I missing?
Using TeamCity 7.1.2, working on getting it upgraded to 8.1 but it requires some internal evaluation first.
Don't think its a version issue. How do both of your builds know where to put the artefacts at . For ex teamcity normally builds stuff at c:\programs\teamcity\buildagent\work****\toolkit , not at c:\programs\teamcity\buildagent\work\toolkit ?
Also, if your targets are dependent upon each other across builds, (1) have you setup any artefact dependencies or (2) any process that does not read of a shared agent workspace ? or (3) forcing both builds to run from the same directory
See if both your builds are running on the same target "folder name". In case they are , deselect any option that "cleans up build targets" before they run.
Also, you might want to check your build files to see if they have any code to clean directories before they start to run
I'm having an issue with TeamCity, which relates to the fact that it runs the source control step before it runs the build steps. My project is a windows service, so there are complications with this.
TeamCity often decides to delete the entire contents of the project directory, even though I have the clean build option unchecked. However, since this is a windows service this does not fly, as when trying to delete the dll's it errors out since they're in use:
Error while applying patch: Failed to delete: F:\PathToService\bin\Release\Library.dll
The most frustrating part is that the dll's aren't even under source control, TeamCity seems to have a mind of its own and decides to delete them anyway.
Is there a way to get around this, to be able to run a build step BEFORE doing the svn checkout so that I can stop the windows service first?
I would try to set up your CI environment so it uninstalls the windows service once you are done testing it. I am not aware of Teamcity pre-checkout hook.
The answer was to split up each service into a separate working directory. That prevents teamcity from deleting the dll's.
Two parts to this questions.
1) As part of our Continuous Integration build process i would like to install everything as-if it were a virgin machine. Martin folwler paper: http://martinfowler.com/articles/continuousIntegration.html
Does he mean that we take each (integration) build (clean machine) and installing ALL the necessary software to make the build work? I'm guess this is what he meant by "Single Command" build.
2) Which leads me nicely onto the next question. Is it possible to install programs using Powershell/Dos all through the command line? For example how would I install WinRar and possibly MySQL? (Winrar being a easy example, MySql complex).
Anyways, I am interested to hear from real-world practitioners of CI and how they approach their build processes.
In the latest CI environment I built, I installed and configured the toolchains and SDKs under a single directory tree and then created an ImageX WIM image of the tree. Each clean build would then mount the image, checkout sources from version control, build them, run tests etc. When unmounting, just remember to not commit the changes back to the image so that the image file stays clean.
For each of our builds with Zed we ensure a completely clean working environment, but assume that the entire tool-chain and utility applications are already installed on the machine.
If you really want to go to the level of virgin machine, then I would agree with laalto and look into VM. Setup your VM library to represent the different build environments/configurations that you will need for your product set, and load/start them on demand as you require builds for different products.
I think it is very important to always build from a clean working directory, but I'd question the real value of always trying to start with a bare OS and install everything from scratch for every build.
In using our TeamCity Continuous Integration server we have uncovered some issues that we are unsure as to the best way to handle. Namely how to reference external applications that our application requires on the CI server.
This was initially uncovered with a dependency on Crystal Reports, so we went and installed Crystal Reports on the Server fixing the immediate problem. However as we move more applications over to the CI server we are finding more dependencies.
What is the best strategy here? Is it to continue installing the required applications on the Server?
Thanks
Where possible make the external dependencies part of your build system.
For instance check the installer in to your version control system and have a step that checks it out and runs it in silent mode (many installers support a mode with no user action sometimes using the commandline /s).
This way if you need to set up another build machine for a branch or just for new hardware everything is repeatable.
If your builds require the actual application to complete the build, then you should probably continue to install the application on your build server.
If you just need references to dlls or assemblies from the application, then what we've done at my company is to create installable 'SDKs' of the references required for a particular applicatoin and install them on our development and build machines in well-known library directories that our solutions reference.
On the build machine, our pre-build steps install the correct version of the dependencies and then clean them up when we are finished.
Recently, we've moved to using virtual machines for our build machines that our build process activates. These VMs get the SDKs installed on them as a pre-build, and then are restored to their snap-shot state after the build. We had some dependencies that were almost impossible to uninstall, so this made for a clean starting point each time.
If you use Maven to build, you can define your dependencies in the pom.xml file. They will then be automatically downloaded if necessary.
I am not sure if I followed correctly...
I am assuming your application is dependent on this external app, while building? In that case it should be on the machine doing CI...