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

Allow "local" Shared Library to be loaded from current repo branch

      For context see: https://jenkins.io/blog/2017/02/15/declarative-notifications/
      And the linked bugs, in particular JENKINS-41396.

      I've been informed that this is a horrible idea, but I'm going to describe it here just to make sure.

      There have been a number of issues and discussions going around, dealing with how to define variables and methods in Declarative Pipeline.

      Right now, we can define variables and methods outside of the pipeline section but that is not a supported solution and it is not viable long-term.

      As noted in JENKINS-41396, we have a supported way to define variables and methods that we can use in Declarative Pipeline via
      Shared Libraries. However, that means I have to spin up a separate repository just to make a helper method that might be used in only one
      Pipeline.

      JENKINS-41396 and JENKINS-41335 suggest adding sections to the Declarative Pipeline model to allow these things to defined inside
      the same Jenkinsfile. This is also problematic: there are implementation issues, and it means that the distinction between the overall flow
      (defined in Declarative Pipeline) and the implementation details (defined in methods, variables, and classes) becomes more blurry.

      What I'm suggesting, is we reuse the functionality of "Shared libraries" but support loading from a subfolder in the current branch of the currently checked out repository.

      This would have a number of benefits over other solutions, it would:

      • reuse existing (and tested) functionality, limiting risk
      • not require creating a separate repository
      • keep the script code out of the Declarative Pipeline Jenkinsfile
      • use the same file/folder structure as Shared Library, getting users familiar with it for when they decide to use Shared Libraries

      On the downside, it would:

      • depend on additional folder/files beyond Jenkinsfile (method and define would be in Jenkinsfile)
      • require some changes to workflow-cps-global-lib to support loading from local and from subfolder instead of root folder.
      • make users have to understand library folder/file structure even to write simple helper method.

      We had a IRC chat about this, which I've attached.

      Also attached are images from a Pipeline job that I created as a proof-of-concept.
      The code for this POC is in: https://github.com/bitwiseman/hermann/tree/issue/jenkins-library/example

      What is not shown/done in the POC:

      • loading from a subfolder (not currently supported), subfolder name should default to "jenkins" (maybe?) and be configurable to other values.
      • * Worked around by putting the vars folder in the root - this would not work if the project already had a src or vars folder.
      • loading from the currently checked out branch/commit (not currently supported)
      • * Worked around by hard coding the branch name
      • using a library local directive to tell declarative to load a local library
      • * Worked around by adding the configuration to the parent Multibranch pipeline job and loading implicitly.
      • Using the already checked-out code
      • * Shared library simply clones it's own copy. For this small repo, this is fine, for larger projects it would not be acceptable.

          [JENKINS-42079] Allow "local" Shared Library to be loaded from current repo branch

          Liam Newman created issue -
          Liam Newman made changes -
          Description Original: For context see: https://jenkins.io/blog/2017/02/15/declarative-notifications/
          And the linked bugs, in particular JENKINS-41396.


          See:
          https://github.com/bitwiseman/hermann/tree/issue/jenkins-library/example
          New: For context see: https://jenkins.io/blog/2017/02/15/declarative-notifications/
          And the linked bugs, in particular JENKINS-41396.

          I've been informed that this is a horrible idea, but I'm going to describe it here just to make sure.

          See:
          https://github.com/bitwiseman/hermann/tree/issue/jenkins-library/example
          Liam Newman made changes -
          Description Original: For context see: https://jenkins.io/blog/2017/02/15/declarative-notifications/
          And the linked bugs, in particular JENKINS-41396.

          I've been informed that this is a horrible idea, but I'm going to describe it here just to make sure.

          See:
          https://github.com/bitwiseman/hermann/tree/issue/jenkins-library/example
          New: For context see: https://jenkins.io/blog/2017/02/15/declarative-notifications/
          And the linked bugs, in particular JENKINS-41396.

          I've been informed that this is a horrible idea, but I'm going to describe it here just to make sure.

          There have been a number of issues and discussions going around, dealing with how to handle variables and methods in Declarative Pipeline.



          See:
          https://github.com/bitwiseman/hermann/tree/issue/jenkins-library/example
          Liam Newman made changes -
          Component/s New: pipeline-model-definition-plugin [ 21706 ]
          Liam Newman made changes -
          Attachment New: irclog.txt [ 35993 ]
          Liam Newman made changes -
          Description Original: For context see: https://jenkins.io/blog/2017/02/15/declarative-notifications/
          And the linked bugs, in particular JENKINS-41396.

          I've been informed that this is a horrible idea, but I'm going to describe it here just to make sure.

          There have been a number of issues and discussions going around, dealing with how to handle variables and methods in Declarative Pipeline.



          See:
          https://github.com/bitwiseman/hermann/tree/issue/jenkins-library/example
          New: For context see: https://jenkins.io/blog/2017/02/15/declarative-notifications/
          And the linked bugs, in particular JENKINS-41396.

          I've been informed that this is a horrible idea, but I'm going to describe it here just to make sure.

          There have been a number of issues and discussions going around, dealing with how to handle variables and methods in Declarative Pipeline.




          See:
          https://github.com/bitwiseman/hermann/tree/issue/jenkins-library/example
          Liam Newman made changes -
          Link New: This issue relates to JENKINS-41396 [ JENKINS-41396 ]
          Liam Newman made changes -
          Link New: This issue relates to JENKINS-41335 [ JENKINS-41335 ]
          Liam Newman made changes -
          Link New: This issue relates to JENKINS-39450 [ JENKINS-39450 ]
          Liam Newman made changes -
          Description Original: For context see: https://jenkins.io/blog/2017/02/15/declarative-notifications/
          And the linked bugs, in particular JENKINS-41396.

          I've been informed that this is a horrible idea, but I'm going to describe it here just to make sure.

          There have been a number of issues and discussions going around, dealing with how to handle variables and methods in Declarative Pipeline.




          See:
          https://github.com/bitwiseman/hermann/tree/issue/jenkins-library/example
          New: For context see: https://jenkins.io/blog/2017/02/15/declarative-notifications/
          And the linked bugs, in particular JENKINS-41396.

          I've been informed that this is a horrible idea, but I'm going to describe it here just to make sure.

          There have been a number of issues and discussions going around, dealing with how to define variables and methods in Declarative Pipeline.

          Right now, we can define variables and methods outside of the pipeline section but that is not a supported solution and it is not viable long-term.

          As noted in JENKINS-41396, we have a supported way to define variables and methods that we can use in Declarative Pipeline via
          Shared Libraries. However, that means I have to spin up a separate repository just to make a helper method that might be used in only one
          Pipeline.

          JENKINS-41396 and JENKINS-41335 suggest adding sections to the Declarative Pipeline model to allow these things to defined inside
          the same {{Jenkinsfile}}. This is also problematic: there are implementation issues, and it means that the distinction between the overall flow
          (defined in Declarative Pipeline) and the implementation details (defined in methods, variables, and classes) becomes more blurry.

          What I'm suggesting, is we reuse the functionality of "Shared libraries" but support loading from a subfolder in the current branch of the currently checked out repository.

          This would have a number of benefits over other solutions, it would:
          * reuse existing (and tested) functionality, limiting risk
          * not require creating a separate repository
          * keep the script code out of the Declarative Pipeline Jenkinsfile
          * use the same file/folder structure as Shared Library, getting users familiar with it for when they decide to use Shared Libraries

          On the downside, it would:
          * require additional files beyond Jenkins file (method and define would be in Jenkinsfile)
          * TODO still editing.



          See:
          https://github.com/bitwiseman/hermann/tree/issue/jenkins-library/example
          Liam Newman made changes -
          Description Original: For context see: https://jenkins.io/blog/2017/02/15/declarative-notifications/
          And the linked bugs, in particular JENKINS-41396.

          I've been informed that this is a horrible idea, but I'm going to describe it here just to make sure.

          There have been a number of issues and discussions going around, dealing with how to define variables and methods in Declarative Pipeline.

          Right now, we can define variables and methods outside of the pipeline section but that is not a supported solution and it is not viable long-term.

          As noted in JENKINS-41396, we have a supported way to define variables and methods that we can use in Declarative Pipeline via
          Shared Libraries. However, that means I have to spin up a separate repository just to make a helper method that might be used in only one
          Pipeline.

          JENKINS-41396 and JENKINS-41335 suggest adding sections to the Declarative Pipeline model to allow these things to defined inside
          the same {{Jenkinsfile}}. This is also problematic: there are implementation issues, and it means that the distinction between the overall flow
          (defined in Declarative Pipeline) and the implementation details (defined in methods, variables, and classes) becomes more blurry.

          What I'm suggesting, is we reuse the functionality of "Shared libraries" but support loading from a subfolder in the current branch of the currently checked out repository.

          This would have a number of benefits over other solutions, it would:
          * reuse existing (and tested) functionality, limiting risk
          * not require creating a separate repository
          * keep the script code out of the Declarative Pipeline Jenkinsfile
          * use the same file/folder structure as Shared Library, getting users familiar with it for when they decide to use Shared Libraries

          On the downside, it would:
          * require additional files beyond Jenkins file (method and define would be in Jenkinsfile)
          * TODO still editing.



          See:
          https://github.com/bitwiseman/hermann/tree/issue/jenkins-library/example
          New: For context see: https://jenkins.io/blog/2017/02/15/declarative-notifications/
          And the linked bugs, in particular JENKINS-41396.

          I've been informed that this is a horrible idea, but I'm going to describe it here just to make sure.

          There have been a number of issues and discussions going around, dealing with how to define variables and methods in Declarative Pipeline.

          Right now, we can define variables and methods outside of the pipeline section but that is not a supported solution and it is not viable long-term.

          As noted in JENKINS-41396, we have a supported way to define variables and methods that we can use in Declarative Pipeline via
          Shared Libraries. However, that means I have to spin up a separate repository just to make a helper method that might be used in only one
          Pipeline.

          JENKINS-41396 and JENKINS-41335 suggest adding sections to the Declarative Pipeline model to allow these things to defined inside
          the same {{Jenkinsfile}}. This is also problematic: there are implementation issues, and it means that the distinction between the overall flow
          (defined in Declarative Pipeline) and the implementation details (defined in methods, variables, and classes) becomes more blurry.

          What I'm suggesting, is we reuse the functionality of "Shared libraries" but support loading from a subfolder in the current branch of the currently checked out repository.

          This would have a number of benefits over other solutions, it would:
          * reuse existing (and tested) functionality, limiting risk
          * not require creating a separate repository
          * keep the script code out of the Declarative Pipeline Jenkinsfile
          * use the same file/folder structure as Shared Library, getting users familiar with it for when they decide to use Shared Libraries

          On the downside, it would:
          * require additional files beyond Jenkins file (method and define would be in Jenkinsfile)
          * would require some changes to pipeline



          See:
          https://github.com/bitwiseman/hermann/tree/issue/jenkins-library/example

            Unassigned Unassigned
            bitwiseman Liam Newman
            Votes:
            16 Vote for this issue
            Watchers:
            25 Start watching this issue

              Created:
              Updated: