[Buildbot-devel] required fields forcing a build

[Todd Cooper]

OK .. I started to look under the hood.

One question I have is whether or not you should be able to change the repository on the fly with a force.
I can see the need, but should a person at a GUI be able to do that?  What if they are usually building with SVN and they specify a git repo?
Will this not cause havoc with the builder steps? Usually you put in a step in the build which does the code checkout.  Mixing and matching repo types will likely cause havoc.  I suppose I could add a repo to use assuming it is the same of the one defined for that builder(s)


I have some initialization coded, but I can see I need to hook this into many places.


class ForceScheduler():
    """
    Define a ForceScheduler for a scheduler

    """

    def __init__(self, name, authz="", authzRequired=False, 
                 reason="", reasonRequired=False,
                 branch=None, branchRequired=False,
                 properties):
                 
        """
        @type  name: string
        @param name: name of the ForceScheduler

        @type  authz: string
        @param authz: person claiming to be authorized to force build

        @type  authzRequired: bool
        @param authzRequired: Is authorization required?

        @type  reason: string
        @param reason: The reason for this force

        @type  reasonRequired: bool
        @param reasonRequired: When true, forces reason to be filled in

        @type  branch: string
        @param branch: The branch to be built, defaults to None which implies
                       whatever 'trunk' is on your revision system

        @type  branchRequired: bool
        @param branchRequired: require branch be filled in

        @type  revision: string
        @param revision: The revision to be built, defaults to 'HEAD'

        @type  revisionRequired: bool
        @param revisionRequired: require revision to be filled in

        @type  builderNames: list of strings
        @param builderNames: a list of the builders that apply to this
                             ForceScheduler

        @type  properties: dict
        @param properties: a python dict of properties to be set with the 
                           force .. for example

              properties=dict(
                    run_db_tests=SelectParameter({ 'Yes' : 1, 'No' : 0 },
                                                 default='Yes'))


        """





>________________________________
>From: Dustin J. Mitchell <dustin at v.igoro.us>
>To: Todd Cooper <todd_cooper at yahoo.com>
>Cc: "buildbot-devel at lists.sourceforge.net" <buildbot-devel at lists.sourceforge.net>
>Sent: Sunday, September 4, 2011 11:59 AM
>Subject: Re: [Buildbot-devel] required fields forcing a build
>
>On Sun, Sep 4, 2011 at 5:12 AM, Todd Cooper <todd_cooper at yahoo.com> wrote:
>> Sounds a bit elaborate.  I like kiss, keep it stupid simple.
>
>In this case, what we have is KISS, and it's inadequate.  I'm
>particularly sad about the force-all-builds screen, which would make
>any UI designer throw their macbook across the room :)
>
>> I was think more just being felxible enough to make each parameter flexible.
>> I do think the force build needs to be more flexible, but should not not be
>> more with a template?
>
>Yes, you're right -- a template makes a lot more sense than
>dynamically creating a form.
>
>> I so see the need for multiple schedulers with artibrary slaves.  I even see
>> a build forced on a particular slave.
>
>This is where I'd "overrule" you with my experience as maintainer --
>folks use forced builds for an wide array of purposes, and have had to
>hack around its limitations.  There's some benefit to forcing a build
>on a particular slave as a debugging tool, but I think that should be
>separate from the web status (since it's not compatible with the
>current buildset/buildrequest system).
>
>> The way the GUI is now seems somewhat sufficient in that you click on the
>> column head.
>
>So let me lay out what I'm envisioning here:
>
>The ForceScheduler specifies a set of builders, and a set of
>buildrequest parameters.  Each of these can either be hard-wired
>(e.g., always build the 'beta' branch) or input from the web in
>various ways (e.g., text field with optional regexp validation, or
>select box).  Optionally, you can specify a template for the page.
>So:
>
>  s = ForceScheduler(
>    name='smoketest',
>    parameters=dict(
>        branch=TextParameter(),
>        revision='HEAD',
>        properties=dict(
>            run_db_tests=SelectParameter({ 'Yes' : 1, 'No' : 0 },
>default='Yes'),
>        ),
>        repository='git://...')
>    builderNames=[ 'smoke_linux', 'smoke_osx', 'smoke_win' ])
>
>The WebStatus would grow a more advanced /schedulers URI, listing all
>schedulers.  /schedulers/smoketest would contain general info about
>the scheduler, while /schedulers/smoketest/force would render the
>force-build page for that scheduler -- either dynamically generated
>from the given parameters, or rendered from a Jinja2 template
>specified in the scheduler.
>
>A few future-oriented thoughts, before I go:
>- The above leaves open the option of adding a slave "hint" to
>BuildRequests at some point in the future, and hinting in the
>ForceScheduler.  I don't want to do that yet, though.
>- WebStatus is increasingly becoming a built-in part of Buildbot.  At
>some point it will move out of c['status'].  So don't worry about
>tying it down further.
>
>Dustin
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://buildbot.net/pipermail/devel/attachments/20110908/51ab102f/attachment.html>