i am looking for a way to share build number between multiple build configurations. The goal is to have an global counter of some sort and all build configurations would be incrementing it and use it in its own the build number.
If one of build configurations A has snapshot or artifact dependency on build configuration B, then you can obtain build number from B in A with help of dependency parameter:
%dep.<B id>.build.number%
Where <B id> is id of build configuration B (see buildTypeId parameter in URL).
This solution works for me:
Create Build Configuration. Let say "GenerateBuildNumber", do not attach template. Do not specify any build steps. Click Save.
Edit configuration for your project. Go to "Build Configuration Settings->Dependencies". Click "Add new snapshot dependecy".
Select previously created "GenerateBuildNumber" in "Depend on" section. Uncheck option "Do not run new build if there is a suitable one". Click Save.
Go to "General Settings", clear "Build number format:", click the button on the left side with 3 lines. Select "%dep.YouProjName_GenerateBuildNumber.env.BUILD_NUMBER%". Click Save.
Run your project build. Firstly it should start "GenerateBuildNumber" project then your project with a generated number.
Do the steps 2-4 for every project you want to have unique generated number.
Profit!
I believe the AutoIncrementer plugin should do the trick. It lets you share build numbers between configurations. http://confluence.jetbrains.com/display/TW/Autoincrementer
You can make one Team City project use the build number from another project by following these steps:
Open the TeamCity project configuration's properties for the configuration where you want to import the build number.
Go to the "Dependencies" section.
Add an "Artifact Dependency" and choose the project configuration that you want to get the build number from as the dependent project.
In the "Get artifacts from" field choose "Build with specified build number"
Next to the "Build number" input box there is a button you can click to choose where to get the build number. In this list you should see an option like "dep.bt2.build.number" (the number might not be 2 for your configuration).
AutoIncrementer is good, but now there is a new plugin that has tried to do what some users said they can't do with AutoIncrementer:
http://java.nicholaswilliams.net/TeamCityPlugins/introduction#SharedBuildNumber
It has a UI when you add it to TeamCity, and can also handle the use of dates in the format that you might want to use.
The easiest way by far is to use the variable that gets exposed:
%dep.<build configuration id here>.build.number%
You can use any parameter from the dependency using that variable. If you start typing % in a field with the square box next to it that lets you choose a variable it will pop up with the build configuration id there.
How to set parameter
Step 1: Using IDE to pick up which one you want to use
Step 2: %dep.[B id].build.number% from another project name
How to get parameter
echo %CAPR_number% <-- Parameter Name
Related
Situation: we have a set of build configurations based on the same build template. So, all the configs are marked as "based on MySuperTemplate" and all build steps are marked as (inherited). So far so good.
Eventually I introduced a change in a step of a particular build config, not in the template itself. After figuring this out, I applied the change to the template, however corresponding step of that particular build config is still marked as (inherited, overridden).
Question: how to undo that "override state" back to "just inherited" so the step will accept all the changes from the template origin again?
P.S. TeamCity version is 2021.2.3 (build 99711) if it matters...
No idea why I didn't notice it before:
Open the build configuration, go to the grid of steps
At a grid row with "overridden" step, find "Edit" hotlink accompanied with a small combo-button aside (right-side of the row)
Open a drop-down for this combo-button and click "Reset" option (it appears for overridden steps only, regular ones are provided with "copy" and "disable" choices)
As simple as that. Now the step is reverted back to the template-defined content.
I am new to TeamCity.
I need to create a configuration parameters for build (android).
Configuration parameters should consists from git branch (branch to build), build type and where to push the build (if i choose to push at all).
Example.
How to automatically populate "Build Branch" field with git branches from my repo?
Depending on what is selected in "Build Type" [Release|Debug] how to automatically change what is available for selection in "Make Public" field.
Example:
If "Build Type" is Debug then A and B should be available to select in "Make Public" field.
If "Build Type" is Release then C and D should be available to select in "Make Public" field.
TeamCity version: "TeamCity Professional 2018.1.1 (build 58406)".
First of all, you should use the VCS Roots.
Go to
Create VCS Root
Attach this VCS to your build
General Settings
Version Control Settings
Attach VCS root
Now your project able to build on the different branch
Create the Parameter Build_Type
Click to Spec: Edit
The construction
Debug => A,B
Release => C,D
means if I choose Debug, the real value of the parameter %Build_Type% is A,B
TC hasn't an opportunity to create a depends parameters what you want. But you can use the real value of Build_Type.
The second way is:
User selects the Build_Type and Make_Public.
Run the custom script to determine the needed value and pass it to project.
One more way:
Create a template of builds
Create 2 projects where 1th has one parameter, the second project has another
I'm using perforce in my project. I would like to ask, how can I set the build branch in teamcity? Right now if I want to make a build it is taking code from trunk, when I hit the "run" button it is asking me for my username/password/perforce job, I also need to ask me for a branch name. I know that is needs to be set in the build configuration in build parameters.
I'd suggest using the "Run Custom Build" button to achieve it. It's located next to the "Run" button and titled with ellipsis (three dots in a row).
I might be mistaken in case of the particular VCS you're using (Perforce) though, but for me it works pretty good. When you run a custom build you can either specify the value of your %BranchName% parameter (needs to be specified in your VCS' settings) in "Parameters" tab or select a branch in "Changes" tab.
Hope this helps.
Suppose I have a list of changesets 1 to 10. Is it possible to specify that it build till changeset no. 5, instead of building just for a particular changeset or all the changesets 1-10?
I know It's possible to specify a particular version of the files to build, like changesetId,Date,Label,latest and workspace versions. So how do I specify "Build till C5" when triggering a custom build in my application?
Yes, you can do that using the default build process template. In the "Advanced" section of the build process parameters (in the Process tab of the build definition editor), set the "Get Version" parameter to the changeset you want to build (e.g. "C5"). More logically, you would do this in the Queue Build dialog's "Parameters" tab.
I'm using Visual Studio 2008 and would like to create a sort of container project that holds a number of DLL's that must be installed with a solution. I want them to be in a separate project so that they can be easily attached to a solution as a group.
I created an empty project call TEST, added my DLL's to it with a Build Action of "Content", and set them to "Copy Always". That all works exactly as I want. The problem is that if I set the TEST project Output Type to "Console Application" or "Windows Application" that it won't build because there's no entry point. If I set the Output Type to "Class Library", it builds but I end up with an extra TEST.DLL file that I don't really want.
Is there anyway to sort of set the Output Type to "none"? I want the build actions to take place (so my DLL's get copied) but I don't want the dummy class assembly created. Any ideas?
Thanks!
Assumptions for the following step-by-step guide:
Let's assume that you have a solution with two projects:
Main: your main (start-up) project.
BundledDLLs: a library project which contains the .dlls that should end up in the main project's output directory.
Step-by-step guide:
The easiest way to achieve your goal inside Visual Studio is probably the following:
Add all .dlls to BundledDLLs and set their Copy to output directory to Copy if newer.
This is done in the Project Explorer and the Properties windows.
Configure BundledDLLs's output directory to be identical to Main's output directory.
This can be done in the Build tab of BundledDLL's Project Properties page. Enter something like the following in the Output Path textbox:
..\Main\bin\Debug
Set up BundledDLLs as a dependency of Main.
Do not add BundledDLLs as a project reference to Main, as you usually might; instead, use the Project Dependencies dialog to . This will tell the build tool that whenever Main is built, BundledDLLs needs to be built first.
Do this by right-clicking on the Main project node to open the context menu; select Project dependencies... from there. In the now opened dialog, first select Main from the drop-down list; then check BundledDLLs in the project list below. BundledDLLs is now registered as a dependency of Main.
P.S.: One disadvantage of not having an explicit assembly reference in Main is that some tooling might not recognise the dependency. For example, ClickOnce deployment might not work properly.
Add a post-build event to BundledDLLs that deletes the superfluous BundledDLLs.dll.
As you said, you don't want, and don't need, the dummy output generated when BundledDLLs is built. So add a post-build event that simply deletes this .dll once it's been created.
Open the Build events tab in BundledDLLs's Project Properties page, and enter something like the following in the post-build textbox:
DEL "$(TargetDir)\$(TargetName).*"
(In case you wondered: The reason why you didn't add this project as a project reference to Main earlier is because if you had done so, Main would be looking for BundledDLLs.dll, which it wouldn't be able to find since you don't actually want such a file to be generated.)
P.S.: One disadvantage of adding such a post-build step is that it might interfere with incremental builds. If your project keeps getting recompiled from scratch after this, you might be better off removing the post-build step and living with the extra BundledDLLs.dll in your solution's output directory.
Another option is to use a makefile project, which doesn't require you to build/link anything.
In your project properties (right click property in solution explorer and click "Properties"), under "Configuration Properties" and then under "General", choose "Makefile" from the "Configuration Type" drop-down menu. The build output will include the warning "The property 'NMakeBuildCommandLine' doesn't exist...Skipping" but the build will succeed without building any dll/exe/etc.
While other answers here may better address your specific need, specifying a makefile more directly answers the question title "Possible to create Visual Studio project with Output Type of none?" I hope this is useful for people who google something to that effect and land here.
Credit goes to Xeek in the #winapi freenode irc channel for sharing this tip.
Instead of putting them in a project, you can put the files in a Solution Folder. One of your projects can have a build action that does the copying, but since they won't be in a project, they won't try to "build".