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

Truncated build logs do not show parallel branch names that began before the truncation point

    • workflow-job 2.37

      JENKINS-54304 added a CSS prefix for parallel branch names to Pipeline logs, but that fix relies on the start node for the branch being present in the HTML displayed on the console output page, which is not always the case for truncated logs. This results in parallel branch names not being displayed for branches that began before the truncation point.

      I am not sure about the best way to fix this. We could create some synthetic hidden nodes that hold the necessary information when the log is truncated and write them directly into the log when we are producing an HTML log, or add them directly in a copy of console.jelly, and then tweak the Javascript in workflow-job that adds the CSS rules to display the branch names, but that seems very awkward, and I think would need to be done in each individual implementation of LogStorage (or maybe we could make some API change to LogStorage.overallLog or AnnotatedLargeText to make it possible to add that logic in just once place). A prototype of this kind of approach can be seen here.

      Maybe it would be better to revert to inserting the branch names directly into the logs when generating HTML logs in the LogStorage implementations, similarly to how things worked before JENKINS-38381. That would also take care of JENKINS-56910, and would get rid of the lag between when the log shows up and the branch names are displayed because they are generated via Javascript. That would make the logs larger because of all of the redundant data, but given the comments on JENKINS-60862, it seems like a lot of people considered the old behavior a feature, so I think the tradeoff is worth considering.

          [JENKINS-60862] Truncated build logs do not show parallel branch names that began before the truncation point

          Devin Nusbaum created issue -
          Devin Nusbaum made changes -
          Link New: This issue relates to JENKINS-54304 [ JENKINS-54304 ]
          Devin Nusbaum made changes -
          Status Original: Open [ 1 ] New: In Progress [ 3 ]
          Devin Nusbaum made changes -
          Description Original: JENKINS-54304 added a CSS prefix for parallel branch names to Pipeline logs, but that fix relies on the start node for the branch being present in the HTML displayed on the console output page, which is not always the case for truncated logs. This results in parallel branch names not being displayed for branches that began before the truncation point.

          I am not sure about the best way to fix this. We could create some synthetic hidden nodes that hold the necessary information when the log is truncated and write them directly into the log when we are producing an HTML log, and then tweak the Javascript in workflow-job that adds the CSS rules to display the branch names, but that seems very awkward, and I think would need to be done in each individual implementation of {{LogStorage}} (or maybe we could make some API change to {{LogStorage.overallLog}} or {{AnnotatedLargeText}} to make it possible to add that logic in just once place). I prototyped this approach, and will submit draft PRs for it shortly.

          Maybe it would be better to just insert the branch names directly into the logs when generating HTML logs in the {{LogStorage}} implementations. That would also take care of JENKINS-56910, and would get rid of the lag between when the log shows up and the branch names are displayed because they are generated via Javascript.

          New: JENKINS-54304 added a CSS prefix for parallel branch names to Pipeline logs, but that fix relies on the start node for the branch being present in the HTML displayed on the console output page, which is not always the case for truncated logs. This results in parallel branch names not being displayed for branches that began before the truncation point.

          I am not sure about the best way to fix this. We could create some synthetic hidden nodes that hold the necessary information when the log is truncated and write them directly into the log when we are producing an HTML log, and then tweak the Javascript in workflow-job that adds the CSS rules to display the branch names, but that seems very awkward, and I think would need to be done in each individual implementation of {{LogStorage}} (or maybe we could make some API change to {{LogStorage.overallLog}} or {{AnnotatedLargeText}} to make it possible to add that logic in just once place). I prototyped this approach, and will submit draft PRs for it shortly.

          Maybe it would be better to just insert the branch names directly into the logs when generating HTML logs in the {{LogStorage}} implementations. That would also take care of JENKINS-56910, and would get rid of the lag between when the log shows up and the branch names are displayed because they are generated via Javascript.

          One other option would be to revert to the old approach of inserting a console note for each branch transition with all of the necessary data for display, but that adds a lot of overhead to to the size of the log.

          Devin Nusbaum made changes -
          Description Original: JENKINS-54304 added a CSS prefix for parallel branch names to Pipeline logs, but that fix relies on the start node for the branch being present in the HTML displayed on the console output page, which is not always the case for truncated logs. This results in parallel branch names not being displayed for branches that began before the truncation point.

          I am not sure about the best way to fix this. We could create some synthetic hidden nodes that hold the necessary information when the log is truncated and write them directly into the log when we are producing an HTML log, and then tweak the Javascript in workflow-job that adds the CSS rules to display the branch names, but that seems very awkward, and I think would need to be done in each individual implementation of {{LogStorage}} (or maybe we could make some API change to {{LogStorage.overallLog}} or {{AnnotatedLargeText}} to make it possible to add that logic in just once place). I prototyped this approach, and will submit draft PRs for it shortly.

          Maybe it would be better to just insert the branch names directly into the logs when generating HTML logs in the {{LogStorage}} implementations. That would also take care of JENKINS-56910, and would get rid of the lag between when the log shows up and the branch names are displayed because they are generated via Javascript.

          One other option would be to revert to the old approach of inserting a console note for each branch transition with all of the necessary data for display, but that adds a lot of overhead to to the size of the log.

          New: JENKINS-54304 added a CSS prefix for parallel branch names to Pipeline logs, but that fix relies on the start node for the branch being present in the HTML displayed on the console output page, which is not always the case for truncated logs. This results in parallel branch names not being displayed for branches that began before the truncation point.

          I am not sure about the best way to fix this. We could create some synthetic hidden nodes that hold the necessary information when the log is truncated and write them directly into the log when we are producing an HTML log, or add them directly in a copy of console.jelly, and then tweak the Javascript in workflow-job that adds the CSS rules to display the branch names, but that seems very awkward, and I think would need to be done in each individual implementation of {{LogStorage}} (or maybe we could make some API change to {{LogStorage.overallLog}} or {{AnnotatedLargeText}} to make it possible to add that logic in just once place). I prototyped this approach, and will submit draft PRs for it shortly.

          Maybe it would be better to just insert the branch names directly into the logs when generating HTML logs in the {{LogStorage}} implementations. That would also take care of JENKINS-56910, and would get rid of the lag between when the log shows up and the branch names are displayed because they are generated via Javascript.

          One other option would be to revert to the old approach of inserting a console note for each branch transition with all of the necessary data for display, but that adds a lot of overhead to to the size of the log.

          Devin Nusbaum made changes -
          Description Original: JENKINS-54304 added a CSS prefix for parallel branch names to Pipeline logs, but that fix relies on the start node for the branch being present in the HTML displayed on the console output page, which is not always the case for truncated logs. This results in parallel branch names not being displayed for branches that began before the truncation point.

          I am not sure about the best way to fix this. We could create some synthetic hidden nodes that hold the necessary information when the log is truncated and write them directly into the log when we are producing an HTML log, or add them directly in a copy of console.jelly, and then tweak the Javascript in workflow-job that adds the CSS rules to display the branch names, but that seems very awkward, and I think would need to be done in each individual implementation of {{LogStorage}} (or maybe we could make some API change to {{LogStorage.overallLog}} or {{AnnotatedLargeText}} to make it possible to add that logic in just once place). I prototyped this approach, and will submit draft PRs for it shortly.

          Maybe it would be better to just insert the branch names directly into the logs when generating HTML logs in the {{LogStorage}} implementations. That would also take care of JENKINS-56910, and would get rid of the lag between when the log shows up and the branch names are displayed because they are generated via Javascript.

          One other option would be to revert to the old approach of inserting a console note for each branch transition with all of the necessary data for display, but that adds a lot of overhead to to the size of the log.

          New: JENKINS-54304 added a CSS prefix for parallel branch names to Pipeline logs, but that fix relies on the start node for the branch being present in the HTML displayed on the console output page, which is not always the case for truncated logs. This results in parallel branch names not being displayed for branches that began before the truncation point.

          I am not sure about the best way to fix this. We could create some synthetic hidden nodes that hold the necessary information when the log is truncated and write them directly into the log when we are producing an HTML log, or add them directly in a copy of console.jelly, and then tweak the Javascript in workflow-job that adds the CSS rules to display the branch names, but that seems very awkward, and I think would need to be done in each individual implementation of {{LogStorage}} (or maybe we could make some API change to {{LogStorage.overallLog}} or {{AnnotatedLargeText}} to make it possible to add that logic in just once place). I prototyped this approach, and will submit draft PRs for it shortly.

          Maybe it would be better to revert to inserting the branch names directly into the logs when generating HTML logs in the {{LogStorage}} implementations, similarly to how things worked before JENKINS-38381. That would also take care of JENKINS-56910, and would get rid of the lag between when the log shows up and the branch names are displayed because they are generated via Javascript. That would make the logs larger because of all of the redundant data, but given the comments on JENKINS-60862, it seems like a lot of people considered the old behavior a feature, so I think the tradeoff is worth considering.

          Devin Nusbaum made changes -
          Remote Link New: This issue links to "jenkinsci/workflow-job-plugin#150 (Web Link)" [ 24344 ]
          Devin Nusbaum made changes -
          Description Original: JENKINS-54304 added a CSS prefix for parallel branch names to Pipeline logs, but that fix relies on the start node for the branch being present in the HTML displayed on the console output page, which is not always the case for truncated logs. This results in parallel branch names not being displayed for branches that began before the truncation point.

          I am not sure about the best way to fix this. We could create some synthetic hidden nodes that hold the necessary information when the log is truncated and write them directly into the log when we are producing an HTML log, or add them directly in a copy of console.jelly, and then tweak the Javascript in workflow-job that adds the CSS rules to display the branch names, but that seems very awkward, and I think would need to be done in each individual implementation of {{LogStorage}} (or maybe we could make some API change to {{LogStorage.overallLog}} or {{AnnotatedLargeText}} to make it possible to add that logic in just once place). I prototyped this approach, and will submit draft PRs for it shortly.

          Maybe it would be better to revert to inserting the branch names directly into the logs when generating HTML logs in the {{LogStorage}} implementations, similarly to how things worked before JENKINS-38381. That would also take care of JENKINS-56910, and would get rid of the lag between when the log shows up and the branch names are displayed because they are generated via Javascript. That would make the logs larger because of all of the redundant data, but given the comments on JENKINS-60862, it seems like a lot of people considered the old behavior a feature, so I think the tradeoff is worth considering.

          New: JENKINS-54304 added a CSS prefix for parallel branch names to Pipeline logs, but that fix relies on the start node for the branch being present in the HTML displayed on the console output page, which is not always the case for truncated logs. This results in parallel branch names not being displayed for branches that began before the truncation point.

          I am not sure about the best way to fix this. We could create some synthetic hidden nodes that hold the necessary information when the log is truncated and write them directly into the log when we are producing an HTML log, or add them directly in a copy of console.jelly, and then tweak the Javascript in workflow-job that adds the CSS rules to display the branch names, but that seems very awkward, and I think would need to be done in each individual implementation of {{LogStorage}} (or maybe we could make some API change to {{LogStorage.overallLog}} or {{AnnotatedLargeText}} to make it possible to add that logic in just once place). A prototype of this kind of approach can be seen [here|https://github.com/jenkinsci/workflow-job-plugin/pull/150].

          Maybe it would be better to revert to inserting the branch names directly into the logs when generating HTML logs in the {{LogStorage}} implementations, similarly to how things worked before JENKINS-38381. That would also take care of JENKINS-56910, and would get rid of the lag between when the log shows up and the branch names are displayed because they are generated via Javascript. That would make the logs larger because of all of the redundant data, but given the comments on JENKINS-60862, it seems like a lot of people considered the old behavior a feature, so I think the tradeoff is worth considering.

          Devin Nusbaum added a comment -

          A fix for this issue was released in Pipeline: Job Plugin version 2.37. See the changelog for details.

          Devin Nusbaum added a comment - A fix for this issue was released in Pipeline: Job Plugin version 2.37. See the changelog for details.
          Devin Nusbaum made changes -
          Released As New: workflow-job 2.37
          Resolution New: Fixed [ 1 ]
          Status Original: In Progress [ 3 ] New: Resolved [ 5 ]

            dnusbaum Devin Nusbaum
            dnusbaum Devin Nusbaum
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: