I use the declarative "libraries" directive in all my pipelines:

      libraries {
        lib('test@asdf')
      } 

      Without realising the drawbacks of this syntax, I started using it a couple of years ago.

      Basically, it does not support the "changelog=false" parameter and it ignores the "Include @Library changes in recent job changes" setting, which makes sense if you know that @Library is a completely different command. 

      However, there is no way to avoid triggering all projects, including libs, when they are updated, which is problematic in many ways.

      There are a number of open issues regarding the behaviour of "lib change triggers builds" and I think this confusion is the main reason. 

      During my investigation I checked the documentation and found that the "libraries" directive is the only one that is not documented. The directive generator shows it, but gives no further information.

      So is this directive supported or deprecated?

      Personally, I like it better than the @Library syntax, but it should honour the "ignore changes" option globally and by parameter.

      A bunch of related issues are here:

      https://issues.jenkins.io/browse/JENKINS-65649

      https://issues.jenkins.io/browse/JENKINS-41497

      https://issues.jenkins.io/browse/JENKINS-39615

          [JENKINS-71127] "libraries" directive is not documented

          Jesse Glick added a comment -

          I suppose you refer to the Declarative Pipeline syntactic sugar. Indeed according to https://github.com/jenkinsci/pipeline-model-definition-plugin/blob/ddba44ad605e472e62087785d43bddd1b8431149/pipeline-model-definition/src/main/resources/org/jenkinsci/plugins/pipeline/modeldefinition/ModelInterpreter.groovy#L791-L802 this just call the Pipeline step with its default (identifier) argument. The actual step, as called from Scripted syntax, supports changelog and more: https://www.jenkins.io/doc/pipeline/steps/pipeline-groovy-lib/#library-load-a-library-on-the-fly

          It is true that neither https://www.jenkins.io/doc/book/pipeline/syntax/ nor https://www.jenkins.io/doc/book/pipeline/shared-libraries/ even mentions the existence of this directive. Docs patches welcome.

          Also confirmed that https://ci.jenkins.io/directive-generator/ picking libraries does not mention anything about changelogs, and links to https://www.jenkins.io/doc/book/pipeline/syntax/#libraries which is a nonexistent anchor. Note that by policy, all product links to jenkins.io docs should be in the form of a named redirect which can be tracked by site infrastructure; this plugin appears to violate that policy here for various directives.

          Jesse Glick added a comment - I suppose you refer to the Declarative Pipeline syntactic sugar. Indeed according to https://github.com/jenkinsci/pipeline-model-definition-plugin/blob/ddba44ad605e472e62087785d43bddd1b8431149/pipeline-model-definition/src/main/resources/org/jenkinsci/plugins/pipeline/modeldefinition/ModelInterpreter.groovy#L791-L802 this just call the Pipeline step with its default ( identifier ) argument. The actual step, as called from Scripted syntax, supports changelog and more: https://www.jenkins.io/doc/pipeline/steps/pipeline-groovy-lib/#library-load-a-library-on-the-fly It is true that neither https://www.jenkins.io/doc/book/pipeline/syntax/ nor https://www.jenkins.io/doc/book/pipeline/shared-libraries/ even mentions the existence of this directive. Docs patches welcome. Also confirmed that https://ci.jenkins.io/directive-generator/ picking libraries does not mention anything about changelogs, and links to https://www.jenkins.io/doc/book/pipeline/syntax/#libraries which is a nonexistent anchor. Note that by policy, all product links to jenkins.io docs should be in the form of a named redirect which can be tracked by site infrastructure; this plugin appears to violate that policy here for various directives.

          Bartosz Nowak added a comment -

          Bartosz Nowak added a comment - Hi, This feature is not implemented. https://github.com/jenkinsci/pipeline-model-definition-plugin/blob/master/pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/parser/ModelParser.groovy#L742-L748 Currently, SCM reviver is ignored by the parser.

          Per Östman added a comment - - edited

          This issue is (seemingly) the cause for triggering a build storm every time a change is made to one of our shared libraries.

          Is there any idea for when a fix can be available? 

          Edit:

          It doesn't seem to help using "Legacy SCM" for the shared library either.

          This is causing a major headache since every change to a shared library causes a massive build storm on the jenkins systems...

          Per Östman added a comment - - edited This issue is (seemingly) the cause for triggering a build storm every time a change is made to one of our shared libraries. Is there any idea for when a fix can be available?  Edit: It doesn't seem to help using "Legacy SCM" for the shared library either. This is causing a major headache since every change to a shared library causes a massive build storm on the jenkins systems...

          Per Östman added a comment -

          Any plans for addressing this? As stated by many, this is a headache...

          Per Östman added a comment - Any plans for addressing this? As stated by many, this is a headache...

            Unassigned Unassigned
            debugbug Richard
            Votes:
            3 Vote for this issue
            Watchers:
            8 Start watching this issue

              Created:
              Updated: