[pull-request][kteam-tools] Add test-build script.
Chris J Arges
chris.j.arges at canonical.com
Wed Apr 10 12:16:51 UTC 2013
On 04/10/2013 05:12 AM, Andy Whitcroft wrote:
> On Tue, Apr 09, 2013 at 01:26:43PM -0700, Brad Figg wrote:
>> On 04/09/2013 12:31 PM, chris.j.arges at canonical.com wrote:
>>> The following changes since commit da5872fc64a738606afc922f6a3de05a0cb307b4:
>>> config summary: drop erroneous local paths (2013-04-09 17:01:49 +0100)
>>> are available in the git repository at:
>>> git://kernel.ubuntu.com/arges/kteam-tools.git master
>>> for you to fetch changes up to 94af9950fc2bcb3c38c381174ed08a540411dd34:
>>> buildscripts: test-build.sh script added (2013-04-09 14:19:36 -0500)
>>> Chris J Arges (2):
>>> kernel-team-accounts: fix account name
>>> buildscripts: test-build.sh script added
>>> buildscripts/test-build.sh | 149 +++++++++++++++++++++++++++++++++
>>> kernel-team-accounts/kernel_devs.conf | 4 +-
>>> 2 files changed, 151 insertions(+), 2 deletions(-)
>>> create mode 100755 buildscripts/test-build.sh
>> Nice script Chris. It looks quite useful. However, (and this is not directed
>> directly at Chris but the group at large) how many different build
>> scripts do we need. Rather than having everyone write a new script I'd like
>> to see us improve the one(s) that we have. I think a lot can be said for us
>> using the same tools.
> One each?
> I think one of the big issues is that Chris has added a new one here.
> "Here it is yay!", I still have no idea what it does, whether it is
> better than my own ones (yes another another one) or not etc.
Good point. I put some info into the git commit, but perhaps a cover
letter would have been better.
This script helps me with my workflow for fixing linux kernel bugs and
building test packages. It works by allowing me to have a local git tree
with my changes committed to a separate branch or master. Then I can use
this script in one line to clone a proper tree on a remote box, push the
changes, and start a build with arch/flavor/ddebs specified.
The script also infers some variables from the git tree and changelogs
itsself. In addition it appends a user specified string to the build
such as "3.8.0-0~lp1234v20130410". This allows me to track which LP# the
build is associated with and what date it was built on.
For example working in a local tree:
git checkout -b lp1234
git cherry-pick -exs <hash>
test_build.sh -a i386 -d -b gomeisa.buildd
# time passes...
# scp the build from the remote machine to wherever I want it
More information about the kernel-team