Is there any way to configure parametrized builds in team city?
I need to pass a few parameters before actually triggering the build. I have multiple releases for a project and I need to pass the release version manually each time my build fires (It's not an CI Build)
I would then use this release version in my build accordingly.
If you really don't want to use TeamCity to manage your version numbers then one option is to create a BuildVersion (or whatever you want to call it) build parameter for your configuration.
You then need to manually define the version each time you trigger a build; you can do this by clicking the custom build button and entering the version against the parameter in the subsequent dialog.
You can then use the BuildVersion property in your script.
This, however, does not stop people from executing the build without defining that parameter though (may cause some mayhem).
Related
Motivation
PreBuild to disable compilation of redundant projects for faster compilation cycle.
Background
I have a VS15 ALL solution that contains many projects.
I have a single project, PreBuild, that all the other projects are dependent on, meaning, this PreBuild compiles first.
In addition, we also have a PostBuild project that do some more work once binaries are ready.
All projects are configured to build in Release mode (which is desired).
When a team member wants to release some binaries, he hits F7, Build Solution.
Now, the PreBuild, activates a separate dedicated process that calculates which projects should be released. The nature of the calculation is irrelevant to this discussion.
Problem
Out of the many many projects, it is often the case that only a few projects needs to be released. However, once the PreBuild process is done, ALL the projects are will compile which is very time consuming.
Question
Is it possible, after a solution build had started, to change the released projects?
Suggested unwanted approaches
A developer handpicks only the relevant projects and only build those.
PreBuild Kill & Revive. Once desired projects are calculated, PreBuild kills the VS15 process and activate a cmd compiling only the relevant projects.
Suggested approach
Change file ALL.sln and remove the the unwanted projects.
This would work had I changed that file prior to the process start but I'm not sure it would work if this change occurs during the process.
The simplest way I can think of, while still keeping most of the current infrastructure in place: have a dedicated project which invokes the release build (by calculating dependencies and invoking msbuild) and configure VS so it can be select just that project for a build. All from within your ALL.sln so the rest of the features remain. Steps:
Get rid of the PreBuild/PostBuild projects. I assume the PostBuild you mention is also meant for the actual release builds; if not just leave it there. Note by not requiring all projects to depend on the PreBuild project you already got rid of one maintainance burden.
Add one single project which will do the release building, say ReleaseBuild. Such name is also better than having PreBuild/PostBuild projects since it clearly states the intent of the project. A Makefile project is suitable, though technically it could be as simple as an msbuild file with just one Build target. Configure the build command line to do whatever is needed, i.e. figuring out what to build then build. For the sake of an example: say you use Powershell to do this you would configure the build commandline to be
Powershell -NoProfile -File BuildRelease.ps1 $(Platform)
and BuildRelease.ps1 contains something like
$projectsToRelease = CalculateMyProjectsForRelease()
$platform = $Args[0]
$projectsToRelease | %{& msbuild $_ "/p:Configuration=Release;Platform=$platform"}
In Configuration Manager add an extra Configuration called Deploy or so. This will be used to select what to build: you probably have Debug and Release configurations now already. Those stay in place, and are simply used to build everything. The idea is this extra configuration will take care of building the actual release. This is fairly consistent with the standard way of working in VS and easy to discover and understand for newcomers. Using the checkboxes, make it so that when the Deploy configuration is selected only the ReleaseBuild is built and none of the others whereas when Debug or Release is selected the ReleaseBuild project is not built. Looks like this:
To build a release, select Deploy from the configuration drop down menu in the VS toolbar and hit F7 (or whatever way you use to invoke Build Solution). Any build errors/warnings will be parsed and shown as usual in the Error List.
This is also easy to extend: suppose you only have a couple of release build versions just add more configurations like DeployA DeployB DeployC and adjust the build command line for them.
I have a VC++ project that some people in the team open using VS2105 and others VS2017, but the former ones need to constantly edit the project to select v140 instead of v141 in order to be able to build. Is there a way to automatically select the most recent toolset available? I.e., in such a way that the VS2015 users use the v140 toolset automatically, and the VS2017 users use the v141 also automatically.
One idea that comes to my mind would be to have two projects referring the same source-code files, each using a different toolset. But then, any change (e.g., add a new file or a new library to the project) would have to be done twice :(
Another one could be a branch which only differs in the toolset specified, and constantly rebase as the master branch evolves, but then contributing back becomes clumsy :(
Save 2 solution files, one *_2015.sln, and one *_2017.sln.
Start out after this by figuring out the most efficient solution for manually updating only one of these whenever needed. Then write a script to modify the one as to create the other. Add that script to CI or build script, Git push script, or whatever.
Anytime you find yourself uttering the words, "I find myself having to constantly do x, y, z." you should think, "How can I automate this?", followed by figuring out one or more manual methods to complete the task, then choosing the easiest one to automate - especially when a task can be completed by changing text in a file...
If you have CI set up, you should be able to tie such a script to trigger on any new commit.
(sorry if this answer is too basic...)
I would like to stop hudson from incrementing the build number for failed builds. I see no value in incrementing the build number for failed builds as they are not usable.
I expect this is a simple setting in the config but cannot find it and I can't find a solution on SO.
Could someone please let me know if this is possible?
A build is a build, whether it's successful or failed, isn't it? Build number is different from release number, or version number, or whatever your organization calls it.
Additionally, Hudson stores the entire logs from all builds so you can easily refer back to them. This aids you in your ability to go fix the problems with broken builds. If you didn't have that, and you had multiple broken builds in a row, how could you tell what the problem was with each of the builds?
IMHO, you can't find a solution because it's something both that you shouldn't be doing, and cannot currently be done.
It sounds like your trying to automate a rolling minor release #. As others have mentioned you shouldn't use the hudson build number.
If you are using Maven you can use the release plugin so that the least significant version number is bumped (ie 1.0.x where x is incremented) on successful builds.
The Maven release plugin will also checkin the new version # into source control (using wagon) and create a tag.
If you are not using Maven I'm sure there are other build tools that do something similar.
I want to build a Maven project using Jenkins. However, the project only must be built if a certain file in the SVN repository has changed (and contains a special key)
So my plan is to create a job with two build steps:
the first step executes a shell or python script that checks that "condition".
the second step is the actual Maven build
The second step only must be invoked if the condition check in step 1 returned "true".
Is there a possibility to do so? Well, I guess I could return an exit code 1 in the first script if the condition is not met. This will stop the build at once, but the job will be marked as "failed". So this is not a good idea since the red icon makes my users panic ;-)
Any other ideas around this?
Cheers,
Frank
We do something similar with our own Jenkins setup.
We have a "trigger" job that monitors SVN on a periodic basis. When a change occurs in SVN, the trigger job executes its build steps. One of the build steps examines some aspects of the code and decides whether a build is necessary or not. If it is necessary, it uses CURL to initiate the start of a the "build" project. The "build" project gets the source code and does a build - it doesn't bother to figure out whether it needs to build or not - it always does.
Having the two tasks separate also makes it easy to trigger a manual build without worrying the should-I-build logic kicking and stopping the build.
We recently moved to an automatic build system (something internal, not Hudson or Teamcity, yet).
Our version is stored in a header file and is included by some cpp and resource files. It is also used by the installer.
Its format is A.B.C.D where:
A didn't change in years.
B changes rarely (major version).
C changes with minor versions.
D changes when a new minor version (bug fix) is delivered to QA.
Up until now, the one incharge of building a new version, incremented C/D by hand (D being the more common) before starting the build, checked in the change and then started the build. The version stayed the same until that person built the app successfully.
Naturally with the move to an automatic build system I'd like to get rid of the manual step of changing the version number.
How should this be approached?
Do I increment D whenever a new build is made, whether it's a QA build or an internal-test build (i.e. I'm working on some feature and I'd like to test I haven't broke anything)?
Is the increment step a task in the automatic build system?
After incrementing, should I commit the version file?
How do I avoid having a lot of noise in my version control? I don't want tons of "version incremented" commits.
What do I do if the build failed? Still increment the version and commit?
Do I increment D whenever a new build is made, whether it's a QA build or an internal-test build (i.e. I'm working on some feature and I'd like to test I haven't broke anything)?
The Eclipse Foundation adds an E element, the date and time of the build. I think that's a good idea for the internal-test builds. It's up to you if you want to use E for the QA builds.
Is the increment step a task in the automatic build system?
Seems logical, but you have to have some way of telling that task what kind of build you're doing.
How do I avoid having a lot of noise in my version control? I don't want tons of "version incremented" commits.
Commit the version control file with the source code.
Basically, your development build process should proceed in the following order.
Build the product from the development source code.
If the build succeeds, increment the version number.
Commit the source code and the version control file.
Build the product again from your version control system.
If the build fails, back out the source code and version control file commit.
This tests your build and your build process. The second build should never fail, but if it does, there's a problem in the process.
Your production build process would start at the 2nd step, skipping the 3rd step.
What do I do if the build failed? Still increment the version and commit?
My E is auto-incrementing. :-) I'd say no for the other elements A, B, C, or D.
Do I increment D whenever a new build is made, whether it's a QA build or an internal-test build (i.e. I'm working on some feature and I'd like to test I haven't broke anything)?
Yes, change your process so that D increments with every build (successful or not) rather than with every delivery to QA.
It can be quite frustrating having several builds, some working some not and not being able to tell them apart because the failed build is the same id as the good one, well eventually.
Then you don't even have to consider if it was on the same day or in the same hour.
Is the increment step a task in the automatic build system?
I'd have the build system auto increment the build number (D) only.
After incrementing, should I commit the version file?
How do I avoid having a lot of noise in my version control? I don't want tons of "version incremented" commits.
The version control storage is all about recording the detailed noise.
I'd have the version update checked in, this can make a reasonable tag visible in SVN of what build the previous changes where included in, have the build system ignore checkins by the build system, or those identified as the version update checkin.
Then to view the version history you should have an appropriate tool that allows you to filter the history to show you the view you need, in some cases excluding the version commit tags.
If you choose not to commit the version number for each build, then it might be a good idea to maintain the version number in a separate file to avoid accidental updates.
What do I do if the build failed? Still increment the version and commit?
Still increment the version number, I wouldn't commit the version number unless it was a successful build. You can have a variety of failures outside of source change in version control that don't need to be recorded - build server out of disk, server crash, compiler got all wobbly in the knees building 32 and 64 bit, debug and release aix, linux and windows builds at the same time...
You could consider to use the convention for .NET assemblies, as described in the documentation for class System.Version. Quote:
Build [your C]: A difference in build number represents a recompilation of the same source. Different build numbers might be used when the processor, platform, or compiler changes.
Revision [your D]: Assemblies with the same name, major, and minor version numbers but different revisions are intended to be fully interchangeable. A higher revision number might be used in a build that fixes a security hole in a previously released assembly.
How are you going to automate this? I mean, what system would know that "this build is the release build!". It would seem to me that all your digits in a version is relevant. If the next release (D + 1) requires two builds, then would A.B.C.D+2 be the next version? Sounds fishy to me. I would rather add the build number on top of the version instead, if it's really necessary to have this information on your DLLs and EXEs.
I don't think the build number is a relevant piece of information to have attached to the binary, unless you distribute files of version A.B.C.D from different builds (which you shouldn't do anyway!)
I would setup the build server to store the artifacts (DLLs, EXEs, MSIs, PDBs, etc) in a directory, whose name includes the build number and version, and then burn DVD/whatever from there. If you ever need to back track from a version to a specific build, you can use this information, provided that you keep an archive of your releases (recommended!).
I would recommend the use of autorevision.
You could still keep the A.B.C.D format for your tags and use the script to create header files that are generated at build time that have the needed info in them.