[JIRA] (JENKINS-37462) Polling breaks with multiple slaves with own workspace

42 views
Skip to first unread message

pyssling@ludd.ltu.se (JIRA)

unread,
Aug 17, 2016, 6:40:02 AM8/17/16
to jenkinsc...@googlegroups.com
Nils Carlson created an issue
 
Jenkins / Bug JENKINS-37462
Polling breaks with multiple slaves with own workspace
Issue Type: Bug Bug
Assignee: Unassigned
Components: p4-plugin
Created: 2016/Aug/17 10:39 AM
Environment: Jenkins ver 2.17, p4 plugin 1.4.4
Priority: Major Major
Reporter: Nils Carlson

When using multiple slaves, each with their own perforce workspace, polling appears to be broken causing endless rebuilds.

One slave does the polling, finding changes:

P4 Task: establishing connection.
... server: perforce.somewhere.com:1666
... node: A
P4: Polling with cstat: //

{some-path}/...
... p4 cstat //{some-path}

/... +
... p4 change -o 113712 +
... found change: 113712
... p4 change -o 113686 +
... found change: 113686

Triggering a build on another host:

P4 Task: establishing connection.
... server: perforce.somewhere.com:1666
... node: B

Which already has all the changes!

It seems that the p4-plugin is relying only on the perforce servers knowledge of what the client has to decide if a new build is needed, which breaks if multiple clients are polling/building.

Maybe it would be better to save the last changelist id on the master and only build if a new changelist is found on when querying the server?
Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
Atlassian logo

timothy.fredrickson@seagate.com (JIRA)

unread,
Aug 22, 2016, 12:58:01 PM8/22/16
to jenkinsc...@googlegroups.com
Tim Fredrickson commented on Bug JENKINS-37462
 
Re: Polling breaks with multiple slaves with own workspace

Would be nice to get some eyes on this

pyssling@ludd.ltu.se (JIRA)

unread,
Sep 20, 2016, 6:46:03 AM9/20/16
to jenkinsc...@googlegroups.com
Nils Carlson assigned an issue to Paul Allen
 
Change By: Nils Carlson
Assignee: Paul Allen

pyssling@ludd.ltu.se (JIRA)

unread,
Sep 20, 2016, 6:48:01 AM9/20/16
to jenkinsc...@googlegroups.com
Nils Carlson commented on Bug JENKINS-37462
 
Re: Polling breaks with multiple slaves with own workspace

Hi,

Any chance of getting eyes on this? This is really impairing our use of jenkins with perforce.

pallen@perforce.com (JIRA)

unread,
Sep 21, 2016, 5:16:04 AM9/21/16
to jenkinsc...@googlegroups.com

Polling with cstat is a fall back situation if the P4 plugin was not able to find the last built change. Are you throwing the Perforce workspace away each time? or sharing the Perforce workspace between slaves?

pyssling@ludd.ltu.se (JIRA)

unread,
Sep 21, 2016, 9:32:04 AM9/21/16
to jenkinsc...@googlegroups.com

Hi,

I'm pretty sure we have a dedicated workspace per slave.
I am running a pipeline job, with the following setup:

master polls on the Jenkinsfile in own workspace on node A
slaves build inside the pipeline and do their own polling on node B and C. Node C has been disabled, but I still get unwanted polling.

But looking at the output of the perforce plugin in detail I do see strange things:

------------------------

[Pipeline] stage (Build)
Using the ‘stage’ step without a block argument is deprecated
Entering stage Build
Proceeding
[Pipeline] echo
Bulding <snip>
[Pipeline] node
Still waiting to schedule task
Waiting for next available executor on docker
Running on nodeB in <snip>
[Pipeline] {
[Pipeline] echo

perforce depot path: "<snip>"
perforce view: "jenkins-<job>-nodeB"
perforce view spec: "<snip>"
perforce populate type: "AutoCleanImpl"
[Pipeline] checkout
... p4 client o jenkins<job>-NodeB+
... p4 info +

P4 Task: establishing connection.
... server: <snip>
... node: nodeA
... p4 client o jenkins<job>-nodeB +
... p4 client -i +
... client: jenkins-<job>-nodeB
... p4 client o jenkins<job>-nodeB +
... p4 info +
... p4 counter change +
... p4 changes m1 -ssubmitted //jenkins<job>-nodeB/... +
Building on Node: master
... p4 client o jenkins<job>-nodeB +
... p4 info +

P4 Task: establishing connection.
... server: <snip>
... node: nodeB

P4 Task: reverting all pending and shelved revisions.
... p4 revert <snip> +
... rm [abandoned files]
duration: (3ms)

P4 Task: skipping clean, no options set.
P4 Task: syncing files at change: <snip>
... p4 sync <snip> +
... p4 client -i +
duration: 0m 2s

P4 Task: saving built changes.
... p4 client o jenkins<job>-nodeB +
... p4 info +
... p4 changes m100 //jenkins<job>-nodeB/...<snip> +

------------------------------------------------

Notice that for the same workspace belonging to nodeB the master node, nodeA, establishes a connection during the pipeline.
Could this be causing problems somehow? Is this wanted behavior?

pallen@perforce.com (JIRA)

unread,
Sep 21, 2016, 11:27:01 AM9/21/16
to jenkinsc...@googlegroups.com

Please can you provide the pipeline script. I'd like to know which DSLs you are using to sync the files (checkout scm, p4sync, checkout).

pyssling@ludd.ltu.se (JIRA)

unread,
Sep 21, 2016, 12:48:03 PM9/21/16
to jenkinsc...@googlegroups.com

This is the function I use:

def perforceCheckout(def depotPathStr, def viewName, def forceClean=false) {
def cleanType = 'AutoCleanImpl'
if (forceClean)

{ cleanType = 'ForceCleanImpl' }

p4sync(credential: "p4-read-only",
depotPath: depotPathStr,
poll: true,
populate: [$class: cleanType ])
}

And this is the XML from the defining the Jenkinsfile step for the pipeline:

<definition class="org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition">
<scm class="org.jenkinsci.plugins.p4.PerforceScm">
<credential>p4-read-only</credential>
<workspace class="org.jenkinsci.plugins.p4.workspace.ManualWorkspaceImpl">
<name>job</name>
<spec>
<view>....view....</view>
</spec>
</workspace>
<filter>
<org.jenkinsci.plugins.p4.filters.FilterPathImpl>
<path>//</path>
</org.jenkinsci.plugins.p4.filters.FilterPathImpl>
</filter>
<populate class="org.jenkinsci.plugins.p4.populate.ForceCleanImpl"/>
</scm>
<scriptPath>Jenkinsfile</scriptPath>
</definition>

Changes in the pipeline shouldn't trigger any jobs, therefore the filter.

pyssling@ludd.ltu.se (JIRA)

unread,
Sep 22, 2016, 3:56:01 AM9/22/16
to jenkinsc...@googlegroups.com

I saw this filter now: https://issues.jenkins-ci.org/browse/JENKINS-32814 letting one only poll on the master using the lastBuild. This seems to be what the git plugin is doing normally, would it be possible to do this from a pipeline build? Are there any downsides to this?

hugues.moreau@cgg.com (JIRA)

unread,
Oct 3, 2016, 7:56:07 AM10/3/16
to jenkinsc...@googlegroups.com

Hi, this is a "me too" comment...
My Pipeline build looks like this:

    node('redacted') {
        def mvnHome = tool 'M3'
        stage 'P4 Sync'
        p4sync credential: 'redacted', depotPath: '//redacted'
        stage 'Build'
        sh "${mvnHome}/bin/mvn package install"
    }

If I enable "Poll SCM", builds are triggered every time, because the polling step always finds there are new changes.
So to answer Paul's question from September 21st: in my case I reproduce the issue using "p4sync".

Thanks,
Hugues

pallen@perforce.com (JIRA)

unread,
Oct 3, 2016, 8:14:06 AM10/3/16
to jenkinsc...@googlegroups.com
Paul Allen started work on Bug JENKINS-37462
 
Change By: Paul Allen
Status: Open In Progress

hugues.moreau@cgg.com (JIRA)

unread,
Nov 17, 2016, 4:27:02 AM11/17/16
to jenkinsc...@googlegroups.com

Hi,
any news about this?

I noticed it went to "In Progress" soon after my previous comment – are there fundamental difficulties? (perhaps some difficult-to-resolve discrepancies between Perforce and Jenkins ways?) Or is it not a priority?

Thanks,
Hugues

pallen@perforce.com (JIRA)

unread,
Nov 17, 2016, 5:17:02 AM11/17/16
to jenkinsc...@googlegroups.com

It is a priority and an important job (one of the reasons I moved it out of the backlog). However the issue is complicated and will need some redesign that will work for many different use cases.

The main issue is around storing the changelist number last used by the Job. In the past we used Jenkins Build data, but this could fail for many reasons; then we switched to storing the data in the Client Spec. Unfortunately, the Client Spec gets deleted in some workflow patterns. I need to reproduce your scenario, perhaps I am missing something?

hugues.moreau@cgg.com (JIRA)

unread,
Nov 17, 2016, 5:54:01 AM11/17/16
to jenkinsc...@googlegroups.com

Thanks for sharing this info.
By "I need to reproduce your scenario", do you mean you tried but did not manage to reproduce with the available details?
I shared my Pipeline build details above, but maybe the issue depends on other things?

It's interesting that the critical piece of info is stored in client spec, and that some Pipeline scenarios will delete it: perhaps I can try to trace this? How/where exactly is this stored? If it can help and provide you with details you might be missing... or provide me with enough insight to circumvent the issue.

pallen@perforce.com (JIRA)

unread,
Nov 17, 2016, 6:13:01 AM11/17/16
to jenkinsc...@googlegroups.com

I just haven't had time to setup the slave environment, but do understand the failure mechanism. Simulating slaves in automated tests is not simple in Jenkins. It's going to take me a while to redesign the change storage, but would you be interested in helping me verify the fix?

hugues.moreau@cgg.com (JIRA)

unread,
Nov 17, 2016, 7:31:01 AM11/17/16
to jenkinsc...@googlegroups.com

Sure. For example if you produce a "debug" version of the plugin, I can install it on our Jenkins instance (for now, only our experimental Pipeline projects use your plugin, all other projects use the old plugin by Rob Petti, so if your plugin produces a trace there should be no noise, only the trace of my tests).
I cannot however touch the perforce server (running 2014.1 – if that is not enough I can request an upgrade).

pallen@perforce.com (JIRA)

unread,
Nov 18, 2016, 9:19:04 AM11/18/16
to jenkinsc...@googlegroups.com

I have a working design for tracking changes when polling, but before I submit it and build a SNAPSHOT please will you try the following.

  • Add a polling Filter for 'Poll on Master using Last Build' and set it to 'true'

With the 'checkout' DSL (checkout: General SCM)

filter: [[$class: 'FilterPollMasterImpl', master: true]]

I'm going to Deprecate this behaviour in favour of the new design, but have a feeling the filter might work in your situation.

hugues.moreau@cgg.com (JIRA)

unread,
Nov 18, 2016, 12:01:02 PM11/18/16
to jenkinsc...@googlegroups.com

I'd love to test a workaround!
But I'm afraid I don't know how to use 'checkout' with p4.
Currently I have this:

p4sync credential: 'abcdef1234', depotPath: '//foo/bar/'

Do you mean I should not use p4sync, but checkout instead, and fill in the equivalent parameters, alongside your filter parameter?
Do you have an example?

hugues.moreau@cgg.com (JIRA)

unread,
Nov 18, 2016, 12:02:02 PM11/18/16
to jenkinsc...@googlegroups.com
Hugues Moreau edited a comment on Bug JENKINS-37462
I'd love to test a workaround!
But I'm afraid I don't know how to use 'checkout' with p4.
Currently I have this:
{code}p4sync credential: 'abcdef1234', depotPath: '//foo/bar/'{code}

Do you mean I should not use {{p4sync}}, but {{checkout}} instead, and fill in the equivalent parameters, alongside your filter parameter?
Do you have an example? (or a doc maybe? I had trouble finding any...)

pallen@perforce.com (JIRA)

unread,
Nov 18, 2016, 12:51:01 PM11/18/16
to jenkinsc...@googlegroups.com

You can use the snippet generator 'checkout: General SCM' then 'Perforce Software' from the SCM list. I don't often use StackOverflow, but did answer a similar question:
http://stackoverflow.com/questions/39583602/jenkins-pipeline-syntax-for-p4sync/39623661#39623661

timothy.fredrickson@seagate.com (JIRA)

unread,
Nov 18, 2016, 12:54:02 PM11/18/16
to jenkinsc...@googlegroups.com

Paul, will the fixed behavior be applied to all Jenkins project types? ie perforce plugin in matrix builds?

pallen@perforce.com (JIRA)

unread,
Nov 18, 2016, 12:59:01 PM11/18/16
to jenkinsc...@googlegroups.com

Yes I added the fix to Matrix, but have not explicitly tested it beyond the automated tests.

pallen@perforce.com (JIRA)

unread,
Nov 18, 2016, 1:02:02 PM11/18/16
to jenkinsc...@googlegroups.com

timothy.fredrickson@seagate.com (JIRA)

unread,
Nov 18, 2016, 1:08:02 PM11/18/16
to jenkinsc...@googlegroups.com

I would be willing to test it out on our jenkins setup if you need.

pallen@perforce.com (JIRA)

unread,
Nov 18, 2016, 1:12:02 PM11/18/16
to jenkinsc...@googlegroups.com

If you do try the SNAPSHOT build please don't cleanup your Configuration data under Manage Jenkins. I have deleted the 'Poll on master filter'. If you revert back to the 1.4.9 version after cleanup, you may need to re-add the filter.

hugues.moreau@cgg.com (JIRA)

unread,
Nov 21, 2016, 8:01:11 AM11/21/16
to jenkinsc...@googlegroups.com

Hi Paul, very quickly: it seems to work with "checkout" and the filter you suggested.
I wil have to factorize all that blob of awful configuration in a user-function in our groovy library, but I think that will do, many thanks.
(still happy to test stuff for you if needed)

pallen@perforce.com (JIRA)

unread,
Nov 21, 2016, 8:17:39 AM11/21/16
to jenkinsc...@googlegroups.com

Thanks, that is good news. If you want to try the snapshot, the build 459 link in the earlier post will give you the HPI file (p4-1.4.10-SNAPSHOT.hpi); download it and install the snapshot in Jenkins by using:

Jenkins > Manage Jenkins > Manage Plugins > Advanced (tab) > Upload File > (choose the downloaded HPI) > Upload.

You may need to restart Jenkins to take effect. You can remove it by going to Manage Plugins and downgrading, and restart as required.

pyssling@ludd.ltu.se (JIRA)

unread,
Nov 23, 2016, 8:18:01 AM11/23/16
to jenkinsc...@googlegroups.com

Hi,

I'm trying the latest snapshot now. I seem to be getting even more continuous builds then before.
Plus everything started building at once.

Could you tell me in what file in the workspace the last change is stored? I would be happy to take a look and try to figure out whats going on.

I also get a lot of errors in the output:

watching the Jenkins output I see:

Nov 21 12:40:01 <host> java[726]: at com.perforce.p4java.impl.mapbased.server.Server.handleErrorStr(Server.java:4991)
Nov 21 12:40:01 <host> java[726]: at com.perforce.p4java.impl.mapbased.server.Server.getClient(Server.java:2435)
Nov 21 12:40:01 <host> java[726]: at org.jenkinsci.plugins.p4.client.ClientHelper.clientLogin(ClientHelper.java:92)
Nov 21 12:40:01 <host> java[726]: at org.jenkinsci.plugins.p4.client.ClientHelper.<init>(ClientHelper.java:81)
Nov 21 12:40:01 <host> java[726]: at org.jenkinsci.plugins.p4.tasks.AbstractTask.getConnection(AbstractTask.java:154)
Nov 21 12:40:01 <host> java[726]: at org.jenkinsci.plugins.p4.tasks.AbstractTask.setWorkspace(AbstractTask.java:65)
Nov 21 12:40:01 <host> java[726]: at org.jenkinsci.plugins.p4.PerforceScm.pollWorkspace(PerforceScm.java:359)
Nov 21 12:40:01 <host> java[726]: at org.jenkinsci.plugins.p4.PerforceScm.compareRemoteRevisionWith(PerforceScm.java:311)
Nov 21 12:40:01 <host> java[726]: at org.jenkinsci.plugins.workflow.job.WorkflowJob.poll(WorkflowJob.java:618)
Nov 21 12:40:01 <host> java[726]: at hudson.triggers.SCMTrigger$Runner.runPolling(SCMTrigger.java:563)
Nov 21 12:40:01 <host> java[726]: at hudson.triggers.SCMTrigger$Runner.run(SCMTrigger.java:609)
Nov 21 12:40:01 <host> java[726]: at hudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:119)
Nov 21 12:40:01 <host> java[726]: at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
Nov 21 12:40:01 <host> java[726]: at java.util.concurrent.FutureTask.run(FutureTask.java:266)
Nov 21 12:40:01 <host> java[726]: at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
Nov 21 12:40:01 <host> java[726]: at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
Nov 21 12:40:01 <host> java[726]: at java.lang.Thread.run(Thread.java:745)
Nov 21 12:40:01 <host> java[726]: Nov 21, 2016 12:40:01 PM org.jenkinsci.plugins.p4.client.ClientHelper clientLogin
Nov 21 12:40:01 <host> java[726]: SEVERE: P4: Unable to use Workspace: com.perforce.p4java.exception.RequestException: Error detected at line 53.
Nov 21 12:40:01 <host> java[726]: Syntax error in 'ns/...'.
Nov 21 12:40:01 <host> java[726]: com.perforce.p4java.exception.RequestException: Error detected at line 53.
Nov 21 12:40:01 <host> java[726]: Syntax error in 'ns/...'.
Nov 21 12:40:01 <host> java[726]: at com.perforce.p4java.impl.mapbased.server.Server.handleErrorStr(Server.java:4991)
Nov 21 12:40:01 <host> java[726]: at com.perforce.p4java.impl.mapbased.server.Server.getClient(Server.java:2435)
Nov 21 12:40:01 <host> java[726]: at org.jenkinsci.plugins.p4.client.ClientHelper.clientLogin(ClientHelper.java:92)
Nov 21 12:40:01 <host> java[726]: at org.jenkinsci.plugins.p4.client.ClientHelper.<init>(ClientHelper.java:81)
Nov 21 12:40:01 <host> java[726]: at org.jenkinsci.plugins.p4.tasks.AbstractTask.getConnection(AbstractTask.java:154)
Nov 21 12:40:01 <host> java[726]: at org.jenkinsci.plugins.p4.tasks.AbstractTask.setWorkspace(AbstractTask.java:65)
Nov 21 12:40:01 <host> java[726]: at org.jenkinsci.plugins.p4.PerforceScm.pollWorkspace(PerforceScm.java:359)
Nov 21 12:40:01 <host> java[726]: at org.jenkinsci.plugins.p4.PerforceScm.compareRemoteRevisionWith(PerforceScm.java:311)
Nov 21 12:40:01 <host> java[726]: at org.jenkinsci.plugins.workflow.job.WorkflowJob.poll(WorkflowJob.java:618)
Nov 21 12:40:01 <host> java[726]: at hudson.triggers.SCMTrigger$Runner.runPolling(SCMTrigger.java:563)
Nov 21 12:40:01 <host> java[726]: at hudson.triggers.SCMTrigger$Runner.run(SCMTrigger.java:609)
Nov 21 12:40:01 <host> java[726]: at hudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:119)
Nov 21 12:40:01 <host> java[726]: at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
Nov 21 12:40:01 <host> java[726]: at java.util.concurrent.FutureTask.run(FutureTask.java:266)
Nov 21 12:40:01 <host> java[726]: at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
Nov 21 12:40:01 <host> java[726]: at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
Nov 21 12:40:01 <host> java[726]: at java.lang.Thread.run(Thread.java:745)

