Version 2.0 will cover a few high-level epics:
-
Integration with Pipeline: Groovy Plugin
-
Code Cleanliness
-
Feature Development
Items for the 2.0 release are tracked via Issues on the repository and the 2.0 scope can be seen via the GitHub Project.
JTE Initialization (#87)
Until now, JTE’s initialization has taken place after the pipeline has actually started. From a code standpoint, that means it was happening within the pipeline as opposed to happening within "plugin" code. This introduced technical complexities associated with the fact that the plugin was limited in the same way that Jenkins pipelines are in regard to CPS.
This was accomplished by creating a TemplateEntryPoint Global Variable that provided a template step to Jenkins. This step would then go and compile the Entry Point Script in the resources directory. Every time a user selected "Jenkins Templating Engine" as the pipeline definition, we hard code that the pipeline simply invoked this template step via template() as seen Here.
This is visible to end users. When you try to "replay" a Jenkins pipeline that uses JTE what you’ll see as the main script is just template().
The first step to achieving a lot of the feature enhancements users were asking for relies on improving this initialization process.
JTE 2.0 completely rethinks how to initialize the pipeline. We have been able to completely remove the TemplateEntryPointVariable Global Variable.
Now, all JTE pipelines extend off of a TemplateFlowDefinition that makes use of an invisible build action called PipelineDecorator that handles the initialization process for JTE and stores the additions to be injected into the pipeline’s runtime environment via a GroovyShellDecoratorImpl.
This GroovyShellDecoratorImpl is then responsible for taking the primitives that were created and injecting them into the template’s environment prior to execution. This class also plugs into the compilation process of the template to wrap it in a try-finally such that JTE’s lifecycle hooks can be executed prior to template execution and post template execution.
Some users rely on the resumability of Jenkins Pipelines promised by Jenkins. Because of how JTE currently works, there is a bug preventing Jenkins from resuming a pipeline managed by JTE.
As JTE grows in adoption, there is plenty that can be done to improve our ability to collaborate on the code base. The following tickets are internal-facing changes that will help remediate technical debt, standardize coding styles, and better communicate the software architecture.
-
✓ move JTE behavior feature flags into a root level
jteblock in the pipeline configuration -
✓ Pipeline Job: added SCM pipeline configuration and template
-
✓ Document the StageContext functionality to pass arguments to steps run as part of a Stage
-
✓ Improve overall initialization logging for JTE to help users debug issues
-
❏ Investigate whether or not JTE can integrate with Jenkins Pipeline’s Declarative Syntax
Feel free to join the JTE Gitter Channel to join the conversation.
|
Important
|
Don’t see something you’d lke? Feel free to open an Issue on this repository and let’s get the conversation started :) |