I am executing a job from my jenkinsfile to specify parameters i want to have in this automated run. The problem I face is that pollSCM doesn’t allow me to specifiy the repo that is to be polled. I want to poll the repo that is checked out in the build i will be starting and not the one where the jenkinsfile is located. Is there a way to achieve that?
As you already found out, the pollSCM trigger in Jenkins Pipeline is designed to poll the SCM of the Jenkinsfile’s own repository.
As far as I know, it doesn’t support polling other repositories directly.
You could maybe achieve your goal by creating a separate Jenkins job that is responsible for polling the desired repository.
I know, that’s not pretty.
This job could be a simple Freestyle job or Pipeline job that is configured to poll the SCM of the desired repository.
This job could trigger your main Pipeline job when changes are detected.
Here’s a rough untested example of how you could set up the separate job:
Create a Pipeline job in Jenkins.
In the job configuration, set up the SCM to point to the repository you want to poll.
In the “Build Triggers” section, enable “Poll SCM” and set the schedule as needed.
In the “post” section of your pipeline, add a build to your main Pipeline job.
Well i already have two jobs:
Job1 = The job that’s supposed to poll the scm and execute job2 with paramters.
Job2 = Job to be executed reguarly.
Are you implying it’s not possible to do in a jenkinsfile but somehow when using the UI? Also i would rather not do that since it will have to clone the whole repo for a job that isn’t doing much and i would have to setup multiple times probably also.
The git checkout step allows to configure the given repository to be included in the polling, at least the snippet generator provides a checkbox for this. Of course this can only work when the step is in the same pipeline. You can have multiple checkout steps in one job so you can potentially poll for multiple repos.
To avoid a full clone you could work with git ls-remote repo. You will need to persist the git hash you get yourself (so you need a fixed workspace, if the job can run on different agents that would not work out of the box) and then compare if something has changed and then trigger a build.
I do this myself ( the repo is over 10GiB and a clone takes about 1h and a simple fetch 2-3 minutes) and store the file with the last git hash on an nfs share. But the ls-remote check takes a second or so.