Home → Support →

Problem with build trigger when tracking a second branch

• Edit

Finnav

08 Oct, 2015 06:00 PM

Hi, I think this is a bug that I'm reporting. We have some repository on GitHub with two branches: master and staging

On AppHarbor, we have two application, Dev app that is set up to track the master branch (using default, with "only build tracking branch" unchecked) and the Staging app that is set up to track the staging branch (with "only build tracking branch" checked) .

So we make check-ins in the master branch: commit#1, commit#2 and commit#3. Each will trigger a new build for the Dev app. Good. Now if we add the same commits into the staging branch, they won't trigger any builds on the Staging app. If we make a new commit to the staging branch that does not exist in the other branch, then it will trigger a new build.

Our workaround for now is after we pull changes from master into staging, we make a dummy check-in at the end to trigger a build on the Staging app. And then we pull out the dummy commit.

I think when you're tracking a branch, it should always trigger a build every time there is a new commit in that branch, regardless of if that change is in any other branch.

1. Support Staff 1 Posted by rune on 09 Oct, 2015 02:57 PM

   

   Hi,

   Ok I'm not sure this is actually a bug, but I can see why it can be a bit confusing with the "Only build tracking branch" set. Essentially it should work the same way you expect (at least on GitHub), i.e. a push to a branch should trigger a build regardless of whether the commits in the branch are also found in another branch). You mention a scenario where you:

   1. Push a few commits on the master branch which triggers a build every time on the Dev app.
      
   2. You then add the same commits to the staging branch, but this does not trigger a build on the staging app.

   How do you add the same commits to the staging branch in step 2? Also, do you push to the branch on GitHub after adding the commits (i.e. git push origin staging) after adding them?

   It may be helpful to disable the "Only build tracking branch" while isolating this. It won't change the behavior with regards to automatic deployments, but it'll allow us to see exactly what branch GitHub sends a notification to AppHarbor about where you push. The feature is really just there to avoid having a lot of builds in your build overview.

   Also, it'd be great if you can let me know a couple of commit ids where a build should've been triggered so I can take a closer look at why it didn't happen.

   Best,
   Rune

   • Edit

2. 2 Posted by Finnav on 09 Oct, 2015 04:59 PM

   

   Hi Rune,

   I use this command to add commits to staging:

   git push origin master:staging
   

   I've also tried updating staging branch locally by rebasing it to the master and then pushing that to github, which didn't work either.

   git checkout master
   git pull
   git checkout staging
   git rebase master
   git push origin staging
   

   The behavior is the same with "Only build tracking branch" checked or unchecked.

   You can try it for yourself:

   • Create two AppHarbor applications and hook them to the same repository on GitHub.
   • Push a commit to origin master
   • Then when the staging branch is behind master, do git push origin master:staging. Even though it updates the branch on GitHub it won't trigger a build on AppHarbor.
   • Then push a new commit to staging which does not already exist in master, making staging ahead of master and that will trigger a build on AppHarbor.
   • Edit

3. 3 Posted by Finnav on 09 Oct, 2015 05:21 PM

   

   Trying to push directly to the AppHarbor git address also didn't work:

   > git push appharbor master:staging
   Counting objects: 112233, done.
   Delta compression using up to 8 threads.
   Compressing objects: 100% (21488/21488), done.
   efrror: RPC failed; result=22, HTTP code = 413iB | 718.00 KiB/s
   atal: The remote end hung up unexpectedly
   Writing objects: 100% (112233/112233), 742.41 MiB | 90.13 MiB/s, done.
   Total 112233 (delta 93251), reused 108485 (delta 89899)
   fatal: The remote end hung up unexpectedly
   

   The command takes too long and it is as if it is trying to copy everything to the remote, and then after about 7 minutes disconnects.

   • Edit

