Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-1682

Pre-tested commit feature

    XMLWordPrintable

    Details

    • Type: New Feature
    • Status: Resolved (View Workflow)
    • Priority: Major
    • Resolution: Won't Fix
    • Component/s: other
    • Labels:
      None
    • Environment:
      Platform: All, OS: All
    • Similar Issues:

      Description

      Hi Koshuke,

      As we talked at JavaOne, it would be nice if Hudson provided a pre-tested commit
      feature, similar to TeamCity's:

      http://www.jetbrains.com/teamcity/delayed_commit.html

      – Felipe

        Attachments

          Issue Links

            Activity

            Hide
            lars_kruse Lars Kruse added a comment -

            Hmmm!
            I agree that the implementation of the support for pre-tested commit will have to be laid on each individual plugin. The point that I was advocating in Paris was, that there ought to be a recommended approach that the SCM plugin developers should/could use when implementing it.

            Our rationale is that all pre-test commits - regardless of the underlying VCS - has a generic character:

            Pre-build step
            (The pre-build step is where the SCM extension currently has it's foot print)

            • Establish a workspace representing the tip of the branch
            • Merge 'something' into the workspace (the 'something' can be a patch, a pull, a merge from another branch ... - this is up to the SCM plugin developer to decide)

            The build step
            If the merge succeeded the job continues to the build step - the user simply implement the test that should qualify the commit - typically something relatively simple like build and run the unit test - but the actual test is of course up to the user of the plugin to decide.

            The post-build step
            The pre-tested commit feature will have to have a foot print in the post-build step to decide if the current state of the workspace is accepted as a new commit - or not)

            • If build is successful accept the merge as a new commit, if not then reject it an roll back the workspace (exactly what is going to happen her is up to the developer of the SCM plugin to decide)

            Suggested solution
            Currently the "generic" approach is implemented by having the SCM plugins that supports that pre-tested commit feature extend both SCM and the Notifier (to get a foot print in the post build step).

            We suggest that the the SCM extension simply is enhanced so that it has a wrap-up method that is called in the post-build step - those SCM plugins that want to make decisions regarding the workspace could implement and override the wrap-up method - those who doesn't could simply do nothing - and everything would stay the same.

            This approach would be backwards compatible and those SCM plugins that want to implement support for pre-tested commits wouldn't have to use the, not so obvious and kind of tedious, approach to have their SCM plugin extend the Notifier as well.

            Lars Kruse

            Show
            lars_kruse Lars Kruse added a comment - Hmmm! I agree that the implementation of the support for pre-tested commit will have to be laid on each individual plugin. The point that I was advocating in Paris was, that there ought to be a recommended approach that the SCM plugin developers should/could use when implementing it. Our rationale is that all pre-test commits - regardless of the underlying VCS - has a generic character: Pre-build step (The pre-build step is where the SCM extension currently has it's foot print) Establish a workspace representing the tip of the branch Merge 'something' into the workspace (the 'something' can be a patch, a pull, a merge from another branch ... - this is up to the SCM plugin developer to decide) The build step If the merge succeeded the job continues to the build step - the user simply implement the test that should qualify the commit - typically something relatively simple like build and run the unit test - but the actual test is of course up to the user of the plugin to decide. The post-build step The pre-tested commit feature will have to have a foot print in the post-build step to decide if the current state of the workspace is accepted as a new commit - or not) If build is successful accept the merge as a new commit, if not then reject it an roll back the workspace (exactly what is going to happen her is up to the developer of the SCM plugin to decide) Suggested solution Currently the "generic" approach is implemented by having the SCM plugins that supports that pre-tested commit feature extend both SCM and the Notifier (to get a foot print in the post build step). We suggest that the the SCM extension simply is enhanced so that it has a wrap-up method that is called in the post-build step - those SCM plugins that want to make decisions regarding the workspace could implement and override the wrap-up method - those who doesn't could simply do nothing - and everything would stay the same. This approach would be backwards compatible and those SCM plugins that want to implement support for pre-tested commits wouldn't have to use the, not so obvious and kind of tedious, approach to have their SCM plugin extend the Notifier as well. Lars Kruse
            Hide
            rlindsgaard Ronni Elken Lindsgaard added a comment -

            I believe to have created a module that implements this feature and believe this issue can now be closed. The plugin https://wiki.jenkins-ci.org/display/JENKINS/Pretested+Integration+Plugin comes with built-in support for Mercurial but is easily extendable to other SCMs - please read the wiki page.

            I will present the details of the solution and plugin at the Jenkins CI User Event CPH 2013 friday, september 7th.

            Ronni E Lindsgaard

            Show
            rlindsgaard Ronni Elken Lindsgaard added a comment - I believe to have created a module that implements this feature and believe this issue can now be closed. The plugin https://wiki.jenkins-ci.org/display/JENKINS/Pretested+Integration+Plugin comes with built-in support for Mercurial but is easily extendable to other SCMs - please read the wiki page. I will present the details of the solution and plugin at the Jenkins CI User Event CPH 2013 friday, september 7th. Ronni E Lindsgaard
            Hide
            integer Kanstantsin Shautsou added a comment -

            What is the status?

            Show
            integer Kanstantsin Shautsou added a comment - What is the status?
            Hide
            danielbeck Daniel Beck added a comment -

            For Git there's both the Pretested Integration plugin (talk video) and Validated Merge in Jenkins Enterprise (docs), so this can probably be considered resolved.

            Show
            danielbeck Daniel Beck added a comment - For Git there's both the Pretested Integration plugin ( talk video ) and Validated Merge in Jenkins Enterprise ( docs ), so this can probably be considered resolved.
            Hide
            jglick Jesse Glick added a comment -

            Closing on the grounds that there are some such implementations floating around in plugins and that no one is proposing an “official” implementation bundled in Jenkins.

            (In the future I would like to see something that used scm-api-plugin and branch-api-plugin to manage the list of named or implicit branches being tested so there is a clear linear history for each; mixing all such builds in one project is a UI disaster. But this will have to wait until more widely used project types integrate properly with the Branch API.)

            Show
            jglick Jesse Glick added a comment - Closing on the grounds that there are some such implementations floating around in plugins and that no one is proposing an “official” implementation bundled in Jenkins. (In the future I would like to see something that used scm-api-plugin and branch-api-plugin to manage the list of named or implicit branches being tested so there is a clear linear history for each; mixing all such builds in one project is a UI disaster. But this will have to wait until more widely used project types integrate properly with the Branch API.)

              People

              • Assignee:
                Unassigned
                Reporter:
                felipeal felipeal
              • Votes:
                61 Vote for this issue
                Watchers:
                43 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: