| -- a little flame in a functional style | |
| function particle(step, style, t) | |
| local newStyle = step(style, t) | |
| return { | |
| style = newStyle, | |
| next = function() | |
| return particle(step, newStyle, t + 1) | |
| end | |
| } |
| class ContainerAdapter implements Procedure<String> { | |
| private Collection<String> containments = new ArrayList<String>(); | |
| protected Container container; | |
| public ContainerAdapter(Container adaptee) { | |
| this.container = adaptee; | |
| } | |
Locate the section for your github remote in the .git/config file. It looks like this:
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = [email protected]:joyent/node.git
Now add the line fetch = +refs/pull/*/head:refs/remotes/origin/pr/* to this section. Obviously, change the github url to match your project's URL. It ends up looking like this:
| SELECT | |
| NH_TCASE.name AS | |
| tcase_name, | |
| NH_TCASE.id AS | |
| tcase_id, | |
| NH_TCASE.id AS | |
| tc_id, | |
| TPTCV.tcversion_id, | |
| TCV.version, | |
| TCV.tc_external_id AS |
| Index: pom.xml | |
| =================================================================== | |
| --- pom.xml (revision 1483879) | |
| +++ pom.xml (working copy) | |
| @@ -225,6 +225,34 @@ | |
| </archive> | |
| </configuration> | |
| </plugin> | |
| + <plugin> | |
| + <groupId>org.apache.maven.plugins</groupId> |
| update-rc.d logstash-shipper defaults | |
| update-rc.d logstash-reader defaults |
| #################################### | |
| # BASIC REQUIREMENTS | |
| # http://graphite.wikidot.com/installation | |
| # http://geek.michaelgrace.org/2011/09/how-to-install-graphite-on-ubuntu/ | |
| # Last tested & updated 10/13/2011 | |
| #################################### | |
| cd | |
| sudo apt-get update | |
| sudo apt-get upgrade |
| getTestProjectByName | |
| checkTestCaseIdentity (External id) | |
| new methods: | |
| ========== | |
| getProjectPlatforms | |
| removePlatformFromTestPlan | |
| addPlatformToTestPlan |
When you do your first Sonar run on your project, you get a lot of new quality numbers to play with, but no trends. You only have one data set for comparison, the now picture.
Wouldn't it be nice if you could see the current trend of the project without waiting a couple of month for the 'daily/weekly' Sonar runs to fill up the data? Well, you're in luck! And if you're using git as a version system as well, this is your day. :)
In the Sonar Advanced Parameter documentation you will find a System Property called sonar.projectDate. The property let you tell Sonar when in time the running analysis was ran.
By combining this property and what your version system does best, track changes to source, we can now play back the history of the project as far as Sonar is concerned.
This little Bash script illustrates the concept. To spell out what it does in human readable form:
| 1..63 | |
| ok 1 Create Search results copies simple attributes | |
| ok 2 Create Search results creates empty product list for no results | |
| ok 3 Create Search results creates 1 product list for one results | |
| ok 4 Create Search results creates multiple product list for more than one result | |
| ok 5 serviceUrlFor should prepend current site | |
| ok 6 fullUrlFor should prepend current site | |
| ok 7 config should return config for supplied site | |
| ok 8 Middleware should add current site to res locals | |
| ok 9 Middleware should set locale for i18n correctly |