[cryptography] [OT] openssl on git

Jeremy Stanley fungi at yuggoth.org
Wed Jan 9 13:25:02 EST 2013

On 2013-01-09 01:02:33 -0600 (-0600), Nico Williams wrote:
> Some even go so far as to trigger an incremental build to check
> that all is ok (but rarely is this done synchronously, and so
> build failures -> email, possible backout, ...).
> Some such checkers can easily be found by searching around. The
> Solaris gate checks are, IIRC, in OpenSolaris and derivatives, for
> example, but I've seen others.

I help support the developer community infrastructure for the
OpenStack project, and we basically break it down in two places.
Changes are initially checked into a code review system (Gerrit)
where our gatekeeper (Zuul) sees the upload event and kicks off
style, lint and unit tests (on Jenkins slaves) for that subproject
with the patch applied to the target branch. The test results are
fed back into comments in the review for that change and the
developer possibly continues to upload modified iterations of the
change based on feedback from reviewers and tests. These same
test suites and checkers feature prominently in the developer
documentation for each subproject and are made readily available, so
the hope is that this stage of automated testing merely confirms the
patch is viable (but it does still often get abused for
trial-and-error uploads as warned about elsewhere in this thread).

Once the code is also approved by core contributors to the
subproject, the gatekeeper automatically attempts to merge it to the
tip of that branch and fires off a full suite of integration tests
with all the other subprojects together in a simulated production
environment built on-demand for that change. The integration
exercises are also thoroughly documented, and many developers will
run them on their patches before upload as well if they're worried
about some particular interoperability change. If all those complete
successfully, the patch winds up in the master Git repository for
the subproject and gets automatically published in typical ways
(tarballs built and made available for download, updated
documentation uploaded to Web servers, commits sync'd to Github, et

We do also have a client-side git commit hook which amends the
commit message with header information used by the code review
system, but we definitely don't use any hooks to modify the
committed source code itself. Contributors should always be aware of
published style requirements, and it's their responsibility to not
write sloppy code. It does help that most of our software is written
in Python, so we're able to automatically check it for PEP8 style
conformance using the "pep8" utility.

An overview of our continuous integration can be found here, though
I can provide more specific pointers to the published source for all
our installation and integration scripting as well if anyone's
interested and has trouble finding it themselves:


{ WHOIS( STANL3-ARIN ); WWW( http://fungi.yuggoth.org/ );
PGP( 48F9961143495829 ); MUD( kinrui at katarsis.mudpy.org:6669 );
FINGER( fungi at yuggoth.org ); IRC( fungi at irc.yuggoth.org#ccl ); }

More information about the cryptography mailing list