I have an issue that I want to share with you and ask for advice.
Let's say I have a project in TFS with a source code folders and folder with deployment scripts. Folders structure:
-- TFS
---- PROJECT
--------DEPLOYMENTSCRIPTS
--------SOURCE
DeploymentScripts folder is a container for custom deployment scripts that are being executed by TFS Build process.
Source - is a folder with a source code where for each new release I create a label to use it later for deployment.
I have a build definition configured to takes files from both folders, so I expect that TFS will download the content of both folders each time I trigger a build:
And this perfectly works when TFS build takes the latest version: it takes everything, builds and deploys.
The issue appears once I configure what label to take:
TFS downloads only the content of Source folder ignoring DeploymentScripts. I suppose that this happens because we use labels only for Source folder and not in DeploymetScripts (the content of this folder is static, there are no any changes). I know, that if I make DeploymentScripts a sub-folder of Sources that will fix my issue, but I want to keep it separate (for example, if I later create a bunch of branch folders I don't want to copy deployment to each specific folder, I want to have as a one instance) and try to find a solution for this case.
Either apply your label at the root level, or start your build using a date or changeset number.
Another approach would be to use branching rather than labels, and set up your build to allow you to pass in the name of the branch to be built.
I no longer use labels, I can't think of a situation where they would be useful to me these days.
If I encountered a team doing this my first question would be why do they need to use Labels to accomplish whatever workflow they are after. This is an unusual practice, most teams just do a Get Latest, and use an appropriate branching strategy to achieve their desired workflow.
If you must use a Label one option is to include the DeploymentScripts in your Labels. You can do this without have to move the folder location in source control by editing your Label.
Related
So, we are in this process of migrating XAML Builds to vNext (2015) Builds on TFS, and we are trying to "do things as clean as possible", since we had many, many customizations on the XAML builds that could be avoided and actually gave us problems along the way.
One major issue we are facing is with paths and "global files". Let me explain:
There are some files that, for commodity reasons, we have on a single place and every SLN file on that Collection refers them. Those files are such ones as Code Analysis RuleSets, Signing Files (SNK), etc. So the change is made in one place only and it affects every build.
Well, in XAML Builds we have a Build that runs with CI that downloads (Gets) those files, and since we hammered-in the same exact pathing for TFS and Machine (with a environment variable for the beginning of the path), the path is the same on the Developers and Build machines. However, this creates dependencies between builds and workspace issues.
My question here is, is there a configuration that I am missing that allows referring to files in other branches other than the build one? Since I’m trying to keep the build machines as “disposable” as possible, it’s running with an Agent Config Out of the Box: No custom paths, no hardwiring.
I already tried referring the files directly with their source control path, for example. The only options I’m seeing are either creating a PowerShell/CMD Script that downloads those files right into the same folder as the SLN or keeping it “as it is” and use relative paths putting a “Build” Build Step before the actual Build Step so it downloads the files to the server.
Isn’t there an “Elegant” way of doing this? Or is our methodology wrong from the get go?
You can add a Copy Files step to copy the files that the build needs:
I recently noticed I needed to reuse a build step in many projects. So I created a template where I only defined that build step, and had the projects that needed it associated with that template. That worked perfectly.
But then I realized that none of the affected projects were generating their artifacts, even though all of them were building successfully. When I went to look at the General Settings, the Artifact Paths box was grayed out and Team City told me that I could only change it inside the template!
I want my builds to have different artifact paths (some don't even generate artifacts at all), but I don't want to duplicate my build step. Is there some workaround for this?
Team City Version: 6.5.6 (build 18130)
This is how I workaround the issue:
Create a configuration parameter in the build parameters section of the template. I just call it Artifacts.
Then reference the property in the Artifacts Paths box in the template, e.g %Artifacts%
Then for each configuration which inherits the template you can override the artifacts configuration parameter with a path that is relevant.
HTH
This is an old question and apparently only affects users with TeamCity versions less than 8.1 (as pointed out in the comments to the accepted answer).
According to the offical documentation:
Since TeamCity 8.1, the following settings can now be overridden in a build configuration inherited from a template:
build number format
artifact paths
build options (hanging builds detection, status widget, number of simultaneously running builds)
VCS checkout mode
checkout directory
clean all files before build
show changes from snapshot dependencies
execution timeout
all common build failure conditions, including execution timeout
I have deleted my application target and now all my Build option are gone. I cannot run my project because I am missing a target. How can I regenerate it?
You have two options.
The first is DarkDust's suggestion: restore from a backup or an SCM repository if you have them. If you have neither, you must admit you were begging for trouble.
The second is unfortunate but comes with a message of hope. Recreate the target from scratch. Select File > New > New Target from the main menu and select the appropriate target type (a Cocoa Mac OS X application, doc-based, or whatever). With the new target selected, click the Build Phases tab, expand the Compile Sources phase, and drag all your implementation files - .m (and .c and .mm if you have them) - into the list so they're compiled as part of this target. Expand the Link Binary with Libraries phase and add in any frameworks you use. Expand the Copy Bundle Resources phase and drag in your resources (including xibs, credits, InfoPlist.strings, your app icon, etc.). Don't forget to recreate any Copy Files build phases you might have set up manually (if you did, you'll already know how). That should do it. The message of hope I mentioned is that you're now familiar with what a target is and all it needs to build your product. It's actually a lot simpler than it appears.
If restoring from a backup or a repository is not an option, and your bundle has many resources, I'd recommend starting a new XCode project from scratch and importing the source files and resources into it.
Create a new Xcode project of the same type and info as your project.
Delete this new project's ViewController and AppDelegate source files, copy your source files into the new project's folder, then import them into the Xcode project.
Add any frameworks you've used.
Import the resources (images, sounds, plists, etc) into the project.
It might take longer than recreating a target and adding things to it, but you're less likely to make mistakes along the way, and you'll ensure that everything is properly added to the target.
If you have version control then the following method works. I used another method to revert my changes if there are not much, executing "Git checkout ." on terminal. Changes will be reverted and Your target will be restored.
Is it possible to combine the following properties, and if so, how?
Store in our version control system some Visual Studio 2008 native C++ (VCPROJ) project files for the developers in our team that use this IDE.
Allow some of those developers to tweak their projects (e.g. using debug version of third-party libraries instead of the usual ones).
Make sure these modifications are done in files that are not versioned.
In other words, I would like to allow developers to tweak some settings in their projects without risking that these changes are committed.
An 'optional VSPROP' file approach seems doomed to fail, as VS2008 refuses to load projects that refer to non-existent VSPROP files...
Any other suggestion? Is this possible with VS2010?
You may not be able to do this but using a solution that generates the vcproj like CMake for example would let you do this. Scripts all your project with CMake and literally conditionally include a config file(if present for example) that developers can change on their setup.
Branches could solve this problem: you create a branch, play with different versions of third-party, merge changes to trunk if results are good.
Well, as a preliminary solution you could put the project file into something like .hgignore or .gitignore after its initial commit.
This way changes to it can't be done accidentally.
At least that's how I handle .hgignore itself.
We use a versionned "common_configuration" folder, and a script which copies project files from this "common_configuration" folder towards the "project" folder.
We have another script to copy the configuration backwards, so the developpers need to make a conscious action to commit their local changes to the global version control system.
It answers partly your needs :
The upside : we have a way to keep a common configuration for everyone, and no accidental committing of local configuration
The downside : blindly copying the files actually crushes local changes. We live with it. We could write some more clever merger tool (using diff, or xml specific manipulations), but don't want to spend to much time on supporting the deployment tools.
Is it possible have two projects with the same name in flex builder?
Here is the scenario
~/projects/myprojectdev/ProjectName
~/projects/myprojectstable/ProjectName
myprojectdev
and
myprojectstable
are more or less the same tree structure and duplicates of the same codebase.
I am using git to manage them as separate repositories. I can do some stuff in the myprojectdev folder and then occasionally merge changes over to the myprojectstable folder when I am satisfied. But I want to keep code from myprojectstable in my working space in flex builder to be able to launch it and occasionally compare the code between dev and stable. I may also want to open different versions of the same project codebase and compare them in the working environment. The problem is that in both folders the "ProjectName" is the same. And so I can't import both into my Flex Builder workspace. I get the warning
A project with the same name already
exists in your workspace. Rename or
delete the existing project.
But I don't want to rename the project or mess with its folder structure. What do I do? Do I have to keep these in different folders? e.g.
~/projects/myprojectdev/ProjectNameDev
~/projects/myprojectstable/ProjectNameStable
You can rename a project (in eclipse/flex builder) without actually renaming the folder it is in. Edit the .project file in your ProjectNameDev and ProjectNameDev to give the projects different names. You might need to restart eclipse to get it to recognize the new name.