And a lot of stuff saying "Error in client specification".

Don't know if they are related though.

/Nils

pallen@perforce.com (JIRA)

unread,
Nov 23, 2016, 8:35:02 AM11/23/16
to jenkinsc...@googlegroups.com

The change used to sync the files is stored in the build.xml file, for example, build '3' on 'myjob':

$

{JENKINS_HOME}

/jobs/myjob/builds/3/build.xml

The error reported looks to be related to an incorrectly configured workspace. Please contact Perforce support if you need help configuring the workspace, or raise a separate JIRA ticket if you think there is a bug.

pallen@perforce.com (JIRA)

unread,
Nov 23, 2016, 8:36:01 AM11/23/16
to jenkinsc...@googlegroups.com
Paul Allen edited a comment on Bug JENKINS-37462
The change used to sync the files is stored in the build.xml file, for example, build '3' on 'myjob': {code}

${JENKINS_HOME}/jobs/myjob/builds/3/build.xml
 {code}
The error reported looks to be related to an incorrectly configured workspace.  Please contact Perforce support if you need help configuring the workspace, or raise a separate JIRA ticket if you think there is a bug.

pallen@perforce.com (JIRA)

unread,
Nov 23, 2016, 11:40:02 AM11/23/16
to jenkinsc...@googlegroups.com
Change By: Paul Allen
Status: In Progress Review

