Nevermind those branch names, that’s just the way the deploy resource works and I guess it has to do with the shallow clone it uses.
In Git, branches are no more than “flags”, or “tags”, or “aliases” that point to a specific node (a commit, in this case) of the acyclic graph that’s the commit tree. Each commit has a unique revision ID that’s a hash of all of itself plus its parent(s), forming a graph.
The deploy_revision resource deploys the code in a releases/<commit_ID> directory, relative to the deploy root. Check that ID and see if it matches with the most current commit ID of your “development” branch. If it does, you’re good.
I find this 2010 OSDC talk very explanative and easy to follow if you’re interested in the way Git manages commits, branches, tags, etc: http://2010.osdc.com.au/proposal/196/git-ages-4-and — it certainly opened my eyes when I was beginning to learn it.
On July 18, 2013 at 22:29:24, Liam Kirsher (firstname.lastname@example.org) wrote:
Well, actually it probably is working and I’m not doing something right.
I’m using deploy via the application cookbook, and my recipe looks like this…
application ‘bart’ do
bart_data = data_bag_item(‘bti’, ‘bart’)
mongo_data = data_bag_item(‘bti’, ‘mongo’)
The correct value for [:bart][:branch] is printed in the log (in this case it happens to be “development”)
However, in the installation dir, it doesn’t seem to have had any effect…?
I’m expecting to see “development” there.
I’m assuming that the “deploy” branch is added by the deployment cookbook as a branch off of master.
In my case, I would want it to be branched off of development.
Can anyone explain how this works?