3 ms·

I was dealing with this just yesterday funny enough. We didn't really like the idea of using `load()` to bring in a new file. I'll prefix the rest by saying we

I was dealing with this just yesterday funny enough. We didn't really like the idea of using `load()` to bring in a new file. I'll prefix the rest by saying we haven't actually implemented this yet, so YMMV. Our goal was to have a separate deploy pipeline that wasn't dependent on the test step (for various reasons I won't go into). We decided on creating a new job of type pipeline, and pointing it at a script named `Jenkinsfile.deploy`. It has a few parameters, namely `BRANCH`, that can be manually set, or passed in from another job. We can then move our deployment steps from the main Jenkinsfile into this new one, and still version control the lot. Major caveat is that the deploy step is not compatible with organisation scans (multibranch/pr), but that's fine for our use case. We usually want to trigger our builds manually based on the branch.

hrmpw 10y ago
I was playing around with a combination of Pipeline and Job-DSL and created this as a POC: https://gist.github.com/HRMPW/9b2a3ccbdc370e0a7c9cb541be229da9 https://gist.github.com/HRMPW/9b2a3ccbdc370e0a7c9cb541be229d... This is a Job-DSL seed job written in Declarative Pipeline that pulls in your Organization based on a build parameter and creates two jobs for every repo: 1. A multibranch Pipeline job that is based on the Jenkinsfile that will work across all branches and PRs. 2. A deploy job for the repo that is defined in a "jenkinsfile.deploy" file in the repo. This isn't a multibranch job but can be run on any branch based on a parameter for the branch. This is a very simplistic implementation but could be expanded on further.
Chico75 10y ago
Sounds like you would be better off putting the logic in separate function of a global library that you can then call in different stages for different conditions: https://jenkins.io/doc/book/pipeline/shared-libraries/ https://jenkins.io/doc/book/pipeline/shared-libraries/
- jsmeaton 10y ago
  For some things, yes, and we are planning to do this. Deployment is different between our projects though, so we'd prefer our deployment method to live within the repo beside other build steps.

hrmpw 10y ago

I was playing around with a combination of Pipeline and Job-DSL and created this as a POC: https://gist.github.com/HRMPW/9b2a3ccbdc370e0a7c9cb541be229da9 https://gist.github.com/HRMPW/9b2a3ccbdc370e0a7c9cb541be229d... This is a Job-DSL seed job written in Declarative Pipeline that pulls in your Organization based on a build parameter and creates two jobs for every repo: 1. A multibranch Pipeline job that is based on the Jenkinsfile that will work across all branches and PRs. 2. A deploy job for the repo that is defined in a "jenkinsfile.deploy" file in the repo. This isn't a multibranch job but can be run on any branch based on a parameter for the branch. This is a very simplistic implementation but could be expanded on further.

Chico75 10y ago

Sounds like you would be better off putting the logic in separate function of a global library that you can then call in different stages for different conditions: https://jenkins.io/doc/book/pipeline/shared-libraries/ https://jenkins.io/doc/book/pipeline/shared-libraries/

jsmeaton 10y ago
For some things, yes, and we are planning to do this. Deployment is different between our projects though, so we'd prefer our deployment method to live within the repo beside other build steps.