-
Improvement
-
Resolution: Unresolved
-
Minor
-
None
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
[JENKINS-51973] Support "Pull Request Iteration Statuses"
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.
carpnick2, 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.
Florian Bäuerle
added a comment - - edited carpnick2 , 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. Florian Bäuerle
added a comment - carpnick2 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.
Florian Bäuerle
added a comment - carpnick2 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. Florian Bäuerle
added a comment - opened a Pull-Request:
https://github.com/jenkinsci/tfs-plugin/pull/218
please test and review.
Florian Bäuerle
added a comment - opened a Pull-Request:
https://github.com/jenkinsci/tfs-plugin/pull/218
please test and review. 
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...