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

Add support for preserving comments and formatting for Jenkinsfile roundtrip

      Support for comment preservation is not actively being worked on

      Many users have asked for preservation of comments, formatting and "shebang"s when loading and saving a Jenkinsfile through features like the Pipeline Editor. Due to technical and time constraints, this is infeasible to do in the short term without a high level of engineering investment.

      Problem
      Would be nice to have support for comments in the ModelAST. TBD whether the comments are required to be fully round-trip aware, but for anyone using the ModelAST classes to generate a groovy pipeline definition the ability to inject comments into the generated groovy would be incredibly useful.

          [JENKINS-38864] Add support for preserving comments and formatting for Jenkinsfile roundtrip

          Andrew Bayer added a comment -

          I guess so, but this is as close to "Never going to happen" as it can get without being 100% guaranteed to never happen. We'd literally have to write our own parser to do this and still use the Groovy compiler/parser to do validation. It would be a Bad Idea.

          Andrew Bayer added a comment - I guess so, but this is as close to "Never going to happen" as it can get without being 100% guaranteed to never happen. We'd literally have to write our own parser to do this and still use the Groovy compiler/parser to do validation. It would be a Bad Idea.

          Liam Newman added a comment -

          abayer
          If using the editor is going to strip comments, perhaps we should warn on finding any comments in Declarative Pipeline. They're effectively in the same boat as code outside the pipeline section - unsupported.

          Liam Newman added a comment - abayer If using the editor is going to strip comments, perhaps we should warn on finding any comments in Declarative Pipeline. They're effectively in the same boat as code outside the pipeline section - unsupported.

          Michael Neale added a comment -

          Yes, this is one of the price paid for groovy as pipeline config language. 

          Michael Neale added a comment - Yes, this is one of the price paid for groovy as pipeline config language. 

          Andrew Bayer added a comment -

          bitwiseman For the same reason we can't round-trip comments, we can't error/warning on comments either - from the Declarative parser's perspective, there never are any comments.

          Andrew Bayer added a comment - bitwiseman For the same reason we can't round-trip comments, we can't error/warning on comments either - from the Declarative parser's perspective, there never are any comments.

          Liam Newman added a comment -

          michaelneale
          I would say it is a bit more complex than that. :smile:

          abayer

          And saying we'd have to implement our own parser, overlooks the idea that this functionality could be added to Groovy itself or that the work might have already been done by someone else.

          Not to say it has any application here, but it looks like eclipse did exactly that. They have an AST model that includes a Comment class.
          There's also some thing called 'Parrot' - https://github.com/danielsun1106/groovy-parser.
          And there's at least one longer term exploration task in Groovy - https://issues.apache.org/jira/browse/GROOVY-4003.
          There's probably more.

          Liam Newman added a comment - michaelneale I would say it is a bit more complex than that. :smile: abayer And saying we'd have to implement our own parser, overlooks the idea that this functionality could be added to Groovy itself or that the work might have already been done by someone else. Not to say it has any application here, but it looks like eclipse did exactly that. They have an AST model that includes a Comment class. There's also some thing called 'Parrot' - https://github.com/danielsun1106/groovy-parser . And there's at least one longer term exploration task in Groovy - https://issues.apache.org/jira/browse/GROOVY-4003 . There's probably more.

          Andrew Bayer added a comment -

          Uggggggh. Well, it's still the case that it's not going to happen at any time in the foreseeable future and most likely will never happen. I mean, I sure don't have time to do it. =)

          Andrew Bayer added a comment - Uggggggh. Well, it's still the case that it's not going to happen at any time in the foreseeable future and most likely will never happen. I mean, I sure don't have time to do it. =)

          James Dumay added a comment - - edited

          abayer I hope you don't mind - I gave this ticket a title and description that was less "star trek" so it was easier to set beginner-level user expectations.

          James Dumay added a comment - - edited abayer I hope you don't mind - I gave this ticket a title and description that was less "star trek" so it was easier to set beginner-level user expectations.

          Liam Newman added a comment -

          I'm reopening this so that it doesn't go into the round file. It is not being worked worked on, but I don't think it is something we can simply never address.

          Liam Newman added a comment - I'm reopening this so that it doesn't go into the round file. It is not being worked worked on, but I don't think it is something we can simply never address.

          Michael Neale added a comment - - edited

          Yes I agree this is possibly quite important - if you think about comments as pipeline documentation. 

          some other options are to have first class elements somewere that store documentation, but that isn't groovy comments. 

          The effort/reward ratio here isn't clear to me yet, but documentation in pipeline will become VERY important I think, just don't know how to solve it with the groovy tax being paid. It's a very expensive tax. 

          Michael Neale added a comment - - edited Yes I agree this is possibly quite important - if you think about comments as pipeline documentation.  some other options are to have first class elements somewere that store documentation, but that isn't groovy comments.  The effort/reward ratio here isn't clear to me yet, but documentation in pipeline will become VERY important I think, just don't know how to solve it with the groovy tax being paid. It's a very expensive tax. 

          Michael Neale added a comment -

          I have opened https://issues.jenkins-ci.org/browse/JENKINS-43053 to see if a neater and simpler alternative is possible

          Michael Neale added a comment - I have opened https://issues.jenkins-ci.org/browse/JENKINS-43053  to see if a neater and simpler alternative is possible

            Unassigned Unassigned
            stephenconnolly Stephen Connolly
            Votes:
            2 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated: