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

          Stephen Connolly created issue -

          Michael Neale added a comment -

          right hrmpw jamesdumay - this may be important. May be. If we are round tripping Jenkinsfiles via the editor, MUST we war-and-peace that people may have written in comments?

          Michael Neale added a comment - right hrmpw jamesdumay - this may be important. May be. If we are round tripping Jenkinsfiles via the editor, MUST we war-and-peace that people may have written in comments?

          Andrew Bayer added a comment -

          Soooooo this isn't actually possible.

          By that, I mean comments aren't part of the Groovy AST - they're already discarded by the time we get to the compilation phase where we're translating the Groovy AST into the declarative ModelAST. I suppose that theoretically we could re-parse the original source and look for comments ourselves and somehow associate them with the ModelAST elements nearest them...but no. Not gonna happen. So this, sadly, is a won't-do.

          Andrew Bayer added a comment - Soooooo this isn't actually possible. By that, I mean comments aren't part of the Groovy AST - they're already discarded by the time we get to the compilation phase where we're translating the Groovy AST into the declarative ModelAST. I suppose that theoretically we could re-parse the original source and look for comments ourselves and somehow associate them with the ModelAST elements nearest them...but no. Not gonna happen. So this, sadly, is a won't-do.

          Andrew Bayer added a comment -

          Oh, and if it can't be round-tripped, then it isn't happening in general. I'm sticking hard to the requirement that everything be round-trippable.

          Andrew Bayer added a comment - Oh, and if it can't be round-tripped, then it isn't happening in general. I'm sticking hard to the requirement that everything be round-trippable.

          Michael Neale added a comment -

          abayer ok - then by that rule - no comments. They can use echo to put comments!
          And I like your thinking, this is how we have to work to make this right.

          However, what about stuff outside of "pipeline" block - presumably comments allowed, but round tripping doesn't cover that right?

          Michael Neale added a comment - abayer ok - then by that rule - no comments. They can use echo to put comments! And I like your thinking, this is how we have to work to make this right. However, what about stuff outside of "pipeline" block - presumably comments allowed, but round tripping doesn't cover that right?
          Andrew Bayer made changes -
          Resolution New: Won't Fix [ 2 ]
          Status Original: Open [ 1 ] New: Resolved [ 5 ]

          Liam Newman added a comment -

          abayer
          Is it okay if we reopen this? I understand if it is not feasible in the short (or even medium) term. However, since this results in loosing existing comments from a Jenkins file anytime someone uses the Blue Ocean editor on a file, it's going to be pretty annoying. I think we're going to get complaints.

          Saying "Won't fix" means "Never going to happen" as opposed to "We don't see how to do this now, but are open to doing revisiting".

          Liam Newman added a comment - abayer Is it okay if we reopen this? I understand if it is not feasible in the short (or even medium) term. However, since this results in loosing existing comments from a Jenkins file anytime someone uses the Blue Ocean editor on a file, it's going to be pretty annoying. I think we're going to get complaints. Saying "Won't fix" means "Never going to happen" as opposed to "We don't see how to do this now, but are open to doing revisiting".

          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. 

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

              Created:
              Updated: