Phpundercontrol / Ant - a way to have a fast & slow build?

Ye' old general discussion board. Basically, for everything that isn't covered elsewhere. Come here to shoot the breeze, shoot your mouth off, or whatever suits your fancy.
This forum is not for asking programming related questions.

Moderator: General Moderators

Post Reply
josh
DevNet Master
Posts: 4872
Joined: Wed Feb 11, 2004 3:23 pm
Location: Palm beach, Florida

Phpundercontrol / Ant - a way to have a fast & slow build?

Post by josh »

My tests run in 10 minutes on windows but 40 seconds on linux. Kinda odd. Anyways if I ask for code coverage or something they end up taking just as long. Is there a way in phpundercontrol or cruise control (ant) to have the fast build happen at check in? and run the slow one at midnight so I can keep my reports & metrics updated? Is it possible?
User avatar
Weirdan
Moderator
Posts: 5978
Joined: Mon Nov 03, 2003 6:13 pm
Location: Odessa, Ukraine

Re: Phpundercontrol / Ant - a way to have a fast & slow bui

Post by Weirdan »

To be honest I have no idea if there's something like this in puc/ant, but you can do whatever you want in svn's pre/post commit hooks. Including running your tests with whatever configuration you need.
josh
DevNet Master
Posts: 4872
Joined: Wed Feb 11, 2004 3:23 pm
Location: Palm beach, Florida

Re: Phpundercontrol / Ant - a way to have a fast & slow bui

Post by josh »

Ok thanks, as far as I see I have two work arounds, 1) set up two projects that share the same local working copy. First project will run the tests & fail quickly on any modification. The other project will run off triggers only and will generate metrics. Or 2)just run my metrics programs outside of the build tool via a cronjob.

The issue I seem to be having is PHP code sniffer is using up 100% CPU. I let it run all night. If I run it on one module in my project at a time it completes instantly. But if I point it to the whole project it runs all night & never finishes. I just want something that will help me find long methods or highly nested code I let slip by, do you know any good & fast tools?

PS > I guess PHP code sniffer crashes if it hits a sub folder in your project that has a few regular .html files and stuff in it. It parses all my code quickly but crashes on my documentation folder. lol
User avatar
Weirdan
Moderator
Posts: 5978
Joined: Mon Nov 03, 2003 6:13 pm
Location: Odessa, Ukraine

Re: Phpundercontrol / Ant - a way to have a fast & slow bui

Post by Weirdan »

We use CodeSniffer here in a pre-commit hook - works perfectly. The trick is to check only changed files. Why would you want to check entire project on a regular basis?
josh
DevNet Master
Posts: 4872
Joined: Wed Feb 11, 2004 3:23 pm
Location: Palm beach, Florida

Re: Phpundercontrol / Ant - a way to have a fast & slow bui

Post by josh »

Don't know. So in your team if a developer gets a warning from code sniffer he has to stop and fix it right there? (or decides whether it gets fixed). Let's say someone lets some less than ideal code thru, how do you go back and find kludges at later dates?

Also could you share your post commit hook so I can how you're piping in the list of change files and such?
User avatar
Weirdan
Moderator
Posts: 5978
Joined: Mon Nov 03, 2003 6:13 pm
Location: Odessa, Ukraine

Re: Phpundercontrol / Ant - a way to have a fast & slow bui

Post by Weirdan »

josh wrote:Don't know. So in your team if a developer gets a warning from code sniffer he has to stop and fix it right there? (or decides whether it gets fixed). Let's say someone lets some less than ideal code thru, how do you go back and find kludges at later dates?
We have a strict policy: if you can't keep CodeSniffer happy - you can't commit. It's enforced by putting the sniffer check into pre-commit hook and aborting the commit if the hook is failed. As such there's no warnings - only errors.
Granted, it's a little bit annoying when you start to apply this policy. But over time it gets easier and easier, as code gets more and more compliant.
Also could you share your post commit hook so I can how you're piping in the list of change files and such?
We use a little sh script to invoke PCS's pre-commit hook script that's provided in their distribution:

Code: Select all

#!/bin/sh

