• Icon: New Feature New Feature
    • Resolution: Unresolved
    • Icon: Major Major
    • subversion-plugin
    • None
    • Platform: All, OS: All

      My idea of this feature would be that hudson provide a mode where, instead of
      just updating the workspace to the tip (latest repository revision) it would try
      to catch up by updating to the next revision and run the target until it reaches
      the tip.

      Right now I do this manually from an ant wrapper script but integrating it in
      hudson allows for fine grained identification of regressions. This is especially
      important when a project get at a stage where performance improvements are the
      focus.

      for example, on our project, we do continuous performance testing so that the
      impact of every commit is assessed by SLAMD jobs.

      the principle is pretty simple but I don't know how difficult it would be to
      implement.
      Here's how I do it manually.
      1. get workspace revision
      2. get repository revision
      3. if workspace revision < repository revision then trigger build

      put that in a loop and you're set.

          [JENKINS-673] SCM "catch up" feature

          I think you can do this by writing a plugin and extending SubversionSCM and
          registering it as a new SCM implementation.

          The modified SubversionSCM could check the revision used in the last build, then
          check the head revision in the server, and uses lastRev+1 to check out. If
          lastRev+1 < serverRev, you can schedule another build right there.

          You are doing this with Subversion, right? This doesn't make sense with CVS.

          Kohsuke Kawaguchi added a comment - I think you can do this by writing a plugin and extending SubversionSCM and registering it as a new SCM implementation. The modified SubversionSCM could check the revision used in the last build, then check the head revision in the server, and uses lastRev+1 to check out. If lastRev+1 < serverRev, you can schedule another build right there. You are doing this with Subversion, right? This doesn't make sense with CVS.

          al_xipe added a comment -

          yes, that's with subversion. I'll add that plugin on my todo list then.

          al_xipe added a comment - yes, that's with subversion. I'll add that plugin on my todo list then.

          What are the chances of this happening? We also wish to run tests after each build and wish to build each revision.

          steverdavidson added a comment - What are the chances of this happening? We also wish to run tests after each build and wish to build each revision.

          Ferenc Kovacs added a comment - - edited

          another way to achive this behaviour, if you create a parameterized build
          http://wiki.hudson-ci.org/display/HUDSON/Parameterized+Build
          then configure your post-commit hook to trigger your job with the revision number

          but it would be much easier if there would be a straightforward way included for this behaviour

          Tyrael

          Ferenc Kovacs added a comment - - edited another way to achive this behaviour, if you create a parameterized build http://wiki.hudson-ci.org/display/HUDSON/Parameterized+Build then configure your post-commit hook to trigger your job with the revision number but it would be much easier if there would be a straightforward way included for this behaviour Tyrael

          Can anybody explain if this would be part of core Jenkins or the code source, e.g. the Git plugin?

          Niklas Hambuechen added a comment - Can anybody explain if this would be part of core Jenkins or the code source, e.g. the Git plugin?

          Jo Shields added a comment -

          7 years, and no activity beyond half-baked workarounds.

          So.

          From where I'm sat, there are two issues to resolve:

          • A way to inject builds with given revisions, without requiring a parameterized build, OR making parameters optional so if Jenkins detects "I am missing these intermediate commits, I will add jobs to build them" it can do so without breaking workflow for non-parameterised default behaviour
          • Maintain some knowledge of "the last master I know about". If Jenkins knows it built revision r1, then polls to discover revision r10, it needs to be able to inject builds for r2..r10 without being confused if r12 appears in the next round of polling (i.e. the record needs to be 'newest commit I know about', not 'last commit I acted upon'). This value should be user-visible in the project settings, so newly created projects don't try to catch up on 10 years of commits.

          Importantly, building commits in precise order is irrelevant - you care whether given commits have been tested, not when they were tested. The order becomes especially irrelevant if you use the build name plugin to use commitid for build revision names, not an incrementing numeric value as is the default.

          A bunch of this plumbing is already done - we can poll the SCM. Some SCM plugins clearly have knowledge of whether revisions have already been done or not (e.g. hudson/plugins/git/util/DefaultBuildChooser.java#L134). The less-implemented part is the first one - injecting the intermediate jobs into the build queue, not just the latest

          Jo Shields added a comment - 7 years, and no activity beyond half-baked workarounds. So. From where I'm sat, there are two issues to resolve: A way to inject builds with given revisions, without requiring a parameterized build, OR making parameters optional so if Jenkins detects "I am missing these intermediate commits, I will add jobs to build them" it can do so without breaking workflow for non-parameterised default behaviour Maintain some knowledge of "the last master I know about". If Jenkins knows it built revision r1, then polls to discover revision r10, it needs to be able to inject builds for r2..r10 without being confused if r12 appears in the next round of polling (i.e. the record needs to be 'newest commit I know about', not 'last commit I acted upon'). This value should be user-visible in the project settings, so newly created projects don't try to catch up on 10 years of commits. Importantly, building commits in precise order is irrelevant - you care whether given commits have been tested, not when they were tested. The order becomes especially irrelevant if you use the build name plugin to use commitid for build revision names, not an incrementing numeric value as is the default. A bunch of this plumbing is already done - we can poll the SCM. Some SCM plugins clearly have knowledge of whether revisions have already been done or not (e.g. hudson/plugins/git/util/DefaultBuildChooser.java#L134). The less-implemented part is the first one - injecting the intermediate jobs into the build queue, not just the latest

          Jo Shields added a comment -

          I've made some progress.

          I now have a local fork of the Git Plugin with a "Wrench" BuildChooser - it returns an array of intermediate jobs up the chain when queried (DefaultBuildChooser blindly returns a 1-element array containing HEAD).

          There's code to handle candidate commit arrays, but the code is really stupid, and that's where I'm currently stuck - it (racily, so sometimes it messes up) builds HEAD and HEAD~1, but nothing earlier regardless of how many earlier commits there are. This is at https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/hudson/plugins/git/GitSCM.java#L927-936

          Jo Shields added a comment - I've made some progress. I now have a local fork of the Git Plugin with a "Wrench" BuildChooser - it returns an array of intermediate jobs up the chain when queried (DefaultBuildChooser blindly returns a 1-element array containing HEAD). There's code to handle candidate commit arrays, but the code is really stupid, and that's where I'm currently stuck - it (racily, so sometimes it messes up) builds HEAD and HEAD~1, but nothing earlier regardless of how many earlier commits there are. This is at https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/hudson/plugins/git/GitSCM.java#L927-936

            Unassigned Unassigned
            al_xipe al_xipe
            Votes:
            18 Vote for this issue
            Watchers:
            14 Start watching this issue

              Created:
              Updated: