[Mailman-Developers] Gsoc idea discussions : Continuous integration tool

[Stephen J. Turnbull]

varun sharma writes:
 > On Fri, Mar 7, 2014 at 7:14 AM, Stephen J. Turnbull <stephen at xemacs.org>wrote:

[ long irrelevant quote snipped -- please trim!  If you really can't
trim because you're using a handheld in a crowded bus on a very bumpy
road, please *top* post, but make sure your text includes enough
context -- readers should not have to dig through a long quote to find
the exact text you are responding to. ]

 > Sorry, if i wasn't clear enough but from frontend suite i meant the command
 > line interface that is going to check for the integrity before the commit
 > (i.e mm_gatekeeper on developer's machine).

OK.  Why is this a CLI (command line interface)?  Does it need to be
controlled by hand?  Isn't this going to be some sort of daemon
triggered by commits to the trunk (or other "watched" branch)?  Below
you write "python module" -- if that's what you mean, it's a better
way to express it.

 > I was trying to say that: Is it possible if i write the command
 > line interface myself by adding all the unit tests for all the
 > projects to be involved in the integration suite and let buildbot
 > handle the build testing part ?

Yes.  This is not only permissible, it's good design, and very
desirable.

 > The work that i am expecting to do in this project is:
 > 1. Write a python module mm_gatekeeper that will handle all the integration
 > tests for all the projects involved in the mailman suite on the developer
 > machine before commit.

OK.  I'm not sure what you mean by "integration tests".

Also, as I understand it, usually "continuous integration" does not
refer to "integration of components with each other", but instead it
means "integration of new code into the public repository".  Ie,
although testing is part of it, it's really a workflow manager, not a
test framework.

If you're interested in integration testing of the components, that is
not a problem, we can use that.  But we should straighten out our
terminology so everybody is expecting the same project.

 > 2. Forking buildbot for adding build testing from the repository and
 > tweaking the buildbot code to meet our requirements.

Do this only if necessary, I think.  We can discuss when you get to
actual coding, of course.  But

1. buildbot should be pretty flexible, enough to handle this task.
2. If you only need a little bit more, it might be better to "wrap"
   buildbot with extra capability rather than "change" it.
3. If you do need to change it, we will definitely ask that you try to
   get upstream to add the additional capabilities.

 > I deployed buildbot with aws ec2 on postorius independently by adding repo
 > of postorius_standalone at http://dev.sharmalabs.com:8010 and
 > added the commands that are required to run the unit tests.

OK, that looks pretty cool.

I suggest you add the URL for your code repo to
http://dev.sharmalabs.com:8010/about.

All of your Internet facing sites should have an "about" or "home"
page with links to all of the others.

Do you have a blog?

Sorry if you have already posted all that information.  Remember that
we have a lot of students, most of us participate in multiple lists
which are currently swamped with GSoC students, and some of us mentor
for more than one org (or are org admins, which also takes up a lot of
time and energy -- thank you Terri!).  Please humor us if we ask for
your information more than once.