Details
-
New Feature
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Won't Fix
-
None
Description
I have several use cases where I may operate on a list or map on different stages of a pipeline. This variable may not be known ahead of time - it could be defined within a stage. I'd like a syntax that allows me to define variables within a pipeline.
Today, I have to define a shared variable before entering pipeline {}.
#!/bin/groovy // Define outside of pipeline to make sure accessible in all script {} blocks def my_list pipeline { agent { label 'label' } stages { stage('stage1') { steps { script { my_list = [1,2,3] } } } stage('stage2') { steps { script { for(int i=0; i<my_list.size();i++) { echo "Doing something with ${my_list[i]}" } } } } } }
A simple approach would be to allow "def" to work anywhere within pipeline {}. This avoids any overly new syntax for pipeline.
Another option would allow the user to provide a special pipeline {} block for defining non-env/params style variables. This could be helpful in allowing the user to use items available in script {} for defining shared state.
#!/bin/groovy pipeline { agent { label 'label' } define { def my_map = [:] //empty map def my_list //undefined shared variable } stages { stage('stage1') { steps { script { //If def can be anywhere in pipeline {}, drop script {} my_list = [1,2,3] } } } stage('stage2') { steps { script { for(int i=0; i<my_list.size();i++) { echo "Doing something with ${my_list[i]}" } } } } } }
Attachments
Issue Links
- is blocked by
-
JENKINS-39450 Add a LibraryStep for loading shared libraries within a Pipeline
-
- Resolved
-
- relates to
-
JENKINS-42079 Allow "local" Shared Library to be loaded from current repo branch
-
- Open
-
-
JENKINS-42360 Globals not accessible in Declarative Pipeline outside script directive
-
- Closed
-
-
JENKINS-41396 Add method definition section to root pipeline block
-
- Closed
-
svanoort I thought I had read somehwhere that the roadmap was for scripted to eventually be deprecated, and that declarative would replace it.
In any case, I second Liam's point that it would be interesting to see documents explaining this vision. It would help, at the very least, people to make long term decisions for their CI architecture around Jenkins.