I am trying to get TeamCity to clear out the publish directory on a remote server AFTER a successful build on the build server. I want this to work like a clean checkout does on the build server. The workflow should be:
Checkout
Build
Clear Publish Directory
Publish successful build files to Publish Directory
In TeamCity 8.x, workflows like this can be done using the conditional-execute option on build steps within a config. Your "Clear Publish Directory" build step could set the "Execute step:" option to "If all previous steps finished successfully (zero exit code)". And similarly for build step 4.
Related
I have 2 configurations in the teamcity which refer to 2 separate repositories in the mercurial. When starting a build the project updates all its files. Can we configure 1 build agent to have 2 reprositories so that only the changes of the corresponding project are taken and not all files of the project at updated when starting the configuration? Or do we need to create 2 agents?
If TeamCity decided to clean checkout directory on an agent, it should log why this happens into the build log of the build.
Possible reasons of clean checkout are outlined in documentation: https://confluence.jetbrains.com/display/TCD18/Clean+Checkout
I am doing the following steps:
dotnet restore
dotnet publish
octopusDeploy: Push packages
The second step creates a 'published-app' folder and the third step is meant to take that and create a .zip file and send it to the Octopus server.
The third step is connecting to the Octopus server but gives the error:
Running command: octo.exe push --server http://server.com/ --apikey SECRET
Pushing packages to Octopus server
Please specify a package to push
I am following this https://stackoverflow.com/a/38927027 so my third step has:
%teamcity.build.workingDir%/published-app/**/* => App.zip
Any ideas why the zip file is not being created?
Not sure if you ever got this working for yourself, however just in case it helps anyone we recently came across the same issue deploying an AspNetCore 2.0 web application running on net471 being built by TeamCity 2017.1.4 (build 47070).
After some tinkering I noticed that the "OctopusDeploy: Create and Push Packages" build step ran at our git checkout root directory, so I ending up having to use the following values for the "Package path patterns"
%ProjectDirectory%/published-app/**/* => %ProjectName%.%GitVersion.NuGetVersion%.zip
NB: %ProjectDirectory%, %ProjectName% and %GitVersion.NuGetVersion% are build parameters we have manually defined elsewhere in the build process that TeamCity can replace. %ProjectDirectory% is simply the application's source directory relative to the root of the git checkout i.e. WebApplication1 so the full path would be <full checkout path>/WebApplication1
Another gotcha that we experienced was that at the time of writing the combination of TeamCity and octo.exe (from Octopus.TeamCity v4.15.10) didn't like creating nupkg files, so make sure you try to produce a ".zip" file. In the error instances we would receive the following error:
Error from Octo.exe: Cannot run program "C:\BuildAgent\temp\buildTmp\octo-temp\3.0\octo.exe" (in directory "C:\BuildAgent\work\4e62985fa616fa1f"): CreateProcess error=206, The filename or extension is too long
I've used Google and looked at the Docs but can't find an answer.
I want to trigger another build or a rake script to do some cleaning up of files after a successful build. I currently use Rake to do my build and pass in %teamcity.build.branch% to it.
I would like to know if I can pass the same branch name of the successful build to the triggered build or script. I can then use this to do some tidying up.
Thanks
In addition to finished build trigger, you need to add snapshot dependency, with "Run build on the same agent" option enabled. This way, cleanup will run after each build, on the same agent.
You then will be able to refer to original build's branch name using dependencies parameters:
%dep.<original_bt_id>.teamcity.build.branch%
i'm new to world of continuous integration and software developement.
I wanted to try hudson so i installed it on my ubuntu machine and created a new job. i pointed it to an open source project's svn (keepassx) just to try.
Hudson downloaded everything from the repository and marked blue for successful build.
aren't i suppose to be able to execute the software now somehow ? i thought once it is built i can run it, but i can't find any executable in the project's home page under hudson user home dir.
thanks.
A Hudson/Jenkins build breaks down into three steps:
update source code in workspace
run build
publish build artifacts
It sounds like you've got step 1 covered.
If the project you linked to has instructions for building (ant, maven, etc.), you can enter these as build steps into the "Build" section of the project configuration.
You can then take the resulting files ("artifacts"--jar, exe, so, bin, whatever) and publish these using the "Post-build Actions", or if necessary you can grab them directly from the workspace filesystem.
Assuming the build artifact was an executable, you could then run it after downloading it from Hudson, or make a build step or post-build action which moved it into the appropriate location and ran it.
It helps to run the build locally before trying to get Hudson to handle it--then you know what the build steps are, and what the final build artifacts are.
How would jenkins/hudson know how to 'execute' some arbitrary package that you told it to download and build? It's up to you to write a program or script to run what you want to run, and then make a downstream job (for example) to do so.
Is it possible to Trigger an exe to run on a failed build? Can you do this within Team City?
If you specifically want the failed builds, you can set up the dependent build as Eric said, and have that secondary buildscript use the REST API to pull up a list of the failed builds for the actual project.
If the latest build is in that failed builds list, then tell the build script to run the executable. If not, then you're all done!
http://confluence.jetbrains.net/display/TW/REST+API+Plugin
I don't think it's possible to trigger an executable to run only on failed TeamCity builds. TeamCity usually allows you to do things either always or only upon successful builds.
It would be possible to trigger an executable to run after this build is finished (failed or successful).
If that would work for you, you could set up a new build configuration that runs the executable. The new build configuration would have a "finish build" trigger. This would cause the executable to be run whenever the other build is completed.
You should add another build step with the exe you want to run and set the correct option to execute.execution options