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

Florian Fuchs flo.fuchs at gmail.com
Mon Mar 3 10:31:02 CET 2014


-----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)

- - ...?

Why would you use Django to build the tool as opposed to "just" a
python package?


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-----


More information about the Mailman-Developers mailing list