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.
Related
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
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.
I've read multiple documentations already but I don't seem to get it - I want to branch one project folder of our rcp, change something there and test with the changes I've made there.
Which steps do I have to make to work on the branch? How do I integrate the branch in my workspace for testing without ruining my local files and what does Switch... do?
Working on a branch directly through Subclipse isn't possible. You have to check out to your local machine first and then commit back.
This will override local changes, so make sure to branch them first.
IF you want to test your quick changes in your project without your local changes ,this is what you can do
-Create a new branch of the trunk/active of your project in SVN
-Checkout the new branch from SVN as its own project
make your quick change . Test it locally
Check it back into the branch. When you are ready, merge your code.
there's an "issue" (actually a nuisance, but a major one) with our development process.
We've setup a good continuous integration-deployment-delivery pipeline; basically, our process is like that:
New development happens on the default branch (we use Mercurial, but git would have the same issue); usually we develop just one small improvement there;
Once the improvement is ready and tested (something that usually happens twice or three times a week, our cycle is pretty short), it's merged into the release branch (which actually stands for release candidate), it's tested again in a production-like environment and if it passes all our testing it's pushed to the production environment.
If we need to make a bugfix, we do it on the release branch, we test it and then push it to the production env.
An artifact (usually an RPM package) is built from each branch; when there's a release in production, the very artifact from the release branch is promoted to our public repository. There's no branch for the production environment, because we usually don't need it (there's a very short timespan when something it's on the release branch but it's not in production; code doesn't linger there unattended).
In this context, there's a small issue for us.
In order to distinguish packages, we usually set version to 1 for packages on the release branch, and 2 to packages on the default branch. Our CI system then adds its build number, so we've got packages like oursoftware-1.0-build37 for release and oursoftware-1.0-build902 for default. Such version is written either in our .spec file or in our pom.xml files (or other files for different softwares, like .gemspec or simila)
Whenever we want to put something in release candidate, we merge the default branch to the release branch.
What happens there? the version gets merged as well. So after each merge we need to get back at the file containing the version and put the old version in them. We should need to do it just once (Mercurial does not try to re-merge things that were already merged) but whenever we need to do a merge from release from default (e.g. in order to merge a fix done on release to the dev branch) the problem rises again.
I'd like some advice on how to prevent this problem completely; how do I set versions outside of my branches? I sometimes actually need to change them (e.g. I want to change from 1 to 2 on release and from 2 to 3 on default) and I wouldn't like to hardcode them in our CI system, I'd like some system which is "outside" the scope of branches and it's kind of "global" for a repository. Or I would need something like "ignore modification for some files".
In many situations I actually need versions in my files as well; for example I cannot omit version info from a Maven pom.xml file or from a .gemspec, otherwise it won't work when developing.
Thanks,
Well, I see 3 4 a lot of possible solution, more or less "native" (random order without priorities and own personal preferences)
Instead of "Monolitic $DEVEL branch" you can use "Branch Per task": in this case file with (hardcoded) version-info will not appear as mergeable file (TBT!)
Branch-specific version change can be moved from (permanent) changeset of branch into patch of MQ (as results - versions /and files/ are identical across branches, permanent default changes have to appear as result of applying patch)
Files with version-info doesn't contain hardcoded versions, they are more "templates", than "data", and real data appear as result of some preprocessing inside build process (you know transformation-rules and can code it)
You can change nothing in developent|deploy process and if version-info files are unique inside repository, you can use trick, similar to merging hgtags (special mergetool for only some files in repo - in your case in must be internal:local special mergetool)
Maybe using just merge-patterns will be OK for you, check Mercurial - Exceptions to internal:local merge-patterns? and Default to trunk version for Mercurial merges? for details and some additional notes+discoveries
I try to understand the right approach for managing hotfixes with TFS /source-control.
Say I have a small project to contains only two file (app.js and util.js). Both files are under source control (Team Foundation Server).
Assuming I applied two weeks ago a label that indicates the "milestone-1" that was deployed to the server. Since then I applied several other modifications (extended app.js and added another files).
Today I found a bug so I get the version with the label "milestone-1" from the server, modify the util.js and deploy this version to the server. The goal is that on the server only the version "milestone-1" including the hotfix-1 is deployed but not the modification I applied the last two weeks.
The question is: How /where do I check-in the hotfix to the TFS? Because I might find another bug tomorrow so I have to get the version "milestone-1" and the hotfix-1 base base for appling the second hotfix.
Is there a way to check-in a version of my code into the TFS that "sits" between label "milestone-1" and my latest version?
With branching and merging!
We have the following development cycle:
The initial project is created, permissions assigned, and imported in to TFS under branch name of "Main".
Because this is the initial iteration of development, we branch "Dev" from main, and that's where the developers work. Note at this point there is no official release.
When development is complete, it is merged back in to Main. No Dev work happens on the Main branch.
We branch "Release" from main, and that is the point at which the code is actually deployed, and version numbers are updated.
Ok, so, further down the line, we have to make some amendments. Once again, "Main" is branched out again and the development work continues down the Dev Branch. All is well. Then a user reports a bug that needs fixing, and it needs fixing fast. But we're half-way through our other development!! What to do?
At this point, we branch from main again. We'll call it "HotFix". The bug is fixed, and then HotFix is merged back in to main. We can then merge it in to our release branch, and the update is sent out. Our current dev work is not interrupted, and none of the work we have been doing up to this point exists on Main).
We finally finish our dev work, and we merge that back in to the main branch, and then in to release. Because our Hotfix branch got merged in to main, our new development work also contains the hotfix we did on the fly earlier.
You should use branching. Check out the "Rangers'" guidance.
I have successfully used the Advanced Branch Plan in the past, but you can customize it to your needs. You need to be disciplined with branching, merging, checking in, etc. Also consider shelvesets for code changes that aren't ready to be committed even to the DEV branch.
http://vsarbranchingguide.codeplex.com/
Let me know if you want more information.