Allow branch-specific build scripts

[alandekok]

It's sometimes useful to have different build scripts for different branches.

The "build.sh" script is used by default. However, if a "build-$BRANCH.sh" script is defined,
that script is used instead.

We use this locally to build with different compliation flags, or for cross-compiling.

It would be useful to extend gitbuilder to have multiple builds for one branch:

./configure --enable-foo

versus

./configure --disable-foo

It's not clear to me how this can be done with the current framework. The pass/fail status is per commit, not per "variant of commit"

[apenwarr]

On Wed, May 25, 2011 at 9:03 AM, alandekok
reply@reply.github.com
wrote:

It's sometimes useful to have different build scripts for different branches.

The "build.sh" script is used by default.  However, if a "build-$BRANCH.sh" script is defined,
that script is used instead.

We use this locally to build with different compliation flags, or for cross-compiling.

It would be useful to extend gitbuilder to have multiple builds for one branch:

 ./configure --enable-foo

versus

 ./configure --disable-foo

It's not clear to me how this can be done with the current framework.   The pass/fail status is per commit, not per "variant of commit"

Why not just have your build.sh run both?

./configure --enable-foo
make
git clean
./configure --disable-foo
make
...etc...

Similarly, I doubt you actually want to build differently on different
branches based on the branch name; that would be weird, because
there should be no difference between branches with identical files
but two different names. It would also cause a lot of confusion if
you have a branch that builds fine, then you merge it into master and
it no longer builds fine, because 'master' has different build steps.

I'd suggest just having your build.sh do two different things based on
the content of the branch. For example, if there's no Makefile
(like in a documentation branch), don't try to run make. I've used
that technique before and it's quite elegant.

Have fun,

Avery

[alandekok]

I'd rather not do 2 builds from one script because one might succeed and the other fail. It would be "cleaner" to separate the output and success/fail status.

Using branch-specific scripts is nice because they don't conflict with upstream changes. The gitbuilder repo can be updated, and the build.sh script changed completely. But that won't affect any local changes, and there won't be any conflicts to merge.

[apenwarr]

On Thu, May 26, 2011 at 3:24 AM, alandekok
reply@reply.github.com
wrote:

I'd rather not do 2 builds from one
script because one might succeed and
the other fail.  It would be "cleaner"
to separate the output and success/fail status.

Yeah, but that's a generalization of the "I want to have multiple
gitbuilders and see the results all in one place" problem. For
example, running an autobuilder on multiple platforms.

It would be nice to solve that problem in a more general way, I agree,
but it probably involves merging RSS feeds or something.

Using branch-specific scripts is nice because they
don't conflict with upstream changes.  The gitbuilder
repo can be updated, and the build.sh script changed
completely.  But that won't affect any local changes,
and there won't be any conflicts to merge.

Oh, I definitely wouldn't suggest putting the build scripts into the
repository itself. But you could have your build.sh detect the
general shape of whatever commit it's looking at (existence of
Makefile, existence of particular targets in the Makefile, etc) and do
the right thing depending what it sees... including calling into a
branch-specific script if you want.

The important thing is to have the build script depend on the
content instead of the exact name of the branch, so that when you
merge between branches, the build results don't change unless the
content does.

Have fun,

Avery

[apenwarr]

Much time has passed, but I still think per-branch scripts is not the right approach. A given commit might be on multiple branches.

In the intervening years, one option has come up though: like Github actions does it, put your build scripts right inside the repo, and they can do whatever they want.