adapt travis-ci build for branch handling
McFoggy opened this issue · 4 comments
- Not all branchs have a travis.yml build instruction file.
- Also it would be good if we could adapt our build file so that we can have badges for each branch (ie a build fail on branch 8.0 is not seen as a build fail in branch 2.2).
It should be fairly trivial to add the travis.yml to the other branch; we currently only have two, 2.2 and 8.0
What does that involve, "having badges"?
On 2013-11-21 8:39, Matthieu Brouillard wrote:
- Not all branchs have a travis.yml build instruction file.
- Also it would be good if we could adapt our build file so that we can have badges for each branch (ie a build fail on branch 8.0 is not seen as a build fail in branch 2.2).
—
Reply to this email directly or view it on GitHub #77.
Yes it should.
Pushing a travis.yml version in the 8.0 branch might not be difficult.
What need a little bit more effort, or at least read some docs & exemples, is to find a way to distinguish branches in travis-ci. I have already seen things around this topic, so it just a matter of taking one hour to have a look. I'll do it next sunday.
The badges are the "icons" representing the build status in the readme.md on the project page.
There also if we could distinguish between branches it would be clean instead of having only the "latest" build result regardless the branch that fired the build.
In jenkins you can specify in the GIT plugin what branch it needs to checkout. The URL of course checks out the default 2.2 branch and that will change to 8.0 when J(FX)8 comes out.
On 2013-11-21 20:14, Matthieu Brouillard wrote:
Yes it should.
Pushing a travis.yml version in the 8.0 branch might not be difficult.
What need a little bit more effort, or at least read some docs & exemples, is to find a way to distinguish branches in travis-ci. I have already seen things around this topic, so it just a matter of taking one hour to have a look. I'll do it next sunday.The badges are the "icons" representing the build status in the readme.md on the project page.
There also if we could distinguish between branches it would be clean instead of having only the "latest" build result regardless the branch that fired the build.—
Reply to this email directly or view it on GitHub #77 (comment).
Closed because of inactivity