• Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Major Major
    • logstash-plugin
    • None

      When sending the log line by line via the JobProperty or the pipeline logstash step, the complete data is sent every time. This data is static and never changes, so it should be sufficient to send it once at the beginning or the end.

          [JENKINS-54685] data ecomony

          mwinter69 I'm not sure – I think most of it is static, but some aren't:

          • test results
          • build result
          • build (env) variables
          • build duration

          I think this would require some refactor to split the actually static data from mutable one

          Jakub Bochenski added a comment - mwinter69 I'm not sure – I think most of it is static, but some aren't: test results build result build (env) variables build duration I think this would require some refactor to split the actually static data from mutable one

          Markus Winter added a comment -

          even test results are static in the sense that once the results are determined they do not change anymore. Of course they are not there from the beginning.

          My idea here is that the wrapper will send really just the bare minimum to identify the build (I think jenkins url, full name and build number are required at least, optionally duration). We have an explicit start event, that sends additional data and an explicit end event that will send all data that is desired (with the data provider as mentioned in JENKINS-54645).

          Data providers could decide whether the data should be included in the start and/or end event. They are configurable (i.e. in the test results include also successful tests).

          A special case is the approach with the script. This might be another post processing option. Or we just drop this idea (I've never been a fan of it to be honest, for the wrapper that could be a performance killer).

          The notifier will always send all data that was configured.

          Markus Winter added a comment - even test results are static in the sense that once the results are determined they do not change anymore. Of course they are not there from the beginning. My idea here is that the wrapper will send really just the bare minimum to identify the build (I think jenkins url, full name and build number are required at least, optionally duration). We have an explicit start event, that sends additional data and an explicit end event that will send all data that is desired (with the data provider as mentioned in JENKINS-54645 ). Data providers could decide whether the data should be included in the start and/or end event. They are configurable (i.e. in the test results include also successful tests). A special case is the approach with the script. This might be another post processing option. Or we just drop this idea (I've never been a fan of it to be honest, for the wrapper that could be a performance killer). The notifier will always send all data that was configured.

          Sounds good, though I would prefer to enable keeping the legacy behavior. Both for pure backwards-compatibility and for builds with small amount of metadata/lines it can be convenient to send everything in a single payload.
          I think we can achieve this by having all three sets configurable:

          • every-message data
          • start event data
          • end event data

          Jakub Bochenski added a comment - Sounds good, though I would prefer to enable keeping the legacy behavior. Both for pure backwards-compatibility and for builds with small amount of metadata/lines it can be convenient to send everything in a single payload. I think we can achieve this by having all three sets configurable: every-message data start event data end event data

            jbochenski Jakub Bochenski
            mwinter69 Markus Winter
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: