Is there a way to have this script monitor two branches of same project?

[Matt Esser]

For instance...

Say I have MyAwesomeApp and two branches (well, two that I care about tracking): master / develop

Right now, your script works perfectly with one branch at a time. Most of the time I'm in develop, so that's what I leave the script at, I commit, push it to Bitbucket, it contacts the gateway, which is configured to deploy to my staging server. This works great, so far so good.

Let's say I'm now happy with my code, merge my develop into master, tag it, commit and push to Bitbucket. I would then like to have the script account for a second branch of the same project, and since this script is already on my post hook, when the 2nd branch is committed,have it deploy to a different location then where the develop branch went. (ideally where the production server has its live files)

Could this be possible? If so, then I have found my answer (and what I would assume be a lot of developers answer) to how to deploy code to both staging and live with one Bitbucket post hook with a single script and not having to have repos all over the ying-yang or pay for a service to do this for me. Right now, I'm fine, because I rarely have a production release, so on the server when I'm ready with master I have to SSH to the server, then manually run a second script to pull the master branch and export it, but this script does exactly what I want and would like to streamline the release process.

Alas, there is no way for the same project to have two monitored branches in your otherwise excellent script.

Thanks, Matt

[Alexandru Lixandru]

Hello,

This is indeed one limitation of this script and I am aware of it. The thing is, I was not using multiple branches when I coded this and, at that time, I didn't realize that this feature would be so helpful.

I haven't implemented it yet because of multiple reasons: - this would only make sense if both production and staging would reside on the same machine, otherwise different instances of this script could be used on each of the machines - there is an workaround to this limitation by using 2 instances of this script on the same machine, with 2 different POST hooks posting to each of the script instances, where one instance is configured to deploy the master branch and the other the develop branch. This is however not very elegant and somehow hard to maintain. - this would raise the complexity of the config file, so a different solution would be needed in order to keep the script easy to configure. - nobody asked for it until now :)

If this feature is useful for you and the workaround is not a viable solution, I'd be happy to implement it, as I do think it's something needed by any real-world app.

I will take the time to think a bit about what path to go with the configuration file (using an ini file to define repositories, branches and deploy paths would be an option).

If you have any suggestions in the mean time, don't hesitate to post them here.

Kind regards, Alex

[Matt Esser]

Alex,

Yes, I am currently doing what you suggested since my production and staging reside on the same server, just different websites: dev.website.com and website.com

Basically, I renamed the deploy directory that contains your project to have one that says: deploy-staging and one that says deploy-master, setup both in the POST hooks on Bitbucket and yes, it does in fact work, although inefficient.

What I mean by that is, both scripts get called via the POST hook, and both seem to trigger the zip download even if I didn't update that branch of code. Then it compares what has changed and for the branch that didn't update anything, it correctly does nothing but yet the project flew across the internet to my server twice. Once in staging and once in master. This is understandable because the script was written for one branch and that branch would ALWAYS be the one being committed.

I'm a wannabe developer at best and wish I could help with the code, but some pseudocode might be:

Decode POST information coming into the gateway script to see what branch was just committed to Bitbucket. If it is a branch of a project we care about, go do those things as defined by that branch. If it is a branch we are not monitoring, then exit script.

Of course, I understand if you don't want to build this. Just humbly saying how cool it would be if it did. A continuous log file of what the script did would be helpful too.

[Thien Nguyen]

Yes, this is a helpful feature if you are happy to code, really appreciate your work.

I also face the same issue with Matt when using 2 instances of script with 2 HOOKs in 1 repo. But I found another workaround, that is using 2 different repos with same code: 1 is LIVE, 1 is DEV. Each repo has its own HOOK. And I use those 2 repos as 2 remotes for my code, problem solved but this will cost you storage for the second repo.

[Alexandru Lixandru]

Issue #27 was marked as a duplicate of this issue.

[Alexandru Lixandru]

This is now possible with the new Pipelines feature of BitBucket. Closing this ticket.