4. Support Staff 4 Posted by rune on 11 Oct, 2015 09:04 PM

   

   Hi again,

   Ok I see what you mean now. The AppHarbor service hook is invoked on the receive_push event, but it seems like GitHub doesn't trigger receive action when the branch ref is just updated (which is essentially what the git push origin staging:master command does).

   I think this can be addressed in a few ways, but the simplest solution is to just disable the "Only build tracking branch" feature. This way all your new code pushes will be built on the applications you've connected with the repository, and given your current workflow this would allow you to simply click the "Deploy" button on the master branch commits which will also be built on the staging app.

   Another way to address this would include changing your workflow a bit. For instance you could:

   1. Develop new code and commit to the staging branch. Pushing will trigger builds on the app tracking the staging branch, so you can test and verify the application before merging into master.
      
   2. When you want to deploy to your production application you change branch to master and merge the staging branch into it, with fast-forward disabled. This will create a merge commit on top of the master branch so you don't have to create another "dummy" commit.

   This approach is that (unlike a fast forward merge) you'll retain historical information about when a branch was merged into master, and the context of those commits. It's similar to the merge commit GitHub make when you create and merge a pull request. I can recommend reading this Stack Overflow answer which discusses the pros and cons of each approach.

   An added bonus is that is also make for a better overview of your builds/deployments on AppHarbor, particularly if you start using more more descriptive "feature branch" names. For instance your, production app tracking the master branch commit messages might look like this if you push every time you merge a feature branch:

   • Merge branch 'support-two-factor-authentication'.
   • Merge branch 'add-user-gravatar'.

   This can make it a lot easier to quickly identify what feature/changes were introduced in a merge. With your current approach the commit message is just the last commit message on your branch (like Remove unused usings) or similar.

   I hope this helps, but please don't hesitate to reach out if this raises new questions or there's anything else I can help with.

   Best,
   Rune

   • Edit

5. 5 Posted by Finnav on 12 Oct, 2015 05:02 PM

   

   Hi Rune,

   master is actually our daily dev branch, we have a staging branch for internal tests and a separate production repo that we push to it from staging for releases. But I think I understood your suggestions. I think merging with fast-forward disabled would work. You may want to document this known issue somewhere in your wikis.

   I think this ticket is resolved.

   Thanks!

   • Edit

6. Support Staff 6 Posted by rune on 13 Oct, 2015 01:13 PM

   

   Hi again,

   Ok great, let me know if this workflow causes problems for you at some point and I might be able to help out. I also forgot to mention another advantage with non fast-forward merges that I value a lot: Consider a scenario where you're on the staging branch and want to integrate and test a new feature (from the dev branch or another feature branch) you'd:

   git merge dev --no-ff
   

   This would create a "Merge branch 'dev' into master" merge commit. Now you can push this to your repo and test how it works, but if you want to roll back the change you can simply delete the merge commit (or, technically, reset the dev branch HEAD ref to point to the previous commit) by doing so:

   git reset --hard HEAD^1
   

   With a fast-forward merge your commits would just appear on the same branch, and you'd have to remember what commits you wanted to delete (or the staging HEAD before the merge).

   Also thanks for the feedback about documenting the behavior when pushing to GitHub. I think in this case the solution will be to remove the option to "Build only from tracking branch" option as that can and will cause confusion in many cases. It was initially added since some customers would push builds to several apps tracking different branches, and building each branch on every app would clutter the build/deployment overview on AppHarbor. It was intended to be a temporary stop-gap measure, but can be handled more elegantly in the UI (by filtering builds based on branches). By doing so it should be possible to make this process much more intuitive so (ideally) developers wouldn't have to consult the documentation at all.

   Best,
   Rune

   • Edit

7. 7 Posted by cottsak on 02 Jan, 2017 12:14 AM

   

   I tried the --no-ff workaround to force the "merge commit" and that seems to work. Problem is that it make the other environment/branch build history dirty too. Seems all too much fuss when I can just-

   On the production site, simply specify a tracking branch prevent-deploy-branch which obviously i never create anywhere and this allows that site to build every commit on master but deploy none of them automatically. Like @Rune said, I just manually "Deploy" the commit I want in my production site and I'm golden. Simple!

   • Edit

8. rune closed this discussion on 03 Jan, 2017 05:21 PM.