pyssling@ludd.ltu.se (JIRA)

unread,
Nov 23, 2016, 3:58:02 PM11/23/16
to jenkinsc...@googlegroups.com
Nils Carlson commented on Bug JENKINS-37462
 
Re: Polling breaks with multiple slaves with own workspace

Looking at the build.xml files for the individual jobs it looks like the change saved in the build.xml doesn't always correspond to the latest one in the depot under that path.

Maybe something with saving the change number has gone wrong. I will let the builds run for a few hours and see if this stabilizes after a while.

/Nils

pyssling@ludd.ltu.se (JIRA)

unread,
Nov 23, 2016, 4:10:05 PM11/23/16
to jenkinsc...@googlegroups.com
Nils Carlson edited a comment on Bug JENKINS-37462
Looking at the build Ok, figured this out . xml files for the individual

Each of my jobs it looks like has two <change> tags. One from polling the Jenkinsfile, under just that path //<path>/jenkins/Jenkinsfile , one from polling the whole pipeline script, //<path>/... The jenkinsfile change saved is first in the build.xml doesn't always correspond to file, the latest one in from polling from inside the depot under that path jenkinsfile is second . I'm guessing this is where it goes wrong.

Maybe something with saving We could go to polling the change number has gone wrong. I will let whole workspace when getting the builds run for a few hours and see if jenkinsfile, but this stabilizes after a while isn't very efficient, it would be better if the plugin could distinguish between different polling runs .

