Showing posts with label continuous integration. Show all posts
Showing posts with label continuous integration. Show all posts

Sunday, November 13, 2011

Managing multiple job configurations for Jenkins

If you are in the same boat as I am, you find you have too many packages to look after with Jenkins.

The beauty of Jenkins is the simplicity at setting up a job with the web frontend - but once you get over a certain level of complexity this is actually one of the bigger drawbacks.

Sure, we've got some templates, but how far can you really stretch it?

In my situation, I need to:

  1. Trawl SVN/other version control for all packages available - several hundred
  2. Only if the package has tests, add an entry to the CI suite
  3. Adapt to packages which require E_ALL & ~E_STRICT to run happily under that
  4. Packages which require dependencies, but can't be installed, still need a mechanism to install said dependencies
  5. And some which need to be invoked with the legacy AllTests.php
  6. Detect when a package has migrated to github
  7. ... and update an existing build/job with a new tool when required
I had tackled part 1 with pear's "packages-all" SVN link, which pointed to the trunk branches of all relevant code, and written some scripts for cruisecontrol to find all directories with a /tests/, but I find myself in need of something more.

So, my code is on github for now, and you can see the current CI system where those scripts have installed new jobs.

I'm quite sure that pyrus and a local installation will deal with the dependencies; as they are all described with PEAR's package.xml format. Also; detecting when a package has shifted to github should be fairly easy to tackle, as there is much work underway to deal with migration.

The one area I need to explore is manipulating jenkins jobs via xpath, to understand what parts of a job are already present and what need updating - basically number seven in the above list.

I'm curious who's done this sort of thing before, regardless of language, and if there are any libraries which make it easier to do this sort of thing.


Wednesday, November 05, 2008

PEAR Unit test results via Twitter

I just set up a few cron jobs to publish PEAR Unit test results, on the web, and via Twitter / Identi.ca / Atom feed, each and every night.

Go take a look!

Sunday, June 08, 2008

How to customise PHP_CodeSniffer (writing custom coding standards)

PHP_CodeSniffer is a PEAR package which detects potential coding problems and enforces your style guide.

The default is the PEAR coding standard, but you can easily change that.

First,
pear install PHP_CodeSniffer
and
pear install PEAR_PackageFileManager_Cli
.

Second, create a new folder somewhere -
PHP/CodeSniffer/Standards/Foo


Third, you'll want to make a
FooCodingStandard.php
in that directory.

It should look somewhat like:

<?php
if (class_exists('PHP_CodeSniffer_Standards_CodingStandard', true) === false) {
throw new PHP_CodeSniffer_Exception('Class PHP_CodeSniffer_Standards_CodingStandard not found');
}

class PHP_CodeSniffer_Standards_Foo_FooCodingStandard extends PHP_CodeSniffer_Standards_CodingStandard
{

public function getIncludedSniffs()
{
return array(
'Generic/Sniffs/Functions/OpeningFunctionBraceKernighanRitchieSniff.php',
'Generic/Sniffs/NamingConventions/UpperCaseConstantNameSniff.php',
'Generic/Sniffs/Metrics/NestingLevelSniff.php',
'Generic/Sniffs/PHP/DisallowShortOpenTagSniff.php',
'Generic/Sniffs/PHP/ForbiddenFunctionsSniff.php',
'Generic/Sniffs/PHP/LowerCaseConstantSniff.php',
'Generic/Sniffs/WhiteSpace/DisallowTabIndentSniff.php',
'PEAR/Sniffs/Files/IncludingFileSniff.php',
'PEAR/Sniffs/Functions/FunctionCallArgumentSpacingSniff.php',
'PEAR/Sniffs/Functions/FunctionCallSignatureSniff.php',
'PEAR/Sniffs/ControlStructures/ControlSignatureSniff.php',
);

}//end getIncludedSniffs()


}//end class


Spend a little time searching for the sniffs you want to use - some can be a huge help, or a huge pain.

Next, use the CLI tool
pfm
to create a package.xml in
PHP/
. You want to set the base install directory to PHP/; and you want to watch out for case senstivity and the like.

Once you have your package.xml; you just want to type
pear package
in the same directory - if it works, you should have a new .tgz with you can install -
pear install PHP_CodeSniffer_Standards_Foo-0.0.1.tgz


Testing it:
phpcs -i
should show your new coding standard listed here if everything is working correctly.

To set it to your default coding standard:
phpcs --config-set default_standard Foo


What next?
You could set it up to run via Cron across your entire project, or you could integrate it with an SVN post commit hook.