Perforce commit triggering wrong build
2 views
Skip to first unread message
Jonathan Bergh
Apr 25, 2018, 5:25:31 PM4/25/18
to Jenkins Users
Hi
We have a number of projects which are building out of Perforce. We trigger the builds using SCM polling, as we dont want to expose a port on the firewall for Perforce to connect into to trigger build on the build server.
Because most of the builds are similar, i have generated a number of the projects by cloning a parent project (which was working correctly) and then changing the most important information, such as the Perforce view etc.
I am using Auto cleanup and Sync to populate the workspace, and the workspace mappings are the following for each of the products:
Job1
//depot/productA/1/x/... //jenkins_ws/...
Job2
//depot/productA/2/x/... //jenkins_ws/...
Job3
//depot/productB/1/x/... //jenkins_ws/...
Job4
//depot/productC/1/x/... //jenkins_ws/...
The strange problems are the following:
1) We usually get builds starting correctly with a commit to the various branches outlined above - i.e. a commit to //depot/productA/1/x/... starts Job1. However, i have started to get commits to Job1's branch triggering a totally different job, say Job4. I.e. the SCM polling is identifying changelists as triggers to build a job which did not include changes to any files in the particular branch which is then subsequently build by Jenkins.
2) the second issue is that, despite Job1 and Job2 having identical build scripts, dependencies and settings with the only differences being in the branch out of which they are building, Job1 manages to resolve its dependencies while Job2 cannot and fails. This is confirmed by preparing a diff of config.xml for both jobs, and confirming the only differences are the branches out of which they are drawing the source.
We do not have use any build slaves, and so all builds are run on the master node and am deleting the workspace for each job at the start of each build. I cant tell if this is a configuration problem or a strange bug which has propagated through because the later jobs were produced by cloning the initial setup.
Or perhaps i have misunderstood how the Perforce plugin is designed to work and this is a misconfiguration on our side ... :)
Many thanks for any assistance in advance,
Regards
Jon
We have a number of projects which are building out of Perforce. We trigger the builds using SCM polling, as we dont want to expose a port on the firewall for Perforce to connect into to trigger build on the build server.
Because most of the builds are similar, i have generated a number of the projects by cloning a parent project (which was working correctly) and then changing the most important information, such as the Perforce view etc.
I am using Auto cleanup and Sync to populate the workspace, and the workspace mappings are the following for each of the products:
Job1
//depot/productA/1/x/... //jenkins_ws/...
Job2
//depot/productA/2/x/... //jenkins_ws/...
Job3
//depot/productB/1/x/... //jenkins_ws/...
Job4
//depot/productC/1/x/... //jenkins_ws/...
The strange problems are the following:
1) We usually get builds starting correctly with a commit to the various branches outlined above - i.e. a commit to //depot/productA/1/x/... starts Job1. However, i have started to get commits to Job1's branch triggering a totally different job, say Job4. I.e. the SCM polling is identifying changelists as triggers to build a job which did not include changes to any files in the particular branch which is then subsequently build by Jenkins.
2) the second issue is that, despite Job1 and Job2 having identical build scripts, dependencies and settings with the only differences being in the branch out of which they are building, Job1 manages to resolve its dependencies while Job2 cannot and fails. This is confirmed by preparing a diff of config.xml for both jobs, and confirming the only differences are the branches out of which they are drawing the source.
We do not have use any build slaves, and so all builds are run on the master node and am deleting the workspace for each job at the start of each build. I cant tell if this is a configuration problem or a strange bug which has propagated through because the later jobs were produced by cloning the initial setup.
Or perhaps i have misunderstood how the Perforce plugin is designed to work and this is a misconfiguration on our side ... :)
Many thanks for any assistance in advance,
Regards
Jon
Reply all
Reply to author
Forward
0 new messages