# PRE-COMMIT HOOK
#
# The pre-commit hook is invoked before a Subversion txn is
# committed.  Subversion runs this hook by invoking a program
# (script, executable, binary, etc.) named 'pre-commit' (for which
# this file is a template), with the following ordered arguments:
#
#   [1] REPOS-PATH   (the path to this repository)
#   [2] TXN-NAME     (the name of the txn about to be committed)
#
# The default working directory for the invocation is undefined, so
# the program should set one explicitly if it cares.
#
# If the hook program exits with success, the txn is committed; but
# if it exits with failure (non-zero), the txn is aborted, no commit
# takes place, and STDERR is returned to the client.   The hook
# program can use the 'svnlook' utility to help it examine the txn.
#
# On a Unix system, the normal procedure is to have 'pre-commit'
# invoke other programs to do the real work, though it may do the
# work itself too.
#
#   ***  NOTE: THE HOOK PROGRAM MUST NOT MODIFY THE TXN, EXCEPT  ***
#   ***  FOR REVISION PROPERTIES (like svn:log or svn:author).   ***
#
#   This is why we recommend using the read-only 'svnlook' utility.
#   In the future, Subversion may enforce the rule that pre-commit
#   hooks should not modify the versioned data in txns, or else come
#   up with a mechanism to make it safe to do so (by informing the
#   committing client of the changes).  However, right now neither
#   mechanism is implemented, so hook writers just have to be careful.
#
# Note that 'pre-commit' must be executable by the user(s) who will
# invoke it (typically the user httpd runs as), and that user must
# have filesystem-level permission to access the repository.
#
# On a Windows system, you should name the hook program
# 'pre-commit.bat' or 'pre-commit.exe',
# but the basic idea is the same.
#
# The hook program typically does not inherit the environment of
# its parent process.  For example, a common problem is for the
# PATH environment variable to not be set to its usual value, so
# that subprograms fail to launch unless invoked via absolute path.
# If you're having unexpected problems with a hook program, the
# culprit may be unusual (or missing) environment variables.
#
# Here is an example hook script, for a Unix /bin/sh interpreter.
# For more examples and pre-written hooks, see those in
# the Subversion repository at
# http://svn.collab.net/repos/svn/trunk/tools/hook-scripts/ and
# http://svn.collab.net/repos/svn/trunk/contrib/hook-scripts/

REPOS="$1"
TXN="$2"


# Check that the sources follow defined standards
/path/to/CodeSniffer/scripts/phpcs-svn-pre-commit --ignore='/test/integration/,/3rd-party/,<.....skipped lots of ignored folders.....>,(?<!\.php)$' -n --standard=StandardName "$REPOS" -t "$TXN" >&2 || exit 1
# All checks passed, so allow the commit.
exit 0
josh
DevNet Master
Posts: 4872
Joined: Wed Feb 11, 2004 3:23 pm
Location: Palm beach, Florida

Re: Phpundercontrol / Ant - a way to have a fast & slow bui

Post by josh »

What coding standard do you use or what other non default options do you use? I didn't look in detail but under the default config it complained about a lot of trivial stuff like white space.
User avatar
Weirdan
Moderator
Posts: 5978
Joined: Mon Nov 03, 2003 6:13 pm
Location: Odessa, Ukraine

Re: Phpundercontrol / Ant - a way to have a fast & slow bui

Post by Weirdan »

josh wrote:What coding standard do you use or what other non default options do you use?
We use our own coding standard file for sniffer that forces output similar to what Zend Framework coding standard required back then when we adopted it (unfortunately ZF abandoned their own standard file/sniffs long time ago, and later even removed it from their version control system, and ZF standard in CS distribution is seriously incomplete and outdated). It mainly draws sniffs from other shipped standard files (with some tweaks where it was necessary), plus some internal stuff.
We also patched CodeSniffer to not require working PEAR installation.
josh wrote:I didn't look in detail but under the default config it complained about a lot of trivial stuff like white space.
That's the main use case we have for code sniffer - complain about trivial stuff so this trivial stuff gets fixed. We don't use any complex metrics sniffs or something. Just what's necessary to keep the code uniform.
Post Reply