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

"Build Review" page should be updated to include "update"

    • Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Minor Minor
    • p4-plugin
    • None
    • Jenkins 2.452.3
      P4-Plugin 1.15.1

      1. I create myself a new multi-branch project, enter in client view mappings, etc.
      2. I enter the branch specific build, then click the "Build Review" tab on the left-hand side
      3. The page "Manual Configuration for Build" appears
      4. I have the following fields: review, change, status, pass, fail and p4.label

      With the new swarm servers and configuration, the preferred way to trigger a swarm review build is via the "update" and give it a callback URL to the swarm server. That part seems to be missing (I can't manually enter it on this page, and thus will need to do this via curl if needed be).

      Also, a nit on the documentation here. The "caveat" is that we can't really use any build-parameters without default values. That's fine, but if you plan to write the code for a light-weight checkout using the scm pipeline step, I these would need to be exposed as build-parameters (b/c without them being parameterized how are you going to ensure you have e.g. change set when you build it outside of the Build Review page??). I guess the assumption is that those parameters feed into the jenkin's p4-plugin and as long as you do the default checkout, you don't need to set them ...

      Please add "update" to the manual build review page

          [JENKINS-73473] "Build Review" page should be updated to include "update"

          Eivind added a comment -

          p4karl - Do you have any suggestions here as far as the build parameters goes??

          Eivind added a comment - p4karl - Do you have any suggestions here as far as the build parameters goes??

          Karl Wirth added a comment -

          Hi enaess - This is a known problem:

          https://issues.jenkins.io/browse/JENKINS-62115

          I'll ping the current assignee to see the current status.

          As for workarounds I agree that a parameterized build is all I can think of. For changeset you could have 'now' which would build at latest but for the review you would need a dummy value that did not unshelve in instances where this was not triggered by a URL call with paramaters from Swarm.

          Karl Wirth added a comment - Hi enaess - This is a known problem: https://issues.jenkins.io/browse/JENKINS-62115 I'll ping the current assignee to see the current status. As for workarounds I agree that a parameterized build is all I can think of. For changeset you could have 'now' which would build at latest but for the review you would need a dummy value that did not unshelve in instances where this was not triggered by a URL call with paramaters from Swarm.

          Karl Wirth added a comment -

          Hi enaess 

          As parameters '{status}', '{change}', '{review}', '{update}','{pass}' and '{fail}' :

          https://www.perforce.com/manuals/swarm/Content/Swarm/test-add.html#Pass_special_arguments_to_your_test_suite

          Depending on how the test is called you may need the branch as part of the URL. For example: 

           

          http://USER:TOKEN@MY-JENKINS:8080/job/swarmmultibranch/job/{branch}/review/build  

          and the JSON payload is:

          status={status}&review={review}&change={change}&pass={pass}&fail={fail}&update={update}   

             

           

           

          Karl Wirth added a comment - Hi enaess   As parameters '{status}', '{change}', '{review}', '{update}','{pass}' and '{fail}' : https://www.perforce.com/manuals/swarm/Content/Swarm/test-add.html#Pass_special_arguments_to_your_test_suite Depending on how the test is called you may need the branch as part of the URL. For example:    http: //USER:TOKEN@MY-JENKINS:8080/job/swarmmultibranch/job/{branch}/review/build  and the JSON payload is: status={status}&review={review}&change={change}&pass={pass}&fail={fail}&update={update}         

          Eivind added a comment -

          p4karl Thanks for your reply here.

          I think those parameters are well documented. What isn't obvious is for example how one chains builds together. Say, I have a top-level job that runs additional jobs in parallel. The tricky part here is processing the parameters injected via the `review/build?param1=value1&...` trigger...

          Say I have a top-level build script that can be triggered via the `buildWithParameters?param1=value1&...` or it can be triggered via `review/build?param1=value1&...`

          The variables may or may not be present in the environment dependent on how the build was triggered.

           

          But how do I trigger downstream jobs like using the build-step plugin (or is this even possible?)

                           // Trigger a downstream job in parallel ...
                           stage("Build My Build") {
                              steps {
                                  // Trying to kick of a review build, but the build-step plugin doesn't seem to know about the secondary url implemented by p4 plugin
                                  build (job: "${env.BUILD_FOLDER}/${env.BUILD_NAME} - Job A/${env.BRANCH_NAME}",
                                         wait: true,      
                                         parameters: ...)
                              } 
                       }
          

          I suppose the downstream build won't be using the review/build url, but needs to implement params.change, params.review, params.status and params.url or params.pass/fail.

          Eivind added a comment - p4karl Thanks for your reply here. I think those parameters are well documented. What isn't obvious is for example how one chains builds together. Say, I have a top-level job that runs additional jobs in parallel. The tricky part here is processing the parameters injected via the `review/build?param1=value1&...` trigger... Say I have a top-level build script that can be triggered via the `buildWithParameters?param1=value1&...` or it can be triggered via `review/build?param1=value1&...` The variables may or may not be present in the environment dependent on how the build was triggered.   But how do I trigger downstream jobs like using the build-step plugin (or is this even possible?) // Trigger a downstream job in parallel ... stage( "Build My Build" ) { steps { // Trying to kick of a review build, but the build-step plugin doesn't seem to know about the secondary url implemented by p4 plugin build (job: "${env.BUILD_FOLDER}/${env.BUILD_NAME} - Job A/${env.BRANCH_NAME}" , wait: true , parameters: ...) } } I suppose the downstream build won't be using the review/build url, but needs to implement params.change, params.review, params.status and params.url or params.pass/fail.

            Unassigned Unassigned
            enaess Eivind
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: