I'm building nuget in TeamCity and would like to append suffix "-pre" to version number when build is triggered by a checkin. And when build is triggered manually, I'd like to be able to provide a checkbox if this build should be a preview release or production-worthy.
I've got a Configuration Parameter created like that:
In this case I always have -pre added to the version number, even if I trigger the build manually and don't check the checkbox.
If I remove the value -pre from the default value of the parameter, then checkbox prompt works as expected. But when my build is triggered via a check-in, the system does not give me -pre suffix and I end up with a production release which should only be created manually.
Any way to implement what I need?
Alternatively I only want to publish nugets only on a manual trigger of the build and don't really care about pre-releases, but I can't seem to find any way to check if the build was triggered manually or via a check-in.
The first part is relatively easy, using a step to check the value of the checkbox and set a parameter based on it - Here I've used powershell but this could be done in bash (I've assumed powershell as you're producing nuget packages)
Note that I have reversed your logic a bit, but it produces the outcome you desire.
Define two varibles
Setup the checkbox
Setup two build steps
In the first step, test the parameter and use it to set another parameter
In the second step I'm proving the value has been set correctly
You should be able to use %ReleaseSuffix% when you need it.
Regarding your second requirement, I'm again going to make an assumption that you only want to publish a nuget package based on it being a Release build rather than a Pre-Release (if I've assumed this incorrectly let me know)
Conditional build steps based on a parameter value are something I've been tracking for a while now on YouTrack. This has been requested since 2011, but has still not made it in as a feature. I made this comment back in 2014 as a work around, but don't have the Java skills (you might) - My comment on YouTrack Issue
There is an alternative way to get this working, that might require some reworking of your build configurations.
If your "Publish NuGet" step is not triggered by anything (assumming it's triggered by the previous build finishing) then you could have a build step that
Checks the %ReleaseSuffix% parameter
Calls the REST API to trigger the build to publish the NuGet
It would potentially look something like this - just ensure you replace the highlighted bits
TeamCity Documentation
Hope this helps
Although the accepted answer here is very good, it does have a flaw; you will not be able to use the Assembly Info Patcher build feature, as this executes before the first step. Unless you wish to chain your builds together, setting the version in the first and using that in the second (yuck).
I have managed to find a solution which should give you the same results by tinkering with the parameters, setting them as follows:
The reason for using the "EmptyString" parameter is because without it, checked value defaults to "true".
I have tested this with manual triggers (release & prerelease) and VCS triggers (prerelease only), all functioning as expected on TeamCity v9.0.3 (build 32334).
Related
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 writing a unified project for 3 smart TVs. I have also 3 configurations created in Visual Studio. Now I want to execute some CLI scripts depending on selected configuration.
The problem is in new ASP.NET 5 project I don't have an editor for post build events.
I know I have to do this in project.json. What I found is:
"scripts": {
"postbuild": ""
}
But using this one I can't create different CLI scripts for different configurations.
I found also:
"configurations": {
},
And I guess this is probably what I want, but... How to use it? Intellisense has no power here and also I wasn't lucky searching the Web...
[edit]
Maybe I should try with .xproj?
You'll need to build a master script which uses the available context and environment variables to switch and run the other scripts of your choice.
In addition to the list of variables Here for compile, you also get these for publish related scripts and then these are available everywhere, as are environment variables returned by Environment.GetEnvironmentVariable, which can be seen here.
The image below shows the intellisense from the VS2015 Update 3 RTM, but it's misleading, since you get others depending on the script block you're using:
So, your full list of context variables that you can use to control flow in your scripts is:
Every script block:
%project:Directory%
%project:Name%
%project:Version%
Compile specific:
%compile:TargetFramework%
%compile:FullTargetFramework%
%compile:Configuration%
%compile:OutputFile%
%compile:OutputDir%
%compile:ResponseFile%
%compile:RuntimeOutputDir% (only available if there is runtime output)
%compile:RuntimeIdentifier% (only availabe if there is runtime output)
%comiple:CompilerExitCode% (only available in the postcompile script block)
Publish specific:
%publish:ProjectPath%
%publish:Configuration%
%publish:OutputPath%
%publish:TargetFramework%
%publish:FullTargetFramework%
%publish:Runtime%
I investigated on this a bit but did not really get to any good result.
There are some project variables that are exposed in scripts. Unfortunately, those are very limited:
%project:Name% gives you the project name
%project:Directory% gives you the project directory
%project:Version% gives you the project version
So there is no way to access the build configuration or the environment here.
The configurations option in the project.json is also limited to build configurations and only allows declaring compilation options there, so that also doesn’t work.
Unfortunately, there also doesn’t seem to be another way to solve this. At least not right now. I would consider myself sending a pull request to DNX to add some additional project variables which one could use but at the moment, it doesn’t really make any sense to invest time into DNX: After all it’s being replaced by the dotnet CLI. We’ll see if that one will come with functionality to access the environment—and if not, I might end up submitting a pull request to add this functionality. But until we get there, I’m afraid there is no solution for this.
The AssemblyInfoPatcher build feature isn't working. Some files are patched and some are not.
Assembly file version was specified, but couldn't be patched in file D:\TeamCity\Agent\buildAgent\work\6afd998e316c631f\La\Di\Da\Properties\AssemblyInfo.cs. Is necessary attribute missing?
I thought it was because it was 1.0.* since one of the failed files had this format, and one of the successful ones had the default 1.0.0.0 format, so I changed the attribute to 1.0.0.0 across the entire solution and now none of them work.
I get either the error above or:
Assembly version attributes were not found in ...
The attribute is defined and at least two other people on the team have confirmed that they can also see it using their production eyes.
Happy to stump up the cash so I can smash my work keyboard.
Well, I managed to get it working but not.
I had a Configuration Parameter called AssemblyVersionStringWithCounter that I set from a PowerShell script. I was using this in the patcher feature.
I changed it to be composed of other parameters like
%MajorVersionNumber%.%MinorVersionNumber%.%BuildWeek%.%build.counter%
And now it mods the files but the params are not set, the version is incorrect. Seems the AssemblyInfoPatcher cannot use values set during the build steps.
Seems I've wasted about £800 of my client's money when I should have just PowerShelled it from the start. Code is King.
How can I tell whether a solution needs to be built (meaning, a change was made since last build)? I use the Solution4 Interface
This related question has the answer you need, with examples
How to get notification when a successful build has finished?
"to figure out when a successful build has finished, you need to use a combination of the two build events:
OnBuildProjConfigDone and OnBuildDone"
In addition, you can also use
Solution4.Saved property
to check if the solution has changed since last successful build.
You should assume that on open, a solution needs to be built.
I am using a custom process parameter for a build which is a simple enumerator. That enumerator is located in my repository as a library and referenced in the Workflow arguments. That dll is imported from my repository (import tab of the workflow) and everything should work fine.
The strange thing is that every time I change the enumerator, compile the dll and check-in it, somehow it still keeps the previous old version as a kind of cache and I have no idea of how to refresh it. I change the version of the dll every time just in case with no success. If I take a look at the repository dll by reflector it contains the last version of the new enumerator. Does anyone know how to refresh it in order to show the last version into the build definition process parameter?
I sorted it out restarting Visual Studio. It was the only way to refresh that source of data, due to other ways didn't work (Team explorer refresh button, check-in the workflow and library, etc).
I realized of that when other group member was able to see the last enumeration on its machine. I don't know whether there is a better way to solve it or not, but this workaround is a bit frustrating...