varun sharma writes:

On Fri, Mar 7, 2014 at 7:14 AM, Stephen J. Turnbull <stephen@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.