Eventually, integration between Drupal.org and the Jenkins master server will be automated, happening entirely through pseudo commit hooks and issue queue integration.

For the commit hooks, every commit made to drupalorg on a testing-enabled project would trigger a build for that project. These triggers can be coded via Drupal.org's "versioncontrol_git" API. For an example of the use of this API (from the existing testing system), see the pift_versioncontrol_git_refs_updated() and pift_versioncontrol_code_arrival() functions in pift.module (Project Issue File Test project).

For the issue queue integration, each file uploaded to an issue will trigger a patch build. See the pift_nodeapi() and pift_comment() functions for an example of the existing integration work.

What we now need is:
1. A way to enable or disable testing for a given project (or set of projects). Long term, this will occur through interaction with project or PIFT module (probably replacing the automated testing tab on project pages); but for now, having a namespaced Drupal variable (i.e. created via variable_set()) containing an array of project ids (project page node id) should suffice. This 'enabled' list will be different from the existing list on drupal.org.
2. Check every time the git/code events fire, and if the repository in question belongs to an enabled project, trigger a curl request configured for that project.
3. Administrative restrictions to ensure that only specific users can modify the list of projects that are enabled for testing.
4. A watchdog() log notification of the request being sent out to the jenkins server (with it's own watchdog namespace, to facilitate filtering.)

Long term, we will need to start tracking requests ... the 'extra extra bonus points' piece here may be configuring things to use a Drupal Queue to manage the requests.

Comments

jthorson’s picture

Title: Add commit hook and nodeapi integration for triggering jobx » Add commit hook and nodeapi integration for triggering job
drumm’s picture

Project: DrupalCI: Drupal.org Integration (Modernizing Testbot Initiative) » Project issue file test
Version: » 7.x-3.x-dev
drumm’s picture

A way to enable or disable testing for a given project (or set of projects). Long term, this will occur through interaction with project or PIFT module (probably replacing the automated testing tab on project pages); but for now, having a namespaced Drupal variable (i.e. created via variable_set()) containing an array of project ids (project page node id) should suffice. This 'enabled' list will be different from the existing list on drupal.org.

Administrative restrictions to ensure that only specific users can modify the list of projects that are enabled for testing.

I went ahead and built out the UI for this, see #2463185: DrupalCI Project UI.

drumm’s picture

Status: Active » Needs review

Check every time the git/code events fire, and if the repository in question belongs to an enabled project, trigger a curl request configured for that project.

This is currently implemented at http://cgit.drupalcode.org/project_issue_file_test/tree/pift.versioncont...

drumm’s picture

Assigned: Unassigned » drumm

  • drumm committed 43839c0 on 7.x-3.x
    Issue #2283017: Refactor commit testing
    
drumm’s picture

Status: Needs review » Fixed

This is now working.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.