I want to run TeamCity processes based on file existance.
I have two TeamCity processes (Dev and Prod):
Dev should be run if there is DevParam file in repo (or in specified location).
Prod should be run if there is ProdParam file.
I want to run exactly one process after each push to repository.
This files will be added and removed like:
[0] Repository has DevParam file
[1] Pushed, there is still DevParam file -> Dev process should be run
[2] Pushed, removed DevParam file and added ProdParam -> Prod process should be run
[3] Pushed, there is still ProdParam -> Prod should be run
I tried to create Trigger with rules, but I failed (rule like +:DevParam run also on file removal).
Git recognizes addind and removing this files as Moving with Rename, so it may be relevant.
file management is not a normal process. I strongly advise you to use the branch flow. For your example, use develop branch(DevParam) for an all your developers and master branch for a prod
Try to use the follows advice.
The developers are coding in the dev branch. Each developer working only this branch.
You should create the build configuration with the trigger to your dev branch. After each new commit, the configuration will be triggered.
If you decided that the code in the dev branch is ready to production, you just merged all to the master. And now you can also trigger the same configuration only for a master branch.
For more information about gitflow-workflow read this
Related
I am using teamcity to build my Unity3d projects. When I am selecting branch in custom build or when build is triggered from "not master branch" git performs clean, and it removes my Library folder. I need to persist this folder because it is a cache that builds a huge amount of time. When I stay on master, everything is fine and this cache is reused. How can I do this? I want this folder to be shared between my branches.
I tried to create multiple VSC roots, but it copies my repo for every branch. I also disabled all "clean" options that I found in settings. But nothing helps
You could try one of these:
In VCS Root settings you could set Clean Policy to Never. It sets whether and when TeamCity should exec git clean in working dir. Default value is "On branch change" which I guess is your case. But it means that you should manually clean your working dir from build artifacts. For more information see here
You could use Unity Accelerator
You could backup your Library folder in the end of every build and restore in the beginning of the next one
I have a project on AppVeyor that I want to build in two (or three) different scenarios:
Anytime it's on the master branch no matter which files changed, but not a pull request
If it is a pull request on the master branch when certain files have changed
(Maybe if it's on a different branch when certain files have changed)
Is there a way to configure appveyor.yml to do this? I'm aware of how to use APPVEYOR_PULL_REQUEST_NUMBER in one-liners, but I want to be able to apply it to the entire appveyor.yml, and combine it with the only_commits: options.
You can create 2 projects on AppVeyor connected to the same GitHub repo:
For the first project got to GitHub repo settings, find Webhook connected to this project and uncheck pull request
For the second project set only_commits for those certain files according to commit filtering doc
Optionally, for the first project set skip_commits for the same files according the same commit filtering doc, to eliminate duplicate builds.
We are implementing an environment in Visual Studio Team Services (VSTS).
We have a Git Repo tied to VSTS
The problem is how to keep the Config files separate so they retain their unique values in their local environments? But without uploading Configs VSTS fails to Build within it's environment.
We don't want the same config settings that are in VSTS to always Sync to Local Environments nor do we want to Push our local configs to the Master. Obviously, we can Exclude on Push but the question is how to configure VSTS in a manner that allows it to Build successfully without requiring config files to be uploaded to the Repo?
Reviewing this post, I'm not sure whether or not Repo based configs are required: How to handle multiple configurations in VSTS Release management?
And yes we will eventually have multiple configs to allow Staging and Production releases.
The direct answer is No. Usually git only track source code for projects, and VSTS usually can build successful without config files. I’m not sure what’s your project is, so we can deal with the situation for that you need to push the config file to VSTS but also do not effect local settings when git pull (assume the name of the config file is project.config):
Option 1:
If it’s ok for you to rename project.config when you build in VSTS, you can use project.config for your local environments and projectRemote.config for the remote repo: gitnore project.config in .gitignore, and create projectRemote.config file to push to remote.
Option 2:
Keep local project.config version when pull changes from remote. You can keep local versions by:
touch .gitattributes
echo 'project.config merge=ours' >> .gitattributes
git config --global merge.ours.driver true
Note: the merge strategies seems only works when the pull is not fast forward.
I want to accomplish following via teamcity in my CI box.
Master branch commit : Build and Release
Beta branch commit: Build and Release to Crashlytics
All other commits to any other branch: Build
(side note since most of our development branches may or may not contain a prefix, it makes it difficult to use "feature-*" branch naming)
Following this question Select Git branch for TeamCity Build
I have created a Configuration Parameters in my project settings
and then
my VCS root settings
Then I created a build template
When I created builds I made sure branch name is correct
I have also tried to edit Triggers
How ever this is not working because when I push a commit to Beta branch
I think because of ref/heads/* default build is running all the branches
and Beta and Master displays "Pending"
How can I correct this?
I solved the problem by talking to other developers and making sure that all development branches uses a prefix, in this case XAAI-
then in my VCS root settings
for triggers in each build configuration I make sure it only is triggered when that branch is checked in.
for example for QA (Betabuild)
this is the tricky part , for Development branches I had to give an empty parameter, I dont know why (maybe because something needs to check default branch which is supposed to be ref/heads/) but whatever the reason it is working.*
and then finally whole thing looks like this
That pending thing is still annoying but , I think at least it is working as I envisioned now.
If you want your builds to only trigger automatically when the default branch is pushed to, you can add a branch filter to the trigger like so +:<default>.
This is dependent on the assumption that you have setup the %BranchName% parameter in each build configuration correctly. IE, for your Default build, make the %BranchName% parameter = master.
As a side note, you will still see all pending changes for each branch, but the trigger will only run when you push to your default build if you add the branch filter. If you want to get rid of the pending changes for each branch, you'll need to setup your vcs root specfic for each configuration to filter out the branches all together.
We have over 100 build configurations in Team City, and I've come to realize over the past few months that these assets are just as important (if not more so) than the actual project assets (code, config, etc) we are delivering.
To that end, I know TC provides it's own build configuration version control but to me that seems a bit low on features - for example if a build stops working it would be really good to be able to diff the actual XML build configurations in my favorite diff tool rather than rely on TC's built in one, or to be able to view differences across a longer time frame than simply against the previous state.
Obviously this can be handled manually by extracting the build definition and committing, and then applying self disciple to always do this when you change the definition. Can anyone suggest a more joined up approach? We're using TeamCity Enterprise v8.0.5
Can you upgrade to TeamCity 9? TeamCity now has built in support to sync the build configurations to Git or Mercurial.
https://www.jetbrains.com/teamcity/whatsnew/
https://www.youtube.com/watch?v=zTLeCrdxGIw
As an interim solution before you upgrade to TeamCity 9, you could write a scheduled job to run every 10mins (or even every minute) and automatically commit the changes to a new repository. I'd use a new repository so TeamCity doesn't ever try and trigger off the commits.
I don't know what OS or VCS you are using, but you'd just need to commit all XML files so you get project-config.xml, build type XML, and plugin config, you don't want .properties files as the build number files will change after every build.
<TeamCityData>/config/projects/**/*.xml
If you are using Git you could easily just init a repo in the projects directory, add a .gitignore for anything other than *.xml, and run git add . and git commit -m "Build configuration settings were edited" as a scheduled job.