After some unexpected changes on the Cruisecontrol.net buildserver the artifacts directories were gone, and the build labels were reset on all projects. How can I change the build label value on the projects? We are using CCNetLabel variable in our scripts.
I tried updating the .state file with no success. it just overwrites the values on the next build. Also tried manipulating the latest log file in the artifact directory
You can use the <initialBuildLabel> value to set it in your .config file. This documentation for the Default Labeler gives more detail, but here is their example:
<labeller type="defaultlabeller">
<initialBuildLabel>1</initialBuildLabel>
<prefix>Foo-1-</prefix>
<incrementOnFailure>true</incrementOnFailure>
<labelFormat>00000</labelFormat>
</labeller>
I think this is what I did in my build config when I needed to do this, but have since removed it once it got going at the number I wanted.
Related
In TFS the Build number format usually looks something like this:
$(BuildDefinitionName)_$(Date:yyyyMMdd)$(Rev:.r)
However, I only want to retain 1 build and I would like it to build to the same folder each time. So I tried changing it to this:
$(BuildDefinitionName)
But the problem is that this only works one time, then gives an error that the build number already exists after that. I would like to build to the same folder so that I can write a script to zip the latest build, move it to another place, and then unzip it and it would just be much easier if I didn't have to deal with writing code to figure out what the most recent folder name is.
Is there a way to accomplish building to a folder name that doesn't change?
This is by designed, every completed build should has a unique build number/name. Otherwise you will get the error above.
$(Rev:.r)
Use $(Rev:.rr) to ensure that every completed build has a unique
name. When a build is completed, if nothing else in the build number
has changed, the Rev integer value is incremented by one.
As a workaround: For vNext build, you could use a copy Files task to copy the build output to the same folder during the build pipeline. To make sure you will always only get the latest build, you could add a powershell script before the copy task to clean/delete files in that special target folder.
For XAML build you need to customize the build template and add the default CopyDirectory activity in build template to copy the build result to the specified drop location. The detailed steps please refer to this blog. Also add a pre-build script to do the clean operation.
I'm using a relatively new feature of TeamCity: File Content Replacer. In my current setup I have a version.js file in my VCS:
window["MyPlugin"].version = "1.0.##VCS_REVISION##.##CI_BUILD_NUMBER##";
I use the File Content Replacer build feature to replace that last part with:
%build.vcs.number%.%system.build.number%
So far so good!
I have one relevant build step. It's an MSBuild step, but it does nothing except call a ps1, which does two relevant things:
Moves all js files to an "output" folder;
Zips all js files into a "zips" folder;
Those are also my two artifacts (an output folder, and a zip file).
However, the File Content Replacer reverts its changes, but this revert is also reflected in artifact nr 1, which are files that are not under version control (even though they are located as a subfolder of my project folder). The version.js file in the zip file is not reverted.
If I change artifact 1 to be my/output/folder => all.%build.vcs.number%.zip then the zip file will also contain a reverted state instead of the output I want.
How do I set TeamCity up so that the artifact files are not affected by this revert? Or do I need something other than this Build Feature?
I'm using TeamCity 9.1.3 build 37176 running on Windows 2012 Server (VM) and the default database for evaluation purposes. I'm using TFS 2013 as my VCS.
PS. I've also asked about this on the JetBrains forums.
File content replace reverts changes before "Publishing artifacts" stage. This is "by design". You can check it in the build log. However you can find modified files in hidden artifacts .teamcity/JetBrains.FileContentReplacer/.
If you want to publish changed file as regular artifact you should create a copy of the file (or pack/archive it as as you've already done). Also instead of using File Content Replacer build feature you can create a script that would make needed changes which aren't reverted.
I'd like my XCode Archive builds to automatically tag my SCM (Git in this project).
I've noticed that in the Schema Editor, Archive builds can run pre and post step build scripts. It would be ideal if post steps are only run if the build is successful, and then the tag could go there.
I'd like the tag name to refer to the name of the build configuration (I have TestFlight and AppStore configurations, as well as Debug and Release, which would not normally be archived), as well as the version number that was built, and also the build number. A tag might go something like: TestFlight_2.1.3_#11 or AppStore_2.9.0_#3.
In XCode's project settings, you can use variable substitutions, such as $(BUILD_CONFIGURATION). Can these be used in an Archive build script?
I'm also not sure if there is a variable for the current version string and build number of the App. I've not managed to find one if there is.
In XCode's project settings, you can use variable substitutions, such as $(BUILD_CONFIGURATION). Can these be used in an Archive build script?
Yes. Build settings are available as environment variables to scripts that run as part of a Run Script Build Phase. An easy way to see what variables are set (if you don't trust the build log output) is to just put env in a script to print them out, or env > environment.txt if you want to save them to a file.
I'm also not sure if there is a variable for the current version string and build number of the App. I've not managed to find one if there is.
There is not. However, if you want to retrieve the current version you can get it from the project's Info.plist file (and there should be an environment variable pointing to the file for the active project).
Xcode Archive doesn't have a concept of a current build number. Usually you use a script to figure out the build number from some other source (Xcode Server, a counter on your disk, whatever) and then set the CFBundleVersion key in Info.plist to that number.
I found this:
https://github.com/bejo/XcodeIconTagger
Obviously this is not exactly what you asked, as this will tag the icon, but you could probably use it to point you to the right direction.
I have checked the option in TeamCity which says "Clean all files in the checkout directory before the build". But it doesnt seem to delete the folder on the server before it builds and deploys the code. There are always stray files which are no longer needed. Is there any better process / Can we achieve by adding extra command line parameters to Build Step to achieve this?
Thanks.
Try setting specific folder as the Build Checkout Directory (instead of using default one). You can set this in your VCS Settings page.
You would also need to select the option the to clean directories before checkout for every run. Otherwise you wil still be left with the issue of stray files
Is it possible to make TeamCity only clean up certain files upon fetching files from my git repo? I modify one file as a build step, and thus always need a clean version of that file. However, it's really unnecessary to fetch the whole repo everytime because usually only a few files are modified (thus, I'd rather not use the 'Clean all files before build' command).
Thanks!
To clarify, lets say I have the following structure:
- index.html
- js/script.js
- js/plugins.js
I only want to always (regardless if any change has happened) to checkout index.html. The files in the js folder I only want to replace whenever any updates on them have happened.
If you are using TeamCity 6.5 or above you can use the Build Files Cleaner (Swabra) Build Feature. Once you have added it your build steps and run clean build it will clean any new unversioned files generated during the build either before the new build starts or at the end of the current build.
I personally prefer to run it before the new build starts as it allows you to look at any of the output when trying to work out why something went wrong.
Basically it makes sure that there is nothing in the build agents work folder that was not pulled from the repository before each build.