7

I have a repository that does not contain a Jenkinsfile - and I have no way of influencing the repository itself. This means I can neither add nor alter any files to or in the repository (In this case, its the Qt repo).

What I want to do is create multiple Jenkinsfiles, that are each configuring and building the Qt library for a different target, or run different additional scripts.
All these Jenkinsfiles will be collected in a different repository.

Now, my problem is how to create a pipeline job, that gets triggered, as soon as there are changes in the Qt repository, but uses a Jenkinsfile from the other repository.

Research left me - as far as I can see and according to these posts - with two options:

  • Adding both repositories to the Definition section - something along the lines of this:
    enter image description here Unfortunately, this does not work for me, as both repositories would still need a Jenkinsfile. Further, I cannot specify a different branch for each repository, so I cannot listen to a specific Qt Version branch.

  • The second (well, probably the only) option I see, would be to create a freestyle Jenkins job, that solely listens to the Qt repository and triggers a build of the pipeline job on a change as its only action.

I reckon, that the second approach would work for me, but what I want to know, is whether there is any plugin, configuration option or whatever that I missed that can solve this in a cleaner way, or whether the above is the way to do it.

Community
  • 1
  • 1
T3 H40
  • 2,326
  • 8
  • 32
  • 43

3 Answers3

5

Why don't you create a Jenkins Freestyle Job that monitors the QT repo using the regular "Poll SCM" method?

Then have that Freestyle job kick off one or more of your Jenkins pipeline jobs.

You would have the pipeline jobs point at the SCM where the pipeline "jenkinsFile" groovy scripts live (the repos you control).

Inside the pipeline code, you can use a pipeline SCM DSL step to pull code from the Qt repo (the one not under your control) then do all the building, testing or whatever.

You can pass the URL and revision of the Qt Repo into the pipeline as a parameter from the polling job.

macg33zr
  • 1,725
  • 15
  • 13
  • Yes, this is what I worked out to be the way, too, as I described in my question. What I wanted to know was, whether there is a more elegant solution, which currently does not seem to be the case. Passing the revision is a useful idea that I did not yet think about, so +1. – T3 H40 Dec 13 '16 at 16:20
  • Sorry missed the second point. Agree - a more elegant solution to this in the pipeline DSL or configuration would be better. – macg33zr Dec 15 '16 at 10:42
2

Did you think about a webhook that triggers the Jenkins job from your Git server? This way you can have arbitrary repos trigger your build and reduce the traffic on the Git server caused by the periodic poll from Jenkins.

The principle behind it is that Jenkins provides a URL for your build job (e.g. http://your-jenkins.domain/job/JOBNAME/build?token=TOKEN) that starts your job. Git on the other hand can register a so called hook that is triggered whenever a push is made to the repository. Adding a HTTP request to your Git hook will trigger the Jenkins job every time someone pushes to your repository.

This SO Post explains how to set up such a hook with any Git server. There are also tutorials for Gitlab and Github.

Community
  • 1
  • 1
Michael Lihs
  • 7,460
  • 17
  • 52
  • 85
  • Thank you, I will have a closer look at this, as soon as my vacation is over. However, upon first glance, the problem I see is *"The hooks are all stored in the hooks subdirectory of the Git directory."* As I have (probably not well enough) mentioned, I have no influence over the target repo. – T3 H40 Jan 03 '17 at 16:59
  • I had another look at this, but as I said, I am afraid this won't work for me. I have no influence over the repo in question, so I cannot add a git-hook in it. I thought about maybe creating a repository with the repo I want to listen to as a submodule, and install some form of post-commit hook on the submodule there, but as far as I understand, because submodules run in detached HEAD mode, the containing repo will not get notified over external changes to the submodule. So in short, this is a well written answer but unfortunately does not solve my problem. – T3 H40 Jan 09 '17 at 07:46
-3

You can configure a build trigger, to check if there are changes in the repository: Build Trigger -> Poll SCM. There you can configure a schedule:

For example * * * * * to check every minute or H * * * * to check hourly.

SevenEleven
  • 2,326
  • 2
  • 32
  • 32
  • 1
    Sure, but this will only poll the repositories that are set in the pipeline section, that is visible on the screenshot above. I have no option to select a specific repo to poll, and the problems described above still apply. I do not get the *Source-Code-Management* Section in a pipeline job, that I would get in a freestyle job. – T3 H40 Dec 13 '16 at 09:32