I want to setup continua ci with octo deploy. In the past I was able to do it. but now with newer version of octodeploy it seems difficult
First continua didn't find a matching agent because the Octo.Default.Path wasn't resolved. I found out that it searches an octo.exe
but in the current octodeploy there is none
So I changed it to point to the octo.server.exe
Now the build starts but it gets a "ressource not found" response.
So i'm not sure i
The only documentation I can find is from 2014
Does somebody know if my change in the path is correct or even better if there is a more current documentation?
The Octo.Default property collector in Continua CI is looking for the Octopus CLI executable. This needs to be installed on the agent, and added to the PATH of the Continua CI Agent service user, for the property collector to pick up the executable. The Octo.Default property collector is used for the Octo Pack and Octo Push actions. These actions are not required if using the MSBuild actions and Octopus Deploy build event handler as described in the blog you linked to. See also my reply to your forum post.
Related
I've asked this question on Gitter, but answer directed me to the documentation I followed.
I'm administrator of TeamCity 2017.2.2 with agents running on Windows 10 (except one on 7). I installed allure-teamcity plugin version 2.6 and added allure tools in version 2.6 as described in the documentation.
The problem is the tool is propagated to the agent on upgrade, but not the plugin itself. Main server shows me the runner I can use as a build step, but once configured none of agents accept this configuration. I've checked agent directory and logs - the plugin is not there and logs doesn't indicate that there was even attempt to pull.
As a holder of commercial license I asked JetBrains technical support, but they told me I need to ask Allure authors. GitHub sends people to Gitter and here, hence the question after unlucky attempt on Gitter.
What do I need to do to get the plugin correctly pulled and working on agents?
Is allure plugin even compatible with TeamCity 2017.2.2?
The problem is that Allure TeamCity plugin looks for a tool called allure-commandline. So you need to make sure that allure-commandline.zip is present in your <TeamCity Data Directory>/plugins/.tools directory.
I am using TeamCity 8.1.3 and have one task in the build queue and compatible enabled agent.
In "Build Queue" teamcity says that task "Can run on" - "2 agents"
Both agents are idle.
I tried to reinstall teamcity, reinstall buildAgent and install agent on another machine.
Tried to run agent as root. I read all agent logs and didn't find any errors; only warnings for not installed VCS tools (i need only git and its installed - no warning for it).
Why wont the agent run my task?
If the VCS tools aren't installed then TeamCity can't pull down your code and run the agent.
From the TeamCity documentation http://confluence.jetbrains.com/display/TCD8/Git+(JetBrains):
Git support in TeamCity is implemented as a plugin. Git needs to be installed on the server machine and, if the agent-side checkout is used, on the agents.
and
[Build configuration] will run only on the agents where git was detected or specified in the agent properties.
So you need install git.
This page covers installation instructions for Windows, Linux and Mac: http://git-scm.com/book/en/Getting-Started-Installing-Git. This SO post discusses installation as well: Git for beginners: The definitive practical guide
I can see two possible reasons
One of the implicit requirements not fulfilled. You need to check the enqueued build info for this, it tells why exactly the build is in the queue with compatible agents but not running. Examples can be: limitation on simultaneous builds in build or template configuration, shared resources unavailable etc. This would be listed in the little popup next to the enqueued build label
I've seen this happening when a requirement wasnt fulfilled initially (I had build configuration limited to 1 build at a time) when the build was enqueued, then it was corrected but the queue cached this requirement. Re-enqueuing the build sorted that.
Hover by mouse cursor to your VCS engine (e.g. git) and maybe you'll see there this message:
Changes have not been collected yet
In that case check performance of your TC and vcs server. (this I just guess from the message)
I have the following set-up:
TeamCity server running on one machine
TeamCity agent on a separate machine, connected via VPN to source control (TFS).
The VPN is a bit tricky to set up to run as a service so can't/don't want to set it up on the server as well. Rather, I was hoping to have everything go through that agent.
The build server fails while collecting sources, it appears it's trying to figure out what changes were performed in TFS (but it can't find the TFS host since it's not on that VPN). The build is set to check out the sources only on the agent.
I'm afraid the answer is obvious, but couldn't find any documentation confirming this...Is it possible to have such a setup? Or does the build server need access to the TFS repo to check for changes and trigger builds?
The TeamCity server will still require access to the VCS root to evaluate the current revision and changeset details.
It's important to note the additional side-effects of agent side checkout as well. See VCS Checkout Mode in the TeamCity docs for more information (note the 2nd line).
I have set up a build step on TeamCity,as described here, to do automatic release deployments to our test server. But it is not using the latest nuget packages that was build in TeamCity.
Use Case :
Teamcity will create nuget package with version 1.0.0.9, all the dlls that is in the package is the correct version, and the Release in Octopus, that was deployed has got the same version number , but the packages that octopus uses is of an earlier package eg 1.0.0.5.
I have specified the --force parameter on the build step so it should use the latest packages but it is not.
If I manually create a release in Octopus, and select the latest packages it is working 100%
Please can someone tell me if I am missing something.
thanks in advance
I think what you need to do is create two build configurations in TeamCity, one to build and one to deploy with Octopus. Refer to this link that has a small blurb toward the end:
Note that NuGet packages created from your build won't appear in TeamCity until after the build completes. This means you'll usually need to configure a secondary build configuration, and use a snapshot dependency and build trigger in TeamCity to run the deployment build configuration after the first build configuration completes.
So in my case I created 2 build configurations, then setup a snapshot dependency from the build to the deploy config and also a trigger to kick off the deploy after a successful build.
It looks like --force is just to force packages to the be re-installed if they have already been installed. Are you using the --packageversion parameter?
My organization uses Jenkins CI. We use the unique build number as our package version and then deploy that specific package version using the --packageversion paramater.
In the case where we have multiple services that need to be deployed. We have an upstream job / main job that provides the unique build number.
I'd imagine you can do the same thing with TeamCity
Master Job (unique build number) calls jobs A and jobs B with parameter (unique build). Jobs A and B build version (from Master Job). Jobs A and B complete then publish their respective versions.
It could be a few things.
Check out.
http://octopusdeploy.com/documentation/integration/teamcity
You haven't mentioned how your consuming the feeds from Octopus in Teamcity. I would start there.
Next I would use the teamcity action to do your deploy. You asked "Where should the --waitfordeployment flag be added" there is a check box to make sure the deploy has worked before the action can continue.
In TeamCity I use a Octo Push Packages step and in the Additional Parameters field I specify the --defaultpackgeversion {VERSION} parameter.
This will force Octo to use a specific version of packages instead of just choosing the 'Latest Version'.
There are more possible reasons for the problem.
To see the problems with Octopus go to Configuration -> Diagnostics
Another common problem is to use a Package Name #{variable} in a deploy step
Currently it is not possible and Package Name should be set manually, for example MyWebSite or MyWindowsService. See UserVoice for this feature.
We're currently using CruiseControl.NET as a continuous integration server for a number of ASP.NET web projects, but we're also evaluating TeamCity.
This is working great for our build server.
What we'd like to setup is a customer facing test server. I'm thinking that when we are happy for our latest development version to be released to the client for test, we could label it in SVN.
I'd then like a second build server to build this version ready for the client to see.
The question is this - is there any way to get either CruiseControl.NET or TeamCity to build only the latest labelled version of the code in a repository?
If anyone has any alternative suggestions, that'd also be greatly appreciated!
You could have a designated location or branch in your subversion repository e.g. \release then point the second TeamCity build server at that.
When your are happy with trunk then overwrite the existing location. The second build server will pick this up, build it, and even deploy it to a test server.
I don't think there's a way to do this directly in TeamCity. You can however configure your build trigger to filter on files and/or users. So, if you touch a given file to indicate release status in addition to or rather than labelling, you can use that.
The trigger filter could be, for example (untested):
+:/ReleaseVersion.cs