Louis,
To answer your last question, if you decide to use declarative pipelines in
the end you can use the built-in tools like the declarative directive
generator and snippet generator. They will provide much the same UI as a
classic freestyle project which you configure according to your needs,
spitting out the relevant section which you can then copy/paste into your
pipeline script. You can read more about how to use these tools at
https://jenkins.io/doc/book/pipeline/getting-started/#built-in-documentation.
I've found them to be indispensable when starting out.
To expand on Jeremy's answer, it's possible to embed a scripted section
into a declarative pipeline. We do this fairly frequently, for example, to
define custom variables that can be used later in a pipeline. This example
parses some Git information and saves some variables for later:
stage('Init') {
steps {
buildName "${params.branch} @${params.commit[0..9]}"
checkout([...])
script {
dir(repo_subdir) {
commit_before_merge = params.commit
author_name = sh(script: "git log -n 1 ${params.commit}
--format='%an'", returnStdout: true).trim()
author_email = sh(script: "git log -n 1 ${params.commit}
--format='%ae'", returnStdout: true).trim()
commit_message = sh(script: "git log -n 1 ${params.commit}
--format='%B'", returnStdout: true)
commit_date = sh(script: "git log -n 1 ${params.commit}
--format='%ci'", returnStdout: true).trim()
addShortText text: author_email, border: 0, background:
'lightBlue'
}
}
}
}
Jordan
On Monday, July 29, 2019 at 6:40:56 PM UTC+3, Louis Elston wrote:
>
> 07/17/19 – wrote this…
>
> We are currently using Windows \ Jenkins 2.107.1 (no pipeline), and I am
> researching going to pipeline. We have a nightly build job, that fetches
> from repositories, and submits and waits on other jobs. I see 9 jobs
> running on the same Master node (we only have a master), at the same time.
> I am not clear on if we should have one Jenkinsfile or multiple
> Jenkinsfiles. It will not be a multibranch pipeline, as we do not create
> test branches and then merge back to a master. In the repository we have
> product1.0 branch, product2.0 branch etc., and build only one branch (the
> latest one). While I do like the Blue Ocean editor, it is only for
> MultiBranch pipelines.
>
> Looking for directions and\or examples on how to convert existing Jenkins
> non-pipeline systems, to pipeline. I did find this…
> https://wiki.jenkins.io/display/JENKINS/Convert+To+Pipeline+Plugin. It
> does help a little in that it gives you some converted steps, but cannot
> convert all the steps, and will give comments in the pipeline script
> "//Unable to convert a build step referring to...please verify and convert
> manually if required." There is an option "Recursively convert downstream
> jobs if any" and if you select that, it appears to add all the downstream
> jobs to the same pipeline script, and really confuses the job parameters.
> There is also an option to "Commit JenkinsFile" (if doing declarative). I
> will play with this some more, but it is not the be all and end all of
> converting to pipeline, and I still am not sure of whether I should be have
> one or more scripts.
>
> Added 07/26/19 - Let’s see if I have my research to date correct…
>
> A Declarative pipeline (Pipeline Script from SCM), is stored in a
> Jenkinsfile in the repository. Every time that this Jenkins job is
> executed, a fetch from the repository is done (to get the latest version of
> the Jenkinsfile).
>
> A Pipeline script is stored as part of the config.xml file in the
> Jenkins\Jobs folder (it is not stored in the repository, or in a separate
> Jenkinsfile in the jobs folder). There is a fetch from the repository only
> if you put it in (you do not need to do a repository fetch to get the
> Pipeline script).
>
> Besides our nightly product build, we also have other jobs. I could create
> a separate Declarative Jenkinsfile for each of them (JenkinsfileA,
> JenkinsfileB, etc.) for each of the other jobs and store then in the
> repository also (in the same branch as the main Jenkinsfile), but that
> would mean that every one of those additional jobs, to get the particular
> Jenkinsfile for that job, would also need to do a repository fetch
> (basically fetching\cloning the repository branch for each job, and have
> multiple versions of the repository branch unnecessarily downloaded to the
> workspace of each job).
>
> That does not make sense to me (unless my understanding of things to date
> is incorrect). Because the main product build does require a fetch every
> time it is run (to get any possible developer check-ins), I do not see a
> problem doing Declarative Jenkinsfile for that job. For the other jobs (if
> we do not leave then for the time being in the classic (non-pipeline)
> format)), they will be Pipeline scripts.
>
> Is there any way of (or plans for), being able to do Declarative pipeline
> without having to store in the repository and doing a fetch every time
> (lessening the need to become a Groovy developer)? The Blue Ocean script
> editor appears to be an easier tool to use to create pipeline scripts, but
> it is only for MultiBranch pipelines (which we don’t do).
>
> Serialization (restarting a job), is that only for when a node goes down,
> or can you restart a pipeline job (Declarative or Scripted), from any point
> if it fails?
>
> I see that there are places to look to see what Jenkins plugin’s have been
> ported to pipeline, but is there anything that can be run to look at the
> classic jobs that you have, to determine up front which jobs are going to
> have problems being converted to pipeline (non supported plugins)?
>
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-users/9d16dcfa-7da2-48fe-9611-03b55818dd99%40googlegroups.com.
