Project specific actions

The purpose of this is to introduce project specific behaviours consisting of some common PHP code and project specific settings stored in the database.
In the Joomla! world this would be Plugins®

I am not sure about the implementation, so this is just a first scratch (but it should work) and I am wide open for suggestions ;)

Update GitHub status for human test results (JBS)

So this would be the first implementation.

It works similar to those automated services like Travis, Scrutinizer etc. but for human test results created by our JTracker Application with the help of our community members from the JBS and others - it wouldn't work without them :)

GitHub allows four different status states called pending, success, error and failure.

So we might use three of them and map our human test results to something like:

• pending - less than 2 successful and 0 failing tests.
• success - 2 or more successful and 0 failing tests.
• failure - 0 or more successful and 1 or more failing tests.

See: GitHub API - Create a status

@test

This would be the database entry to activate the update status action for a project.

You should probably use a test project for testing...

INSERT INTO `#__tracker_actions` (`id`, `project_id`, `type`, `name`, `params`) VALUES
(1, 4, 'GitHub', 'UpdateStatus', '
{
  "humanTestResults": {
    "active": "1",
    "pending": {
      "comp_success": "<",
      "cnt_success": "2",
      "comp_failure": "=",
      "cnt_failure": "0"
    },
    "success": {
      "comp_success": ">=",
      "cnt_success": "2",
      "comp_failure": "=",
      "cnt_failure": "0"
    },
    "error": {
      "comp_success": "",
      "cnt_success": "",
      "comp_failure": "",
      "cnt_failure": ""
    },
    "failure": {
      "comp_success": ">=",
      "cnt_success": "0",
      "comp_failure": ">=",
      "cnt_failure": "1"
    }
  }
}
');

Test results are NOT bound to a specific commit

Currently our human test results are not bound to a specific commit as the CI services like Travis or Scrutinizer are.
This means if a PR receives new commits, the test results would be automatically "invalidated" and testers would be required to submit their results again.

I believe this is good since it does not bother the testers when a PR receives only code style changes, on the other hand the code changes might require new tests.

So there are two solutions:

1. Whenever the PR gets new commits use the currently available test results for the latest commit and submit the results automatically to GitHub (currently implemented)
2. Make the test results bound to a specific commit as the other services. This would require testers to resubmit their test results whenever a PR gets new commits (to be implemented).