For example, this is one such output:
The lines are wrapped and indented. I can only assume that octo.exe faithfully outputs what it receives from the Octopus Server.
So, the question is - how can we configure Octopus Server to stop this annoying wrapping and indentation?
Please, note that the Octopus process in question contains a lot of steps and so suggestions to modify all the steps are unacceptable.
I am looking for some kind of a change to be done in a single place, maybe the Powershell $PROFILE script or some kind of a configuration in Octopus itself.
Related
We are having to use the command configuration (to be able to specify the runsettings file that I want to use at the time of running the job) for vstest.console. But now it does not create the results within bamboo. like the vstest.console bamboo task does.
First question, does the mstest parser create that kind of results? Is there a way to do this after running the command prompt. Also, since they both create trx files, can I use mstest parser for the trx created by vstest.console?
Second question, I don't see in my log that it kicked off that step. Is there anything special I need to do to have it kicked off? Especially if the previous step fails?
Also, the .trx logger setting is not renaming the trx to my TestResult.trx file name.
I looked in the list of apps to see if there is a vstest.console version of the parser, there is not. We are using version 6.6.3 ..so we are a bit behind but not sure if this means anything with the parser.
Must have had to do a reboot. I don't know why, but I came back in after the weekend, and the servers have been rebooted, and with no change to what I said above, the results are showing up as expected.
Using TeamCity version 2017.2.3 (build 51047).
I have a SMB Upload build step and would like to upload the builds from the default branch to a different location than all other builds.
I seen the following variable that will tell me if its a deafult build %teamcity.build.branch.is_default% however im not too sure how or even if its possible to specify conditional Target URL for the SMB Upload step.
Either with some form on IF block, or ternary statement inline.
Non of this is done using PowerShell. All through the UI, i would prefer to keep it that way if possible. Our old TeamCity install saws essentially just a glorified PowerShell script runner and grew into this un maintainable monolith, besides PowerShell is a rather terrible language.
Essentially what i would like would be builds on any branch going to
//DataStore/builds/my-api-%build.number%.zip
Whilst builds on the default branch go to
//DataStore/builds/default/my-api-%build.number%.zip
Any help would be appreciated thanks.
In general, this is not possible. The SMB Upload runner doesn't let you specify a condition anywhere in it.
If conditional steps were possible, you could create two steps: Upload from default and Upload from non-default, each with a different Target URL. It turns out that conditional build steps are the most voted-for feature in TeamCity, see this ticket, yet JetBrains are quite opposed to the idea. You may want to vote for the ticket, or at least monitor it.
There is one thing that you can do, other than Powershell. The Target URL field expands variables. (You can tell this by typing a percent sign in the text field: TeamCity immediately starts suggesting variable names. Compare this with the Step name text field above: that has no variable expansion.) Thus, you could enter a Target URL in this form:
//DataStore/builds/%teamcity.build.branch.is_default%/my-api-%build.number%.zip
That way, you'll end up with files being uploaded as
//DataStore/builds/true/my-api-1234.zip
//DataStore/builds/false/my-api-1235.zip
Now that's kind-of ugly. You can improve it in two ways:
1) create symlinks or junctions on your file server (on the directory/filesystem level), so that the above are accessible to the clients as
//DataStore/builds/default/my-api-1234.zip
//DataStore/builds/my-api-1235.zip
2) even better, you can set up a variable that will either contain the value "/default" or "". Then you can change your Target URL to //DataStore/builds%myCleverVariable%/my-api-%build.number%.zip. To do that, you'll need an extra step before this one, a Powershell runner, that will test the value of %teamcity.build.branch.is_default% and set %myCleverVariable% accordingly, using TeamCity service messages.
The conditional build step feature has been implemented in TeamCity 2020.1
I'm using an Octopus custom template with a powershell script to delete old deployments by age or by count. However, it relies on running after an actual deployment step, so that it can access the output variables of that step. For example,
DeploymentFolder:
#{Octopus.Action[Deployment Step Name].Output.Package.InstallationDirectoryPath}
This works great when, for example, you haven't run out of disk space. However, it doesn't work so well when disk space is low (since you didn't have this step running before) and Octopus can't deploy a new version due to the low disk space condition, thus you can't run the delete old files step. (I know one can change the Octopus parameter for what's considered too little disk space, but I'd rather not do that.) This additionally has a problem where if you want to enter a hardcoded path (say you're experiencing a temporary problem with your script and just need to delete a bunch of old deployments, but don't currently have the permissions needed to delete them manually from the server), it's too easy to accidentally leave off the final version-number-bearing folder and have the underlying script get confused.
Is there some way that I can get the deployment folder for the current environment, and combine it with my NuGet package name (and whatever other parts are in the deployment folder name), so I can work out the expected deployment folder in advance?
The actual deployment folder being used is E:\Octopus\Applications\LifeCycle\NugetPackageName.
I think I can get the NugetPackageName with $OctopusParameters['Octopus.Action[Deployment Step Name].Package.NuGetPackageId'] (though I am not sure, as Octopus.Action.Package.NuGetPackageId is listed as an "Action-Level Variable", and thus may not be available in advance of the step running. I'd be willing to hard-code the NuGet package name if I had to.
About the LifeCycle part, I don't know if that is actually a LifeCycle name. It may be a coincidence that it matches. I'm not sure. For the life of me I can't figure out where this comes from.
I also can't figure out where E:\Octopus\Applications\ comes from, so that I can get this value automatically instead of hard-coding it.
This variable will be available at the start of the deployment:
$OctopusParameters['Octopus.Action[Deployment Step Name].Package.NuGetPackageId']
You can get E:\Octopus\Applications\ from an environment variable called TentacleApplications:
$myRootDir = $env:TentacleApplications
I am fairly new to TeamCity and have recently been tasked with creating various builds, which I have done with no real issues.
What I am trying to do now though is include an external text file into the build output.
The external text file will be received from a service call made during the build.
These are my intended build steps:
Check out solution.
Restore packages.
Run tests.
Call web service with a configurable parameter and receive text file back.
Include text file in build.
Deploy.
Steps 1,2,3 and 6 are covered.
What are my options here? I must confess I do not really know where to begin.
I've spent some time today googling but it has been tricky getting the correct search term to return information on what I am trying to achieve.
I've seen some confusing articles on a 'meta runner'.
Any pointers to get me started in the right direction would be much appreciated.
Thanks.
Use a TeamCity command line build step - https://confluence.jetbrains.com/display/TCD9/Command+Line
I assume you are using build steps for all the other steps you listed so this is simply another of those.
The command line process would run somewhere under your checkout folder and thus anything it downloads would be made available as an artifact for your build
I have some Issues regarding Jenkins and running a Powershell Script within. Long Story short: the Script takes 8x longe execution time then running it manually (takes just a few minutes) on the Server(Slave).
Im wondering why?
In the script are functions which which invoke commands like & msbuild.exe or & svn commit. I found out that the script hangs up in those Lines where before metioned commands are executed. The result is, that Jenkins time out because the Script take that long. I could alter the Timeout threshold in the Jenkins Job Configuration but i dont think this is the solution for the problem
There are no error ouputs or any information why it takes that long and i do not have any further Idea for the reason. Maybe one of you could tell me, how Jenkins invokes internaly those commands.
This is what Jenkins does (Windows batch plugin):
powershell -File %WORKSPACE%\ScriptHead\DeployOrRelease.ps1
I've created my own Powershell CI Service before I found that Jenkins supports it's own such plugin. But in my implementation and in my current jobs configs we follow sample segregation principle rule: more is better better. I found that my CI Service works better when is separated in different steps (also in case of error it's a lot easy for a root cause analyse). The Single responsibility principle is also helpful here. So as in Jenkins we have pre- & post-, build and email steps as separate script. About
msbuild.exe
As far as I remember in my case there were issues related with the operations in FileSystem paths. So when script was divided/separated in different functions we had better performance (additional checks of params).
Use "divide and conquer" technique. You have two choices: modify your script so that will display what is doing and how much it takes for every step. Second option is to make smaller scripts to perform actions like:
get the code source,
compile/build the application,
run the test,
create a package,
send the package,
archive the logs
send notification.
The most problematic is usually the first step: To get the source code from GIT or SVN or Mercurial or whatever you have as version control system. Make sure this step is not embeded into your script.
During the job run, Jenkins capture the output and use AJAX to display the result in your browser. In the script make sure you flush standard output for every step or several steps. Some languages cache standard output so you can see the results only at the end.
Also you can create log files that can be helpful to archive and verify activity status for older runs. From my experience using Jenkins with more then 10 steps requires you to create a specialized application that can run multiple steps like "robot framework".