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

[varun sharma]

Thanks Florian for these suggestions, i have added some more details that i
think need to be discussed.

On Mon, Mar 3, 2014 at 3:01 PM, Florian Fuchs <flo.fuchs at gmail.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> On 02/22/2014 07:54 AM, Varun Sharma wrote:
> > Hi all, I am interested in continuous integration tool as my gsoc
> > project and would like to discuss further it's possible
> > implementations. I think one possible implementation for gatekeeper
> > is :
> >
> > Making another django project mm_gatekeeper which every developer
> > must run in order to commit to trunk. We can host its repo of on
> > launchpad. It will act as a proxy to bzr and will perform bzr
> > commit only after all the unit and doc tests succeeds.
> >
> >
> > bzr pull can be implemented as
> >
> > $ mm_gatekeeper PROJECT_NAME pull
> >
> > or to pull all projects
> >
> > $ mm_gatekeeper pull
> >
> >
> > Instead of using bzr commit in postorius we can use
> >
> > $ mm_gatekeepar PROJECT_NAME COMMAND
> >
> > $ mm_gatekeeper postorius commit -m"commit message"
> >
>
> I like the idea of having a command line tool to run integration tests!
> It could be used both by the devs working on the different packages as
> well as on a central ci server that runs those tests regularly. But
> I'm not sure it should be tied that closely into the commit/merge
> process:
>
> When a developer works on a new feature in a branch separate from the
> main line, it's probably very common to commit small changes that
> would break the whole system, but are commit-worthy anyway because
> they sum up a small series of changes in a chain of more commits that
> eventually lead to a mergeable state.
>
> So when I (as a developer) *think* my stuff is ready to be merged into
> trunk, *that's* when I would like to check if everything's fine and
> run the integration testing tool.
>
> Another thought: What versions of the various Mailman packages should
> the ci tool test against? Should that be configurable for different
> test scenarios? Like:
>
> - - Use the branch I'm currently working on, but get all other packages
> from their respective main lines (the perspective of a developer
> working on a new feature before merging).
>
> - - Use the current main line of one package, but everything else from
> pypi (the perspective of a developer when preparing the release of one
> package)
>
> - - ...?
>
I think we can include a list of branches/versions to be fetched for
testing of integration in settings for every project .
I also wanted to discuss, whether it's a good idea to test the code on the
developers machine before committing or we should just go by the buildbot
implementation(running builds on different servers after getting a commit
on repository).

If we run tests on developer's machine:
Pros:
1. The possible integration error can be detected early, and can prevent
committing the erroneous code.
Cons:
1. All the developers of different projects will be required to pull the
code of all the projects involved in the suite.
2. Running unit tests may take more time on developers machine than on
slave server.

If we run tests after getting commit on trunk:
Pros:
1. We can set different slave servers with different operating systems just
like buildbot and the tests will be more reliable.
2. Time of developer in running the tests for all the projects can be saved.
Cons:
1. The erroneous code in the trunk may get exposed to the end users before
getting fixed by the developer.

So I think we should have a mix of these two :)


> Why would you use Django to build the tool as opposed to "just" a
> python package?
>
I was thinking of expanding it like buildbot to include django based GUI
and detailed reports. So i thought we can use django, but if we just want a
command line tool, then python module will be fine.

>
>
> Cheers,
> Florian
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJTFEvWAAoJEEceGbPdavl7UPMH/A5cd7PWdw+qMaOFRfxfTVuV
> lvwdwTOb/Z7oeeE5bol/czvuG7ejaBi5fVxerSb2Ffo4N8aESP1gmxt4U+Qp1SFr
> 0oIORix0L35Kz19MurbODaZzphjZB5Hf/F/Fu0OgbS4KmDf1nnMvVvXusB6vOxM4
> lvg/AOb1GyGuYd78Cj4GA2CY6oCfh2pAjmzUKI4ULvzHjGFHYtjanmYgaB+cjdwB
> mNaZbJtQKcjBTvl6iXAON0MU2SzmMG9psA/LcR2hRQMZncBxe0Lbh3fEAA7IHuKe
> rzqT2lyX3cBZtvsH06TlLwYmxyJp8Z3HTv6Txj7y+YvvrL4Sj5c6fYTts7OtE1M=
> =fci5
> -----END PGP SIGNATURE-----
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers at python.org
> https://mail.python.org/mailman/listinfo/mailman-developers
> Mailman FAQ: http://wiki.list.org/x/AgA3
> Searchable Archives:
> http://www.mail-archive.com/mailman-developers%40python.org/
> Unsubscribe:
> https://mail.python.org/mailman/options/mailman-developers/varunsharmalive%40gmail.com
>
> Security Policy: http://wiki.list.org/x/QIA9
>

Thanks
Varun