pear:qa:ci
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
pear:qa:ci [2010/01/08 21:11] – external edit 127.0.0.1 | pear:qa:ci [2012/04/12 23:32] – More details on jenkins clockwerx | ||
---|---|---|---|
Line 3: | Line 3: | ||
===== PHPCS and General QA tools ===== | ===== PHPCS and General QA tools ===== | ||
- | [[cweiske|Christian]] hosts continuous integration results | + | http:// |
- | * http:// | + | * [[http:// |
- | * http:// | + | * [[http://test.pear.php.net:8080/|Jenkins]] |
- | * http:// | + | * [[http://test.pear.php.net/unit-test-results/|(old) Test results |
+ | * [[https:// | ||
+ | |||
+ | The helper scripts live at https:// | ||
+ | |||
+ | ===== Jenkins ===== | ||
+ | Jenkins is a continuous integration platform. Currently, all packages in both PEAR and PEAR2 were scanned for the presence of a ' | ||
+ | |||
+ | ==== Access === | ||
+ | Jenkins is configured to authenticate against the github organisations of pear / pear2. You simply need to be associated with one of the organisations to modify builds. | ||
+ | |||
+ | ==== Adding a new job/build ==== | ||
+ | * Create job | ||
+ | * Enter package name | ||
+ | * Enter link to github | ||
+ | * Enter the read-only git url into source management | ||
+ | * Select 'build on push from github' | ||
+ | * Add either manual build steps or invoke an ant build.xml target. Manual steps should include executing | ||
+ | * phpunit --coverage-html build/ | ||
+ | * php ~/ | ||
+ | * Add in Post-build Actions for ' | ||
+ | |||
+ | ==== How do I make sure my tests work? ==== | ||
+ | In general, we encourage the use of an appropriate phpunit.xml - we target PHPUnit 3.6 at this time. | ||
+ | |||
+ | Your package directory layout should allow you to successfully run your test suite as below: | ||
+ | <code bash> | ||
+ | $ cd Foo_Bar/ | ||
+ | $ phpunit -c phpunit.xml tests/ | ||
+ | </ | ||
+ | |||
+ | |||
+ | ==== My directory layout doesn' | ||
+ | A common pattern with older packages is to have a directory structure which is unlike the installed package layout. IE: '' | ||
+ | |||
+ | To fix this: | ||
+ | <code bash> | ||
+ | $ svn mkdir Foo | ||
+ | $ svn mv Bar.php Foo/ | ||
+ | # Edit package.xml, | ||
+ | $ vim package.xml | ||
+ | |||
+ | # Rebuild package using PEAR_PackageFileManager_CLI | ||
+ | $ pfm | ||
+ | |||
+ | # Run tests to confirm no fatal errors, using one of | ||
+ | $ pear run-tests -r tests/ | ||
+ | $ phpunit tests/ | ||
+ | |||
+ | # Commit | ||
+ | $ svn commit -m " | ||
+ | </ | ||
+ | |||
+ | ==== Pyrus won't build my package 1.0 ==== | ||
+ | See [[pear: | ||
+ | |||
+ | ==== My unit tests need a (database/ | ||
+ | Two strategies exist for this: | ||
+ | - Making use of PHPUnit' | ||
+ | - Checking your environment and skipping the test if it cannot run | ||
+ | |||
+ | There is also a test mysql instance available. | ||
+ | |||
+ | > Hi Daniel: | ||
+ | > | ||
+ | > On Wed, Nov 16, 2011 at 08:34:04AM +1030, Daniel O' | ||
+ | > > http://test.pear.php.net:8080/job/ | ||
+ | > > | ||
+ | > > This and a few others obviously need a database to be tested properly. | ||
+ | > > Certainly that machine has mysql on it; or sqlite is probably available - | ||
+ | > > what would be needed to load up an appropriate schema/tear it down after | ||
+ | > > the tests? | ||
+ | > | ||
+ | > I agree and mentioned this on pear-qa a while ago. Take a look at what | ||
+ | > I committed to DB tests yesterday. | ||
+ | > MYSQL_TEST_* environment variables, which are used for PHP's tests. | ||
+ | > should create a test user and database and set those environment | ||
+ | > variables in the cron job, or whatever. | ||
+ | > | ||
+ | > A similar setup should be made for PostgreSQL in PEAR and PHP's unit | ||
+ | > tests. | ||
+ | > | ||
+ | > SQLite3 tests should use ": | ||
+ | > | ||
+ | > Thanks, | ||
+ | > | ||
+ | > --Dan | ||
+ | |||
+ | ==== Build tools ==== | ||
+ | In general, ant is the preferred way of managing a build after a certain level of complexity. See http:// | ||
+ | |||
+ | Noteably, we prefer phpdoc/ | ||
+ | |||
+ | Some packages use phing | ||
+ | |||
+ | ==== Dependencies ==== | ||
+ | There are two available techniques for managing dependencies without installing system wide libraries. | ||
+ | |||
+ | The first is relatively straight forward - simply pulling the library from source and pushing it into a lib directory. | ||
+ | <code bash> | ||
+ | $ git clone git:// | ||
+ | $ git clone git:// | ||
+ | $ phpunit --include-path lib/ | ||
+ | </ | ||
+ | |||
+ | This can be either configured in the jenkins build or (preferred) in the relevant build.xml and phpunit.xml files. | ||
+ | |||
+ | |||
+ | The second is to utilise [[http:// | ||
+ | |||
+ | ==== Todo ==== | ||
+ | - Put more packages into jenkins | ||
+ | - Investigate a notification task to package maintainers? | ||
+ | - Investigate allowing bootstrapped build.xml files back in (Pyrus) | ||
+ | - Upgrade PHP on test.pear.php.net | ||
+ | - Install xdebug for proper code coverage | ||
===== How to test a new PEAR release ===== | ===== How to test a new PEAR release ===== | ||
Before releasing a new version of PEAR, we need to make sure it runs on as many systems as possible. It's pretty easy: | Before releasing a new version of PEAR, we need to make sure it runs on as many systems as possible. It's pretty easy: | ||
- | - Install the new PEAR (1.7.0RC2 currently) | + | - Install the new PEAR |
- Make sure you have the XML_RPC package | - Make sure you have the XML_RPC package | ||
- | - Checkout pear-core from CVS to get the tests | + | - Checkout pear-core from the repository |
- Run the tests | - Run the tests | ||
Line 19: | Line 134: | ||
pear upgrade -f PEAR | pear upgrade -f PEAR | ||
pear upgrade XML_RPC | pear upgrade XML_RPC | ||
- | cvs -d :pserver: | + | git clone git://github.com/pear/pear-core.git |
cd pear-core/ | cd pear-core/ | ||
</ | </ | ||
Line 31: | Line 146: | ||
* For some tests the executable php-cgi is needed. In some Linux distributions this is contained in a separate package, but on for instance Gentoo Linux this has to be enabled using the cgi USE flag. | * For some tests the executable php-cgi is needed. In some Linux distributions this is contained in a separate package, but on for instance Gentoo Linux this has to be enabled using the cgi USE flag. | ||
* If running on linux, do not run the tests as root | * If running on linux, do not run the tests as root | ||
- | |||
- | |||
- | ===== Unit tests ===== | ||
- | There are nightly unit test results published at [[http:// | ||
- |
pear/qa/ci.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1