You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
Could you explain the reason why you restrict the branches checked by Travis into master and bb-travis? I would like to check all branches.
@tsuchm : Yes, but first, I'll remind you that I'm no expert in travis, so I'm not sure that my thoughts are true.
The project has many branches, but seems to only actively commit and take pull requests to the master branch, and the other branches seem just historical. I wanted to avoid needless builds and jobs. It's true that using travis doesn't cost ME anything, but there has got to be someone paying for the computing power, accumulated over time, so I don't want to abuse the kindness.
I used my own version of the repository as guidance. There, I have many active branches, but I'm not sure yet that I want travis to perform all those builds every time I push a merge among the branches. For example, my bb_upstream should always be identical to your master, so it doesn't make sense to run travis on merges into that branch. My bb_quibbles is meant to be a persistent development branch, and I have other development branches for issue-specific pull requests, but do they really need travis on every commit push? I thought that they can wait until PR time, when travis will catch them on your side since they are being merged into your master.
Maybe on your side, it will make sense to enable all branches, and see how travis behaves in practice.
What I would really like is to able to tell travis that if the build request was from my account, to restrict it one way, and if it was from another account, to restrict it a second way. There do exist travis environment variables that might identify the github repo responsible for the build, but I'm not sure how to construct a conditional yaml statement based upon them.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.