We currently having a problem with Teamcity triggering builds with a VCS trigger when there are 0 file changes, our VCS roots are configured with Mercurial
We have a checkout rules setup to only checkout the necessary folder for the solution we want to build and we have a requirement to only build a solution if there are changes in the folder that the solution belongs
The problem we are having is teamcity is triggering a build when there aren't any changes on the folder, this only happends when we merge heads.
The pending changes will show 0 files and if you view the file changes the files shown are from a folder that isn't included in the checkout rules or the VCS trigger.
I can't seem to figure this one out, so any help would be appreciated.
I guess TC9 documentation answers why this is happening. I know that this documentation is for newer version, but it seems to be about exact scenario you have.
Triggering a Build on Branch Merge
The VCS trigger is fully aware of branches and will trigger a build once a check-in is detected in a branch.
When changes are merged / fast-forwarded from one branch to another, strictly speaking there are no actual changes in the code. By default, the VCS trigger behaves in the following way:
When merging/fast forwarding of two non-default branches: the changes in a
build are calculated with regard to previous builds in the same
branch, so if there is a build on same commit in a different branch,
the trigger will start a build in another branch pointing to the same
commit.
If the default branch is one of the branches in the
merging/fast-forwarding, the changes are always calculated against the
default branch, if there is a build on same revision in the default
branch, TeamCity will not run a new build on the same revision.
Have you looked at the trigger rules? You can set a custom trigger rule to only run the build on changes to a specific folder.
http://confluence.jetbrains.com/display/TCD8/Configuring+VCS+Triggers#ConfiguringVCSTriggers-TriggerRulesExample
Related
I use an ant script to deploy my application. Before deploying, however, I preserve any uncommitted changes by committing them to another branch, but keeping them uncommitted in my current branch. I do this by shelving the changes, updating to the other branch, unshelving them (but with --keep), committing, updating back to the original branch and unshelving once more (but without --keep).
The problem with this is twofold. Firstly, shelving changes the content of my project which in some cases messes with my IDE. Secondly, when an error occurs within the ant script after the files were shelved, but before they where successfully unshelved, I am forced to unshelve them manually, which is a pain. The same goes for updating to and from the other branch.
Is there a better way of doing this?
-- EDIT --
After posting this, I managed to implement a better, albeit not ideal, solution. I check if there are local, uncommited changes, and if there are, I shelve them, mock the current branch in hg to be the other branch (using debugsetparent), commit any changes in the working directory (this is now effectively a merge with the original branch that accepts all changes from "other", but without updating at any point), unshelve the previously shelved changes, commit them and mock the current branch in hg to be the original branch, leaving the unshelved changes as local, uncommited changes.
This is better in that I don't update to the other branch and any real change that happens, as far as the IDE is concerned, is the shelving/unshelving of local changes. Previously, it would be affected by all the changes between my current branch and the other one, but now this is avoided.
Still it's not an ideal solution. I could avoid shelving altogether, but then the commit in the other branch would contain the local changes bundled up with any changes that resulted from the difference between the two branches, any I don't like that since it defeats the purpose of being able to quickly check the changes that were done between deploys.
To not endanger current work, would be better to have 2 repositories, one for development, and another for deployment.
Clone the main repository locally to another path in your disk, and use it for deployment, the main repository should be used for development.
Whenever you need to deploy a new version, sync with the main repository, and update to the desired commit.
I have projectA execute projectB. ProjectB writes ProjectA's build info to ProjectA.buildInfo.
I have a Mercurial repo for projectB, and use HgFlow (git-flow workflow) using sourceTree.
I would like ProjectA.buildInfo to be part of the develop branch of my mercurial repo, but not part of the default branch.
When I have removed ProjectA.buildInfo from default, develop eventually merges back into default and brings the unwanted file with it.
You simply have to pay attention to the merges you do. hg remove the unwanted file every time you merge your development branch back into default.
In order to avoid this (easy) mistake to happen, I suggest to ward yourself against that by means of a commit hook. That hook should check whether the commit so done on default branch and fail when it detects the unwanted file(s) being added. Additionally run the same or similar as pretxnchangegroup hook on the central repository (if any).
Check hg help config and search for help on hooks therein. We use a hook to avoid people committing build artefacts to every branch, you could possibly extent that: https://hg.openttdcoop.org/misc/files/tip/mercurial/hooks/check_commit.py
I've been trying to find actual documentation for Sourcetree without much luck, so I figured I'd ask here. I'm a relative newb when it comes to version control, with my current project being my first effort. I'm using Sourcetree on Windows 7 as a frontend for Mercurial, I've got my development code on my local machine in C:\inetpub, and whenever I do a Commit I then switch Sourcetree over to the cloned repository on my backed up network drive and do a Pull of the changes I just Committed so I've got the development history backed up.
What I'm trying to wrap my head around is using Sourcetree to set up a Debug branch so I can fix bugs on the version of the code running on the production server while simultaneously doing development. Obviously a common need, but I can't grok it. I am expecting there to be two code locations, so I can pause in mid-edit on the Development branch, make changes to Debug, and them come back to my changes in Development and finish them up before merging in the changes to Debug. If that's not how it works that's presumably part of my confusion. Any suggestions on where I can find clarity? Pointers to existing tutorials and the like would be fine, I just haven't been having luck searching Google, and I haven't been able to locate any actual Sourcetree documentation.
NOTE: Based on responses I've seen to other questions I've read about Sourcetree and Mercurial, I'll state upfront I have no interest in discussing outside repository hosting unless somebody can explain why it will help with this problem.
Two things here:
You do not need to change repository to pull, you can also push from your local repository;
You do not need 2 code locations for switching from one branch to the other. It might help, for larger projects, but I suggest you get comfortable with Mercurial before doing so.
So, for number 1, there is a default source or remote repository for every local repo. It is either defined by the user or it is the source repo from where it was cloned. Whether you push or pull, it will default to that same source. You can push/pull to multiple sources as well, but this is not your case at the moment. In the normal workflow, just issue a hg push every time you commit, and your changes will be propagated to the other repo.
For number 2, a Mercurial repo, as you already know, can have multiple branches. When you commit a changeset, it is automatically done on the current branch. In SourceTree, click on the Branch button, and enter a new branch name. The next commit you'll do will be the head (and the start) of your new branch. After that, you can update back and forth between the 2 branches, and your code will change accordingly. That means that you can update at any time to the head of any branch, make some changes, commit, and then jump to another branch, and so on. So no, you do not need multiple repositories.
Normally, the proper practice is to have a default branch (default name is rarely changed!) where you have your current development source. For every issue or feature you are fixing/implementing, create a new branch from the default branch to put your new code. Once that branch has been reviewed and tested, merge it back in the default and close the former.
For your current development, if you need an additional stable and safe trunk, you can create a Production branch, which would be the stable code that will run on your server. Once you are satisfied with the default branch tests, you can then merge it in Production to include your changes up to that point.
As a convention, make sure your server is always running the code from the Production branch, for the more stable code. At least, that is what I understood from your initial question.
I have a Jenkins build job with a Mercurial trigger on the default branch, which works fine for building "release candidates". This job then starts a smoke test job.
We use a branch-per-feature branching scheme, so that at any given time there could be up to a dozen different active branches in Mercurial (but the active branches change regularly).
I would like a Jenkins job triggered by changes to any branch, that will then build and run the smoke tests for all branches that need updating. Each time we do a build, we should create artifacts named to match the branch.
I saw a suggestion in another answer of using "tip" instead of the branch name in the Mercurial trigger - this is a possibility, but I think it would fall into the "mostly works" category. The trigger is polling, so if changes to more than one branch occur within the polling interval, then a branch update could be missed.
I could create a new job each time a branch is created, but due to the dynamic nature of our branches, that would be a lot of ongoing work.
If you decide to go with the job for every branch approach, the following tools can make the task a bit more manageable:
jenkins-build-per-branch (supports git)
jenkins-autojobs (supports git, mercurial and svn)
I think you'll need to customize: the top-level polling job (tuned to tip) runs a custom script that determines branches that have changed or have been added. It then will use Jenkins API to start a job parameterized by the branch name. That parameter can be used in your job to customize everything you need by the branch name (including the artifacts).
We've just recently switched over from SVN to Mercurial, but now we are running into problems with our workflow. Example:
I have my local clone of the repository which I work on. I'm making some highly experimental changes to our code base, something that I don't want to commit before I'm sure it works the way it is supposed to, I don't want to commit it even locally. Now, simultaneously, my co-worker has made some significant improvements/bug fixes which I need. He pushes his commits to our main repository. The question is, how can I merge his changes to my workspace without the requirement that I have to commit all my changes, since I need his changes to test my own code?
A more day-to-day problem we have with the exact same workflow is where we have a couple of configuration files which are in the repository. Each developer makes a couple of small environment specific changes to the configuration files, but do not commit the changes. These couple of uncommitted files hinders us from making any merges to our workspace, just like with the example above. Ideally, the configuration files probably shouldn't be in the repository, unfortunately, that's just how it has to be for here unnamed reasons.
If you don't want to clone, you can do it the following way.
hg diff > mylocalchanges.txt
hg revert -a
# Do your merge here, once you are done, import back your local mods
hg import --no-commit mylocalchanges.txt
There are two operations, as you've discovered, that makes changes from one person available to someone else (or many, on either side.)
There's pulling, which takes changes from some other clone of the repository and puts them into your clone.
There's pushing, which takes changes from your repository and puts them into another clone.
In your case, your coworker has pushed his changes into what I assume is your central master of the repository.
After he has done this, you can pull the latest changes down into your repository, and merge them into your branch. This will incorporate any bugfixes or changes your coworker did into your experimental code.
This gives you the freedom of staying current on other coworkers development in your project, and not having to release your experimental code until it is ready (or even at all.)
So, as long as you stay away from the Push command, you're safe.
Of course, this also assumes nobody is pulling directly from your clone of the repository, if they do that, then of course they will get your experimental changes, but it doesn't sound like you've set it up this way (and it is highly unlikely as well.)
As for the configuration files, the typical way to do this is that you only commit a master file template into the repository, with a different name (ie. an extra extension .template or similar), and then place the name of the real configuration file into the ignore filter.
Each developer then has to make his or her own copy of the template, rename it, and change it in any way they want, without the risk of committing database connection strings, passwords, or local paths, to the repository.
If necessary, provide a script that will help the developer make the real configuration file if it is long and complex.
Regarding your experimental changes, you should commit them. Often.
Simply you commit them in a clone you don't push. You only pull to merge whatever updates you need from other repos.
As for config files, don't commit them.
Commit template files, and script able to generate complete config files from the template.
That way, developers will only modify "private" (i.e. not committed) config files with their own private values.
If you know your uncommitted changes will not collide with the merge commit that you are creating - then you can do the following...
1) Shelve the uncommitted changes
2) Do the pull and merge
3) Unshelve the uncommitted changes
Shelf effectively stores your uncommitted changes away as into diff (relative to your last commit) then rolls back those files in your local workspace. Then un-shelving then applies that diff, bringing back your uncommitted changes.
Tools such as TortoiseHg have shelf built in.