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.
Related
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.
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
I have created several user-defined build settings in Xcode 4.3.1. I no longer need these settings and want to delete them, but there doesn't seem to be a way to delete them!
I am aware that these are stored in the project settings (project.pbxproj) file located within the xcodeproj file. But I don't want to edit these in a text editor as there are all sorts of repetitions and guids which I don't understand.
Any suggestions on how I can do this within Xcode? (or have they forgotten to add a "delete" button)
Just figured this out myself: you need to make sure you're at the right scope to be able to delete the setting. If you defined the setting at the project scope, no amount of key-bashing will remove it if you're looking at the target-scope. Remember, targets inherit settings from project scope. That last bit is what I tripped over :)
Try selecting a user-defined setting that you created then hit "Delete" button on your keyboard. That works for me when I encountered the same problem.
On Xcode 6:
Select the row and hit Fn + Delete.
Follow the steps below:
Select Project
Tap on the Info tab
Select Configurations
Select Configuration to remove
Press the Delete button on the keyboard
Removing User-Defined build settings depends on where those settings have been created.
Lets assume that you've created one already and named it as PROJECT_SETTING. In order to check your PROJECT related User-Defined settings, you have to select your project first on the project and targets list, then you should see something like this:
Here you can see only PROJECT related settings, and here you have the
only ability edit/delete PROJECT_SETTING.
Besides that if you set up a TARGET, so can add new User-Defined settings there, that only affects that TARGET scope.
You can edit/delete TARGET_SETTING_1 and TARGET_SETTING_2 here, but
PROJECT_SETTING is read-only, as it is inherited from your
PROJECT settings.
Here you will notice that your TARGET contains your PROJECT User-Defined settings and also your TARGET related User-Defined settings marked as bold letters. This helps you to know which setting can be edited on this level.
You won't be able to delete your settings here if that was created under PROJECT scope, and also editing a PROJECT related User-Defined settings will result a newly created settings that affects only the selected TARGET.
Also if you prefer more visibility on Build Settings, you can select Levels view instead of Combined view, so you should see it more separated:
Select one of them and press keyboard's delete button.
There's a caveat to these answers: If you're using a Build Configuration File (.xcconfig) it doesn't seem possible to delete the user-defined settings generated from these files directly on either the project or target level in the "Build Settings" GUI. You'll have to delete the flag and its value from the configuration file and rebuild the project. If you're using multiple build configuration files that use the same flag, you'll have to delete them from each file.
Although settings that come from these configuration files are displayed in the User Defined build settings section (just like any other user-defined flag that one would create from the GUI), they are not written to the .xcodeproj file like the settings that one adds from the GUI are (which probably prevents them from being able to be deleted from the GUI). They are also not displayed in bold text like these GUI-added settings are.
I downloaded an ASP.NET open source solution and opened it in Visual Studio 2010. VS is running as admin.
Everytime I switch the solution or a project from Active (Release) to Debug and uncheck 'Optimize code' and save, these changes don't stick. The solution or project reverts back to Active (Release).
Why is this happening?
You also have to change it in Configuration-Manager (see pictures).
I just had this exact issue. The solution ended up being:
Go to Tools ⇒ Options ⇒ Make sure "Show All Settings" in the lower left is checked.
Then, in that same window, go to Projects and Solutions ⇒ General ⇒ check "Show advanced build configurations".
I have no idea why this checkbox was suddenly unchecked for me this morning, but this worked.
This is guessing a little, but anyways:
Most likely, you are using build configurations that don't include your start up project for Debug build.
Look for the 'Manage Build Configurations' (I think, no Windows machine nearby) menu item. It will show you a list of projects with tickboxes on the right to show whether it is to be built in the build configuration.
Switch to 'Debug' in that dialog and make sure your startup project - or the project that your starting the build for - is actually included in the build.
PS It is even entirely possible that the 'misbehaving' project is actually lacking a Debug build (it might have a deviant name, like DebugConsole or something else entirely). In that case, use the Project menu to add a build configuration of the proper name for that single project. Afterwards, check (again) that said build configurations are checked in the 'solution wide' build configuration dialog.
HTH
Changing the properties of a configuration doesn't change the current build configuration. If you open project properties, change from Release to Debug and make some changes, after exiting the dialog, you will build on the same platform as before. To change the platform you're building on, there is a combo-box right above the code - use that. You should have all available configurations in the list. When you open the project preferences dialog, the current configuration will be the default one in the dialog.
I opened the csproj file in a text editor. Noticed there were two PropertyGroup sections which look like duplicates, one was Debug|AnyCPU and the second was Release|AnyCPU. I deleted the second one and the debug one showed up.
Luchian Grigore's answer explains correctly one simple misconception that could lead to this problem and aaaaaaa's answer gives another way of correcting it: there is a dialog that looks like you are selecting the configuration to build but you are actually just selecting the configuration to configure.
However neither of their ways of opening the 'Configuration Manager' actually worked for me -- I had to click on the button configuration manager at the top right of the solution Properties.
(Note that the place where you choose the configuration is called Configuration Manager, whereas the place where you manage the configurations is Properties.)
In XCode 4.0.2 there is a good way to configure the program in Build Settings when you click in "Levels" format. Like this screen
The levels are in this way:
Target Settings
Project Settings
iOS Default Settings
So the XCode see if the Target have a config, if not see in project and if not use the iOS default.
The problem here is that when you set a config in a low level and than delete it, it's impossible use the config of a upper level.
Like in image. I set all targets to use Google in Current Project Version, but in this target I want it use stackOverflow and it work. But in the other Generated Versioning ... I first config with stackOverflow but change my mind and want to use the Project Settings. Now is impossible delete the Target Settings and I will have to enter it manually.
How can I delete the target setting to use the project setting?
In xcode 5 it worked right simple for me. I had the same situation as in the picture in the question. Some data in the project setting and an empty but green setting on target level.
You have to select the line e.g. with the mouse that is marked and afterwards press the delete button the green marking is gone from the target level. In my test it and it will never delete the setting on the highes level, so there is no risk.
Click the Combined button and change the build setting value. Now when you click the Levels button, you will see the target and project both have the new value for the build setting.
I just figured this out. It's a little sketchy, but it works, and does not feel dangerous to me (particularly if you're using version control).
In Xcode, delete the text from the target-level configuration. Make sure you still have it defined at the project level.
Look at a diff of the YourProjectName.xcodeproj/project.pbxproj so you can figure out the code-level name of the setting you just changed. For example, in Xcode, I deleted the text from my target-level configuration for "Other C Flags". My diff showed the OTHER_CFLAGS setting changing from OTHER_CFLAGS="mytargetlevelsetting" to OTHER_CFLAGS="". If you're using version control (which you should be), it'll be easy to get this diff.
Quit Xcode.
Open up YourProjectName.xcodeproj/project.pbxproj in a text editor. Find all the lines starting with the setting name you found in step 2. Delete all the ones where the value is an empty string, and keep all the rest. For example, I deleted all the lines that said OTHER_CFLAGS="", but kept all the lines that said OTHER_CFLAGS="settingiwanttokeep". If you don't see any where the value is an empty string, or all their values are empty strings, you probably didn't follow step 1.
When you reopen Xcode and look at your target's build settings again, the setting in question should be using the project-level configuration, not the target.