/Nils

pyssling@ludd.ltu.se (JIRA)

unread,
Nov 23, 2016, 4:32:01 PM11/23/16
to jenkinsc...@googlegroups.com
Nils Carlson edited a comment on Bug JENKINS-37462
Ok, figured this out.

Each of my jobs has two <change> tags. One from polling the Jenkinsfile, under just that path //<path>/jenkins/Jenkinsfile , one from polling the whole pipeline workspace script, //<path>/... The jenkinsfile change is first in the build.xml file, the one from polling from inside the jenkinsfile is second. I'm guessing this is where it goes wrong.

We could go to polling the whole workspace when getting the jenkinsfile, but this isn't very efficient, it would be better if the plugin could distinguish between different polling runs.

/Nils

pyssling@ludd.ltu.se (JIRA)

unread,
Nov 24, 2016, 5:19:03 AM11/24/16
to jenkinsc...@googlegroups.com
Nils Carlson edited a comment on Bug JENKINS-37462
Ok, figured this out.

Each of my jobs has two <change> tags. One from polling the Jenkinsfile, under just that path //<path>/jenkins/Jenkinsfile , one from polling the whole workspace script , //<path>/... The jenkinsfile change is first in the build.xml file, the one from polling from inside the jenkinsfile is second. I'm guessing this is where it goes wrong.


We could go to polling the whole workspace when getting the jenkinsfile, but this isn't very efficient, it would be better if the plugin could distinguish between different polling runs.

/Nils

pyssling@ludd.ltu.se (JIRA)

unread,
Nov 25, 2016, 11:30:01 AM11/25/16
to jenkinsc...@googlegroups.com

Paul Allen Any chance to get eyes on this issue? Or do you recommend simply not polling multiple workspaces within the same pipeline until this is fixed?

pyssling@ludd.ltu.se (JIRA)

unread,
Nov 25, 2016, 11:31:02 AM11/25/16
to jenkinsc...@googlegroups.com
Nils Carlson updated an issue
 
Change By: Nils Carlson
Priority: Major Critical

hugues.moreau@cgg.com (JIRA)

unread,
Nov 25, 2016, 12:25:01 PM11/25/16
to jenkinsc...@googlegroups.com
Hugues Moreau commented on Bug JENKINS-37462
 
Re: Polling breaks with multiple slaves with own workspace

Hi Paul,
finally found a moment to install & test the new p4.hpi: success!
I can use the much simpler p4sync DSL, and polling seems to behave correctly.
Thanks

pallen@perforce.com (JIRA)

unread,
Nov 25, 2016, 2:53:02 PM11/25/16
to jenkinsc...@googlegroups.com

