Jenkins: load Jenkinsfile from another repository than the repository I want to build

Question

So I'm thinking about this setup but I'm not even sure if it's possible. I work in a larger organization and we want to perform static code analysis and unit tests on various projects. These projects are all modules that follow the same pattern, so let's say for the sake of simplicity I have 30 projects that all can be built with the same Jenkinsfile. The only difference in the Jenkinsfile would be the repository in the checkout stage.

Now I was thinking if it would be possible to have 1 repository containing the Jenkinsfile, and have the other 30 repositories use that repository (using "pipeline script from SCM") to fetch the Jenkinsfile. I would then set the url-attribute in the git command in the Checkout-step with a parameter (or something).

Now my questions:

• Is a setup like this even possible? (Having the Jenkinsfile in a different repository than the repository you want to build).
• How would this work with polling? Would Jenkins still poll the proper repository for changes (one of the 30 different ones) or would it only poll the one repository containing the Jenkinsfile (this is not what I want obviously).

Any answers, ideas or suggestions would be highly appreciated.

Virge

Anything you check out inside a Jenkinsfile using checkout is automatically included in polling unless you explicitly turn it off with checkout poll: false, scm: ... – Immediacy

Answer 1

Q:Is a setup like this even possible? (Having the Jenkinsfile in a different repository than the repository you want to build).

A: Yes it is. You can specify Jenkins to pull in as many repos as you want.

Q: How would this work with polling? Would Jenkins still poll the proper repository for changes (one of the 30 different ones) or would it only poll the one repository containing the Jenkinsfile (this is not what I want obviously).

A: It would poll the scm that has the Jenkinsfile. This is important if you add changes to the Jenkinsfile. To remedy this (since you specified that this is behavior you do not want) you can add commit hooks or tokens in your repo that will essentially kick off the Jenkins job if the repo changes or when other circumstances happen (it varies depending on what repo hosting tool you're using, ie Github vs gitlab vs bitbucket etc). Otherwise you can also kick it off manually, but the automated way sounds like what you want.

---

As for implementation

• This could be done with a multi-branch pipeline. Have one repository for all the variations of the jenkinsfiles, and each branch has the defining git scm <repo> you mentioned. This way you can also have tokens/hooks in each so that if anything happens in the repo the corresponding job will autmatically be kicked off. The one minor set back to this is that you may have 30+ branches in the Jenkinsfile repository (or however many depending on the number of repos you have)

• You can also certainly do what you mentioned above, having the Jenkinsfile job take a parameter for what repo it will use. My team has jobs like this where you specify the git_url and git_treeish (branch) so that you can point it to master or your personal fork for testing. The caveat to this is each build could have different results or artifacts and you'd have to check the build parameters on a per build basis to know what you are looking at if the repos make similar artifacts or results. (Ex: if you're running tests, your test result aggregation may not be clear because one build had results from Project/Repo A while another build had results from Project/Repo B etc). If you are forwarding artifacts/results to another job, this wouldn't be too much of a problem, you could base the post build procedure on the repo parameter you initially supplied.

If you comment with more details I can give you some code snippets or post a gist with examples if you need any.

Yunyunfei

Answer 2

This should be done with a shared library. This makes everything work easy, including polling, but centralizes the code. You still have to be able to touch each project to put a Jenkinsfile in each repo, but that Jenkinsfile can be a minimal call to the shared library.

It is an elegant solution, because each repo can set a few project-specific variables as needed, and then make the call. If you have the ability to put a Jenkinsfile in each repo, this is the way to do it.

Saraann