I have a simple Jenkins pipeline project that I want to trigger when pushes occur to the master branch only, I have configured the pipeline with the following settings:
Build Triggers: GitHub hook trigger for GITScm polling.
Pipeline:
- Definition: Pipeline script from SCM
- SCM: Git
- Repository URL: $URL
- Credentials: SSH keys configured in Jenkins
- Branch Specifier: refs/heads/master (I have also tried setting this to */master to no avail)
Script Path: Jenkinsfile
Now the issue is that regardless of what ref
my push occurs on, this pipeline is kicked off and runs. For example, the deletion or creation of a tag, will kick off this pipeline.
I'm not seeing this behavior with similarly defined pipelines in the same Jenkins instance, but they are defined exactly the same (except for pointing to a different repository in the same GitHub instance).
Does anyone have any ideas as to where I could look to troubleshoot why any GitHub push regardless of what ref
it was for, builds this pipeline?
EDIT:
What I am noticing is that for builds that behave correctly (do not get executed on non-master pushes), the Jenkins log shows the following:
[2023-11-14 18:20:08] [INFO] Received PushEvent for https://$GITHUB_REPO from $IP_ADDRESS ⇒ https://$JENKINSURL/webhook
[2023-11-14 18:20:08] [INFO] Poked GoodPipeline
[2023-11-14 18:20:08] [FINEST] lastBuildRevisionSha1 matches sha1:029801983091280128101290129012, returning lastBuild
[2023-11-14 18:20:09] [FINEST] lastBuildRevisionSha1 matches sha1:029801983091280128101290129012, returning lastBuild
For this pipeline that behaves incorrectly, the logs show the following:
[2023-11-14 18:16:23] [INFO] Received PushEvent for https://$GITHUB_REPO from $IP_ADDRESS ⇒ https://$JENKINS_URL/webhook
[2023-11-14 18:16:23] [INFO] Poked MyPipeline
[2023-11-14 18:16:24] [FINEST] lastBuildRevisionSha1 matches sha1:103981293812312391239012390123, returning lastBuild
[2023-11-14 18:16:24] [FINEST] lastBuildRevisionSha1 matches sha1:103981293812312391239012390123, returning lastBuild
[2023-11-14 18:16:25] [FINEST] lastBuild is null
[2023-11-14 18:16:25] [FINEST] No match found in getLastBuild for sha1:103981293812312391239012390123, returning null
[2023-11-14 18:16:25] [INFO] SCM changes detected in MyPipeline. Triggering #5
I do have previous builds in the history in the pipeline that is malfunctioning, so I'm not sure why it cannot find them.
Your branch specifier seems correct (
refs/heads/master
or*/master
). However, make sure there are no typos or extra spaces.And the Jenkinsfile in your
master
branch should not have any configurations that might override the branch specifier.As a test/workaround: to implement a check in the Jenkinsfile that will exit the pipeline if it is not the
master
branch, you can add a conditional at the beginning of your pipeline script:Go to your GitHub repository's settings, check the webhook configuration for your Jenkins server, and make sure the webhook is set to trigger only for "push" events, and not for "tag push" events.
Also, modify your Jenkinsfile to explicitly check if the ref is a tag or a branch. If it is a tag, you can abort the build.
In the malfunctioning pipeline, the log entries
[FINEST] lastBuild is null
and[FINEST] No match found in getLastBuild for sha1...
suggest that Jenkins is unable to associate the incoming commit SHA with any of the previous builds in the pipeline's history.That leads to Jenkins considering every push as a new change, thus triggering the build.
Make sure the SCM polling is configured correctly in Jenkins. It should accurately reflect the repository and branch you are targeting.
Double-check your Jenkinsfile and pipeline configuration for any differences between the working pipeline and the malfunctioning one, particularly in how the SCM is set up.
Also, verify that the SHA1 mentioned in the logs corresponds to a commit in the
master
branch of your repository. If it is not frommaster
, it could indicate that Jenkins is incorrectly processing events from other branches or tags.Inspect the build history of the malfunctioning pipeline. If there are issues with how Jenkins is maintaining the build history or associating builds with specific SHA1s, this could lead to the problem you are experiencing.