1.4.10 is now released. It fixes some of the issues around polling and slaves, but there are so many different ways workspaces can be setup and distributed around slaves I can't promise I can cover them all.

Poll On Master is no longer required (in fact it has been removed). Polling looks for data on previous builds on the Master before invoking the slaves to run changes on Perforce. In most situations this should be ok, although there are obvious edge conditions on the first build and if a build was aborted or crashed before sync.

Please let me know if the fix works for you... and thank you Hugues for the feedback.

scm_issue_link@java.net (JIRA)

unread,
Dec 5, 2016, 10:48:03 AM12/5/16
to jenkinsc...@googlegroups.com

Code changed in jenkins
User: Paul Allen
Path:
src/main/java/org/jenkinsci/plugins/p4/PerforceScm.java
src/main/java/org/jenkinsci/plugins/p4/build/P4EnvironmentContributor.java
src/main/java/org/jenkinsci/plugins/p4/credentials/P4BaseCredentials.java
src/main/java/org/jenkinsci/plugins/p4/tagging/TagAction.java
src/main/java/org/jenkinsci/plugins/p4/tasks/AbstractTask.java
src/test/java/org/jenkinsci/plugins/p4/client/JenkinsfileTest.java
http://jenkins-ci.org/commit/p4-plugin/ad88e9695891a28332f5e1282698aff18a18f9b7
Log:
Multi client support in Pipeline.

If two or more `p4sync` operations are called in one Pipeline script,
they MUST have different client names. During a build, multiple
entries are added to the build history; on subsequent builds they are
used in the three following situations:

  • Polling: largest change number across all the checkouts is used.
  • Change Summary: last change with the same client name is used.
  • Environment: last change recorded (regardless of client).

Added two test cases to cover basic multi sync build/poll situations.

JENKINS-38401
JENKINS-37462
JENKINS-39652

scm_issue_link@java.net (JIRA)

unread,
Dec 5, 2016, 4:41:01 PM12/5/16
to jenkinsc...@googlegroups.com

Code changed in jenkins
User: Paul Allen
Path:
src/main/java/org/jenkinsci/plugins/p4/PerforceScm.java

src/main/java/org/jenkinsci/plugins/p4/tagging/TagAction.java
src/main/java/org/jenkinsci/plugins/p4/tasks/AbstractTask.java
src/test/java/org/jenkinsci/plugins/p4/client/JenkinsfileTest.java
http://jenkins-ci.org/commit/p4-plugin/fb5235393d8b2a1e44271429876b4910defe2463
Log:
Polling fix for Multi client support in Pipeline.

Jenkins polls for each SCM checkout, so must poll each workplace and
therefore need to lookup last build information for each sync.
Polling now uses same lookup as Change Summary.

Added extra test cases multi sync poll and poll again.

JENKINS-38401
JENKINS-37462
JENKINS-39652

pallen@perforce.com (JIRA)

unread,
Dec 9, 2016, 9:46:04 AM12/9/16
to jenkinsc...@googlegroups.com
 

Ready for release
Change By: Paul Allen
Status: In Review Resolved
Resolution: Fixed

pallen@perforce.com (JIRA)

unread,
Dec 9, 2016, 10:18:03 AM12/9/16
to jenkinsc...@googlegroups.com
Paul Allen closed an issue as Fixed
 

Released in 1.4.11
Change By: Paul Allen
Status: Resolved Closed
Reply all
Reply to author
Forward
0 new messages