| Message ID | 1408625696-42975-1-git-send-email-Matthew.Weber@rockwellcollins.com |
|---|---|
| State | Superseded |
| Headers | show |
Dear Matt Weber, On Thu, 21 Aug 2014 07:54:56 -0500, Matt Weber wrote: > Adds an option to specify a specific branch for the autobuilder > to execute against (Defaults to the master branch). > > Signed-off-by: Matt Weber <Matthew.Weber@rockwellcollins.com> > --- > > Changes v1 -> v2 > - Fixed assignment of br_branch value to variable > when reading config from file. (Suggested by Clayton S) What is the intended usage of this? Because customizing the branch without being able to customize the Git repository from which we're getting the Buildroot sources seems a bit odd. Or is it just to test the 'next' branch? Also, there's the issue of the build results being submitted on autobuild.buildroot.org: on this site, for now, we don't have any concept of "branch" or multiple versions being tested. We simply assume that the only thing we're testing is the master branch, and that this branch is evolving progressively over time. If the autobuild-run script then grows the capability of testing other branches/repositories than just the master branch of the official Buildroot repository, it raises the question of what happens when those build results are submitted to autobuild.buildroot.org. Thanks! Thomas
Dear Thomas, On Fri, Aug 29, 2014 at 12:24 PM, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote: > Dear Matt Weber, > > On Thu, 21 Aug 2014 07:54:56 -0500, Matt Weber wrote: >> Adds an option to specify a specific branch for the autobuilder >> to execute against (Defaults to the master branch). >> >> Signed-off-by: Matt Weber <Matthew.Weber@rockwellcollins.com> >> --- >> >> Changes v1 -> v2 >> - Fixed assignment of br_branch value to variable >> when reading config from file. (Suggested by Clayton S) > > What is the intended usage of this? Because customizing the branch > without being able to customize the Git repository from which we're > getting the Buildroot sources seems a bit odd. Or is it just to test > the 'next' branch? I hadn't thought about testing the 'next' branch. That's could be a good idea to reduce the number of days after a release where things aren't stable. I'm making an assumption that the autobuilder script could also be used for testing a personal/corporate mirror of the Buildroot repository where development is being done on branches before submission of patch sets to the mailing list. My initial use case for doing this is for the SELinux patch set. I'm hoping to do a bunch of internal regressions before submitting the v6 patch set. For this branch cfg option patch, we didn't include the option to configure the repository since it seemed the primary purpose of the autobuilder was for testing the mainline Buildroot repository. Instead we currently carry the commit of the repository path change as a local modification that we rebase on top of our local buildroot-test repository clone. I'd gladly update the patch to include the repository cfg option and have it default to the main Buildroot repo. Another item to note about how we're using the script... We're currently not thinking about sending results to the autobuilder results server, since they would reflect our personal branchs/commits. The results would purely be used to refine the proposed updates that haven't yet been posted as a patch set or to refine revisions of a patchset. Since the results aren't submitted and kept local, I'm thinking about adding some scripting to the autobuilder script that provides an option to create a static website from the archive files on the fly, which would make going through the failure cases a bit easier. Related to build resources, I might be able to dedicate some resources to running another instance of the autobuilder, however with the results submission, does it upload all the logfiles and information to your server or does it link back to mine (webhosting content)? I think I can http 'post' results, but serving up any content would probably not be possible at this point. > > Also, there's the issue of the build results being submitted on > autobuild.buildroot.org: on this site, for now, we don't have any > concept of "branch" or multiple versions being tested. We simply assume > that the only thing we're testing is the master branch, and that this > branch is evolving progressively over time. If the autobuild-run script > then grows the capability of testing other branches/repositories than > just the master branch of the official Buildroot repository, it raises > the question of what happens when those build results are submitted to > autobuild.buildroot.org. Agreed, per my comments above it wasn't my original intention to use the script against branches and have it actively do a submission to the autobuilder site. However it might be an interesting discussion item to see if it would be worth having for the 'next' branch. (At this point, I'm guessing it isn't worth doing since it would split resources away from regressioning the 'master' branch) Thanks!
diff --git a/scripts/autobuild-run b/scripts/autobuild-run index dcb8dbd..9ebea30 100755 --- a/scripts/autobuild-run +++ b/scripts/autobuild-run @@ -171,6 +171,13 @@ def prepare_build(instance, log): log_write(log, "ERROR: could not pull Buildroot sources") return -1 + # Update to a specific branch for regression test + abssrcdir = os.path.abspath(srcdir) + ret = subprocess.call(["git", "checkout", br_branch], cwd=srcdir, stdout=log, stderr=log) + if ret != 0: + log_write(log, "ERROR: could not checkout Buildroot branch [%s]" % br_branch) + return -1 + # Create an empty output directory. We remove it first, in case a previous build was aborted. outputdir = os.path.join(idir, "output") if os.path.exists(outputdir): @@ -431,7 +438,7 @@ def send_results(instance, http_login, http_password, submitter, log, result): # This function implements the main per-instance loop, which prepares # the build, generate a configuration, runs the build, and submits the # results. -def run_instance(instance, njobs, http_login, http_password, submitter): +def run_instance(instance, njobs, http_login, http_password, submitter, br_branch): idir = "instance-%d" % instance # If it doesn't exist, create the instance directory @@ -466,6 +473,7 @@ Format of the configuration file: http-login = <value> http-password = <value> submitter = <value> + br_branch = <value> """ parser = argparse.ArgumentParser(description='Run Buildroot autobuilder', @@ -479,6 +487,8 @@ Format of the configuration file: help="Name/machine of submitter") parser.add_argument("--config", '-c', metavar="CONFIG", help="Path to configuration file") + parser.add_argument("--br_branch", '-b', metavar="BR_BRANCH", + help="Name of Buildroot branch to regression") args = parser.parse_args() ninstances = 1 @@ -486,6 +496,7 @@ Format of the configuration file: http_login = None http_password = None submitter = "N/A" + br_branch = "master" if args.config: if not os.path.exists(args.config): @@ -505,6 +516,8 @@ Format of the configuration file: http_password = parser.get('main', 'http-password') if parser.has_option('main', 'submitter'): submitter = parser.get('main', 'submitter') + if parser.has_option('main', 'br_branch'): + br_branch = parser.get('main', 'br_branch') if args.njobs: njobs = int(args.njobs) @@ -512,22 +525,25 @@ Format of the configuration file: ninstances = int(args.ninstances) if args.submitter: submitter = args.submitter + if args.br_branch: + br_branch = args.br_branch - return (ninstances, njobs, http_login, http_password, submitter) + return (ninstances, njobs, http_login, http_password, submitter, br_branch) if __name__ == '__main__': check_version() check_requirements() - (ninstances, njobs, http_login, http_password, submitter) = config_get() + (ninstances, njobs, http_login, http_password, submitter, br_branch) = config_get() if http_login is None or http_password is None: print "WARN: due to the lack of http login/password details, results will not be submitted" print "WARN: tarballs of results will be kept locally only" + print "NOTE: Testing branch --> %s" % br_branch def sigterm_handler(signum, frame): os.killpg(os.getpgid(os.getpid()), signal.SIGTERM) sys.exit(1) processes = [] for i in range(0, ninstances): - p = Process(target=run_instance, args=(i, njobs, http_login, http_password, submitter)) + p = Process(target=run_instance, args=(i, njobs, http_login, http_password, submitter, br_branch)) p.start() processes.append(p) signal.signal(signal.SIGTERM, sigterm_handler)
Adds an option to specify a specific branch for the autobuilder to execute against (Defaults to the master branch). Signed-off-by: Matt Weber <Matthew.Weber@rockwellcollins.com> --- Changes v1 -> v2 - Fixed assignment of br_branch value to variable when reading config from file. (Suggested by Clayton S) scripts/autobuild-run | 24 ++++++++++++++++++++---- 1 file changed, 20 insertions(+), 4 deletions(-)