Ability to include groovy steps defined in the application repository

[Vince-Cercury]

Feature Request

Sometimes an application or team need to implement a different step. Which may not be useful to any other application or team. For instance handling of custom test framework.

Step implementation https://jenkinsci.github.io/templating-engine-plugin/pages/Primitives/default_step_implementation.html#default-step-implementation
sort of allow that. But it is only for simple steps that are docker based. Not suitable for series of commands, try/catch, if conditions, etc.

At the moment, that particular app or team would have to implement that step in a separate repository and add the library inclusion in the definition of the job. They could use the same repository as the application, but even then, the lib needs to be added to the job configuration. And they would have to specify the branch. Which is confusing as multi-branch pipeline is already handling multiple branches.

Can we load libraries defined locally, in a subfolder, alongside the pipeline_config.groovy?

[steven-terrana]

thanks for the feature idea @Vince-Cercury!

this ought to be possible and would definitely consider implementing this after I work through the 2.0 scope.

a few thoughts:

1. It should be possible for a governance tier to disable this functionality. Many users leverage JTE because of the governance it can bring to Jenkins pipelines. I would think that repository libraries would take the highest precedence when loading and thus could override governance tier library sources. Something like an allow_local_libraries = false or something to disable the functionality.

2. We'll need a way to fetch the information required to load the library. maybe we could determine a default subdirectory name and then allow it to be overridden via the library spec? maybe something like:

libraries{
  libA
  libB{
    local = true // check in repository under the default repo subdir
  }
  libC{
    local = true // check in repository
    local_path = "my_custom_subdir/nested" // check custom path for library
  }
}

3. Would the expectation be that the library be loaded from the same branch as the pipeline for a multi-branch project? It could be possible to include a version in the library spec described above but interacting with arbitrary SCM plugins (git-branch-source, github-branch-source, gitlab-branch-source, bitbucket-branch-source) can be ..... challenging. (The code to fetch files from remote SCMs is more cumbersome than the rest of JTE 😂).

Would love your feedback on the specifics of how this should work!

[Vince-Cercury]

1. The stages are template are controlled by the governance tier.
   So even if a local library is included, there is already some form of control as it may not be allowed to be used unless a stage block allows merge or override.
   The problem may arise if a local library is same name as an external one. In which case, maybe it should just error out. I don't mind though.

2. default subdirectory sounds good. With ability to override path. I don't think we need to override path for each lib. But I don't mind

" library be loaded from the same branch as the pipeline for a multi-branch project"
-> yes this is easier for everyone. For testing as well.

[steven-terrana]

circling back to this 😓 .

Perhaps it would be simplest to support something like:

jte{
  local_library= ".jte" 
}

so if the branch is a Multibranch Project then and JTE will just load the library designated at that path with no need to add anything at all to the libraries block.

JTE would then fail if this field was set and the path declared wasn't a directory with at least a src or steps subdirectory.

Pipeline admins that wished to disable this could always define:

jte{
  local_libraries = false 
}

and simply not allow teams to set this field if they wished to lock it down.