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

Support "Pull Request Iteration Statuses"

    Details

    • Type: Improvement
    • Status: In Review (View Workflow)
    • Priority: Minor
    • Resolution: Unresolved
    • Component/s: tfs-plugin
    • Labels:
      None
    • Similar Issues:

      Description

      VSTS supports "Pull Request Iteration Statuses", i. e. the status of a pull-request iteration.

      In my understanding, the benefit of using this is, that a status policy can be proactively enforced by VSTS.

      Scenario:
      1. push a new commit on a VSTS pull-request
      2. Web-hook does not trigger Jenkins for some reason
      3. pull-request stays valid even though not being built/tested

      Link to VSTS API Documentation: https://docs.microsoft.com/en-us/rest/api/vsts/git/pull%20request%20iteration%20statuses?view=vsts-rest-4.1

        Attachments

          Activity

          Hide
          fbaeuerle Florian Bäuerle added a comment - - edited

          In practice solving this issue will be somwhat problematic, since the "Pull request merge attempted" Service Hook does not contain the Iteration Id in its payload...

          Show
          fbaeuerle Florian Bäuerle added a comment - - edited In practice solving this issue will be somwhat problematic, since the "Pull request merge attempted" Service Hook does not contain the Iteration Id in its payload...
          Hide
          carpnick2 Nick Carpenter added a comment -

          This is required if any new commits get pushed to the repository.  I am not sure how this is not a pretty major feature.  Most people do not want their build to run once, pass, then allow any number of commits.

          Is it possible to instead call this to get the list of iterations, match it up to the current commit guid, and then do an update on the pull request.

          We are explicitly evaluating VSTS as a SCM repository, and this basic feature is missing from an integration perspective.

          Show
          carpnick2 Nick Carpenter added a comment - This is required if any new commits get pushed to the repository.  I am not sure how this is not a pretty major feature.  Most people do not want their build to run once, pass, then allow any number of commits. Is it possible to instead call this to get the list of iterations, match it up to the current commit guid, and then do an update on the pull request. We are explicitly evaluating VSTS as a SCM repository, and this basic feature is missing from an integration perspective.
          Hide
          fbaeuerle Florian Bäuerle added a comment - - edited

          Nick Carpenter, there's a few more issues, at least if you're planning to integrate Jenkins via VSTS Service Hooks.

          For pull-requests you will normally use the "merge request attempted" hook, which is okay. Except that this hook is not being triggered, if the target branch moves on. [Actually it does, but just when you're clicking the 'Complete' button, and if there's not conflict, your Jenkins server will build something that is already merged: yay].

          I think this scenario would not be caught by iteration status support, because IIRC the iteration status is not increment when the target branch moves on.

          But of course you still have the option of using VSTS Builds to trigger you Jenkins jobs. That works fine, except that it adds a significant amount of delay and extra configuration to your CI chain.

          One more thing: You cannot easily/properly do CI with Multibranch Pipelines as well.

          Show
          fbaeuerle Florian Bäuerle added a comment - - edited Nick Carpenter , there's a few more issues, at least if you're planning to integrate Jenkins via VSTS Service Hooks. For pull-requests you will normally use the "merge request attempted" hook, which is okay. Except that this hook is not being triggered, if the target branch moves on. [Actually it does, but just when you're clicking the 'Complete' button, and if there's not conflict, your Jenkins server will build something that is already merged: yay] . I think this scenario would not be caught by iteration status support, because IIRC the iteration status is not increment when the target branch moves on. But of course you still have the option of using VSTS Builds to trigger you Jenkins jobs. That works fine, except that it adds a significant amount of delay and extra configuration to your CI chain. One more thing: You cannot easily/properly do CI with Multibranch Pipelines as well.
          Hide
          fbaeuerle Florian Bäuerle added a comment -

          Nick Carpenter looked at this a bit more. The only way to get a link between a pull request merge hook and the correct iteration is to compare the target and the source commit hashes.

          Show
          fbaeuerle Florian Bäuerle added a comment - Nick Carpenter looked at this a bit more. The only way to get a link between a pull request merge hook and the correct iteration is to compare the target and the source commit hashes.
          Hide
          fbaeuerle Florian Bäuerle added a comment -

          opened a Pull-Request:
          https://github.com/jenkinsci/tfs-plugin/pull/218

          please test and review.

          Show
          fbaeuerle Florian Bäuerle added a comment - opened a Pull-Request: https://github.com/jenkinsci/tfs-plugin/pull/218 please test and review.

            People

            • Assignee:
              redsolo redsolo
              Reporter:
              fbaeuerle Florian Bäuerle
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated: