Latest Swarm suggests use of the update parameter in the review/build to show running and some (hopefully) meaningful message(s).

      The "update" (instead of pass and fail) also as formatted in JSON in the body of the POST request. Test status: valid test status values are running, pass, and fail. Messages: you can pass a maximum 10 messages, if you provide more than 10 messages only the first 10 are saved. 

      See https://www.perforce.com/manuals/swarm/Content/Swarm/admin.integrate_test_suite.html?Highlight=update

       

       

          [JENKINS-62115] Review: support swarm's update url

          Pinned comments

          Pinned by Dhaval

          Karl Wirth added a comment -

          Have had a request for this so pinging it.

          Karl Wirth added a comment - Have had a request for this so pinging it.

          All comments

          Pinned by Dhaval

          Karl Wirth added a comment -

          Have had a request for this so pinging it.

          Karl Wirth added a comment - Have had a request for this so pinging it.

          Michael Rose added a comment -

          We are in the process of upgrading our Perforce and Swarm servers and came across this issue. For our needs, I think it would be sufficient for the update field to mean that the Jenkins job will handle all callbacks instead of the plugin doing it. That was my interpretation of what the Swarm documentation said. I went through and updated the Jenkins job to do additional http POST requests when the "update" parameter is set only to find that the field is never passed on to the job.

          Michael Rose added a comment - We are in the process of upgrading our Perforce and Swarm servers and came across this issue. For our needs, I think it would be sufficient for the update field to mean that the Jenkins job will handle all callbacks instead of the plugin doing it. That was my interpretation of what the Swarm documentation said. I went through and updated the Jenkins job to do additional http POST requests when the "update" parameter is set only to find that the field is never passed on to the job.

          Michael Rose added a comment -

          However, if you wanted to implement a function that we can send arbitrary message to that would hand the POST request, even better.

          Michael Rose added a comment - However, if you wanted to implement a function that we can send arbitrary message to that would hand the POST request, even better.

          Karl Wirth added a comment -

          Devs - Please see JENKINS-73473

          Karl Wirth added a comment - Devs - Please see JENKINS-73473

          Eivind added a comment -

          Any update on this joel_brown - By looking at the code, it should be rather trivial to add this field.

          Eivind added a comment - Any update on this joel_brown - By looking at the code, it should be rather trivial to add this field.

          Eivind added a comment -

          p4karl
          > The "update" (instead of pass and fail) also as formatted in JSON in the body of the POST request. Test status: valid test status values are running, pass, and fail. Messages: you can pass a maximum 10 messages, if you provide more than 10 messages only the first 10 are saved.

          Also, I did split the job out into multiple sub-jobs and then used the pipeline "build" step to spawn these jobs in parallel. Looks like the swarm server doesn't maintain state of the messages received, instead it requires the API to supply these which makes spreading the build-job out to multiple jobs hard. I had to contain the swarm message updates to the 'update' url in the main job. It would be nice if the "start" state would reset it, then any update of the messages would be added until the job is finished.

          Eivind added a comment - p4karl > The "update" (instead of pass and fail) also as formatted in JSON in the body of the POST request. Test status: valid test status values are running, pass, and fail. Messages: you can pass a maximum 10 messages, if you provide more than 10 messages only the first 10 are saved. Also, I did split the job out into multiple sub-jobs and then used the pipeline "build" step to spawn these jobs in parallel. Looks like the swarm server doesn't maintain state of the messages received, instead it requires the API to supply these which makes spreading the build-job out to multiple jobs hard. I had to contain the swarm message updates to the 'update' url in the main job. It would be nice if the "start" state would reset it, then any update of the messages would be added until the job is finished.

            joel_brown Joel Brown
            joel_brown Joel Brown
            Votes:
            3 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated: