I agree with this answer. With a pipeline, it is so easy to make logic
decisions and much easier to maintain a single Jenkinsfile that has all the
logic. There is surely going to be some duplicated logic, so now only the
special differences have to be handled, and you don't duplicate code across
the Jenkinsfiles. I have taken several other peoples jobs and consolidated
them exactly like this, with just a parameter. If you have 3 different
pipeline files, but all in the same branch, then things get complicated
when you try to decide which build should be triggered from polling or a
hook, anyway. You might as well put it all in one place and handle the
logic there.
On Monday, October 2, 2017 at 1:23:43 PM UTC-6, dandeliondodgeball wrote:
>
> I think you can have a "build" variable (
> https://jenkins.io/doc/pipeline/tour/environment/), or parameter (below),
> and use the value assigned to that.
>
> Using parameters in a Jenkinsfile. When this runs you will get an
> interactive window.
>
> pipeline {
> agent any
> parameters {
> string(name: 'Stack', defaultValue: 'Production', description: 'Which
> environment is this for?')
> }
> stages {
> stage('Build') {
> steps {
> echo "Running BuilId [${env.BUILD_ID}] on JenkinsUrl
> [${env.JENKINS_URL}] for Job [${env.JOB_NAME}]"
> //
> sh " ${params.Stack} buildIt"
>
>
>
>
--
You received this message because you are subscribed to the Google Groups
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-users/7c332a1e-9531-4a0b-b63c-db48ee5e278a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
