• 5.0.0-beta2

      The URLs of the warnings result pages change when the parser configuration changes. That breaks links and bookmarks to these pages.

      Currently the URLs use the pattern $BUILD_URL/warnings<index>Result/ and the index changes when a parser is added or deleted. See https://github.com/jenkinsci/warnings-plugin/blob/warnings-4.50/src/main/java/hudson/plugins/warnings/parser/ParserRegistry.java#L147.

      The URLs should not change when the parser configiuration changes or there should be a way to retrieve a permalink for the result page.

          [JENKINS-30403] Permalink URLs for Warnings Result Pages

          Daniel Spilker created issue -

          Ulli Hafner added a comment - - edited

          Any suggestion on how to administrate that URL? We currently have three types of parsers:

          1. Parsers integrated by extension point from the warnings plug-in itself
          2. Parsers integrated by extension point from customer plug-ins
          3. Parsers defined in the UI

          I think the first type can be handled by a new attribute in a parser. However, this then needs to be provided by customers plug-ins (and on the UI as text field).

          Ulli Hafner added a comment - - edited Any suggestion on how to administrate that URL? We currently have three types of parsers: Parsers integrated by extension point from the warnings plug-in itself Parsers integrated by extension point from customer plug-ins Parsers defined in the UI I think the first type can be handled by a new attribute in a parser. However, this then needs to be provided by customers plug-ins (and on the UI as text field).

          Yes, an extra attribute sounds like a good idea. The built-in parsers would need to provide a hard-coded value and there needs to be a text field for the parsers defined by the UI. For backwards-compatibility, the index could be used as fallback if the attribute is not set.

          Daniel Spilker added a comment - Yes, an extra attribute sounds like a good idea. The built-in parsers would need to provide a hard-coded value and there needs to be a text field for the parsers defined by the UI. For backwards-compatibility, the index could be used as fallback if the attribute is not set.
          R. Tyler Croy made changes -
          Workflow Original: JNJira [ 165509 ] New: JNJira + In-Review [ 182005 ]
          Ulli Hafner made changes -
          Labels New: analysis-core-2.0
          Ulli Hafner made changes -
          Status Original: Open [ 1 ] New: In Progress [ 3 ]
          Ulli Hafner made changes -
          Epic Link New: JENKINS-49911 [ 188901 ]
          Ulli Hafner made changes -
          Resolution New: Fixed [ 1 ]
          Status Original: In Progress [ 3 ] New: Resolved [ 5 ]
          Ulli Hafner made changes -
          Status Original: Resolved [ 5 ] New: Fixed but Unreleased [ 10203 ]

          Ulli Hafner added a comment -

          Released in 5.0.0-beta2.

          Ulli Hafner added a comment - Released in 5.0.0-beta2.
          Ulli Hafner made changes -
          Released As New: 5.0.0-beta2
          Status Original: Fixed but Unreleased [ 10203 ] New: Resolved [ 5 ]

            drulli Ulli Hafner
            daspilker Daniel Spilker
            Votes:
            2 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: