Changelog information for files are relative to depot path, not workspace path.

Details

Description

Currently the perforce plugin supplies changelog information who's list of files are depot paths, not workspace-relative paths. This should be changed so that ChangeSet.Entry.getAffectedPaths() returns a list of paths relative to the workspace root. Currently, this is preventing incremental maven builds from working correctly.

Activity

Rob, I'm willing to try to fix this issue because I need JENKINS-7619 fixed. I've been looking through the code and wondering if I were to add the workspace root in the depot (e.g. //Depot/foo/bar) to the Changelist bean, I could then adjust the file path in the changelog.xml by removing this workspace root from its path. Effectively replacing the current file path of "//Depot/foo/bar/project/module/src/blah/File.java" with "project/module/src/blah/File.java".

I could also output the workspace root in the depot to the changelog.xml just in case someone needed to reconstruct the file path within the depot.

Tim Drury
added a comment - 2011-06-22 14:24 Rob, I'm willing to try to fix this issue because I need JENKINS-7619 fixed. I've been looking through the code and wondering if I were to add the workspace root in the depot (e.g. //Depot/foo/bar) to the Changelist bean, I could then adjust the file path in the changelog.xml by removing this workspace root from its path. Effectively replacing the current file path of "//Depot/foo/bar/project/module/src/blah/File.java" with "project/module/src/blah/File.java".
I could also output the workspace root in the depot to the changelog.xml just in case someone needed to reconstruct the file path within the depot.
What do you think?

It becomes significantly more complicated, since it's not a 1-1 mapping between the depot and the workspace. Perforce has a built in function to deal with this sort of thing called 'p4 where' that shows how a particular file gets mapped through the view:

Here it shows the depot path, the workspace path, and the path of the file on disk. The only problems here are that the values are space delimited, making it difficult to parse reliably, and the command needs to be run for every file in the changelist.

There are two ways to get around the parsing issue. The first is that you know what two of the delimiters are from the get go: In this case '//rpetti' which is just the name of the workspace and '/home/rpetti/workspace' which is the workspace root. You could hypothetically use those values to reliably parse the output.

The other is to ask perforce to output the results as a marshalled python dictionary (using 'p4 -G where'). The problem is that I haven't been able to find a java library for parsing these, so you might have to write one.

So ideally, when the plugin finishes grabbing a changelist description, it will proceed with finding the mapping of every file in the changeset by running 'p4 where'. It will then dump this information into a new field in the FileEntry class. The getAffectedPaths() function would just need to be changed to reference that new field instead of the depot path.

If this is too much, then I can take another look at it maybe this week or next week? I admit that I've been putting this one off since it didn't seem all that critical at the time.

Rob Petti
added a comment - 2011-06-22 15:34 I think that will only work in the simplest case. Consider the following view:
//depot/product/a/... //workspace/a/...
//depot2/vendor/... //workspace/a/vendor/...
//depot/product/%1/depends/... //workspace/a/depends/%1/...
+ //depot/product/branch/feature/... //workspace/a/...
It becomes significantly more complicated, since it's not a 1-1 mapping between the depot and the workspace. Perforce has a built in function to deal with this sort of thing called 'p4 where' that shows how a particular file gets mapped through the view:
rpetti@petti:~/workspace/Install/trunk/Installers$ p4 where build.properties //Install/trunk/Installers/build.properties //rpetti/Install/trunk/Installers/build.properties /home/rpetti/workspace/Install/trunk/Installers/build.properties
Here it shows the depot path, the workspace path, and the path of the file on disk. The only problems here are that the values are space delimited, making it difficult to parse reliably, and the command needs to be run for every file in the changelist.
There are two ways to get around the parsing issue. The first is that you know what two of the delimiters are from the get go: In this case '//rpetti' which is just the name of the workspace and '/home/rpetti/workspace' which is the workspace root. You could hypothetically use those values to reliably parse the output.
The other is to ask perforce to output the results as a marshalled python dictionary (using 'p4 -G where'). The problem is that I haven't been able to find a java library for parsing these, so you might have to write one.
So ideally, when the plugin finishes grabbing a changelist description, it will proceed with finding the mapping of every file in the changeset by running 'p4 where'. It will then dump this information into a new field in the FileEntry class. The getAffectedPaths() function would just need to be changed to reference that new field instead of the depot path.
If this is too much, then I can take another look at it maybe this week or next week? I admit that I've been putting this one off since it didn't seem all that critical at the time.

Tim Drury
added a comment - 2011-06-22 16:13 It's true I hadn't considered more complex mappings since all our projects typically don't require anything more than a single mapping.
Have you used the Perforce Java API ( http://www.perforce.com/perforce/doc.091/manuals/p4java-javadoc/index.html ), specifically P4JFileSpec? I wonder if it can be used to get the correct file path within the workspace?

Rob Petti
added a comment - 2011-06-22 19:38 Tim, did you want to try testing the latest snapshot? http://files.robpetti.com/perforce-plugin/target/perforce.hpi The build log might be a little noisy right now, but it should be resolving the workspace paths for the affected files correctly now.

ERROR: Processing failed due to a bug in the code. Please report this to jenkinsci-users@googlegroups.com
java.lang.NullPointerException
at hudson.maven.MavenModuleSetBuild$1.isDescendantOf(MavenModuleSetBuild.java:244)
at hudson.maven.MavenModuleSetBuild$1.<init>(MavenModuleSetBuild.java:213)
at hudson.maven.MavenModuleSetBuild.getChangeSetFor(MavenModuleSetBuild.java:207)
at hudson.maven.MavenModuleSetBuild$RunnerImpl.doRun(MavenModuleSetBuild.java:633)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:430)
at hudson.model.Run.run(Run.java:1376)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:466)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:175)

Tim Drury
added a comment - 2011-06-22 20:03 It failed for me:
ERROR: Processing failed due to a bug in the code. Please report this to jenkinsci-users@googlegroups.com
java.lang.NullPointerException
at hudson.maven.MavenModuleSetBuild$1.isDescendantOf(MavenModuleSetBuild.java:244)
at hudson.maven.MavenModuleSetBuild$1.<init>(MavenModuleSetBuild.java:213)
at hudson.maven.MavenModuleSetBuild.getChangeSetFor(MavenModuleSetBuild.java:207)
at hudson.maven.MavenModuleSetBuild$RunnerImpl.doRun(MavenModuleSetBuild.java:633)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:430)
at hudson.model.Run.run(Run.java:1376)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:466)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:175)

I'm running 1.419-SNAPSHOT (I just built it yesterday from git to debug this issue).

I was stepping through your code and in the 'change' object the workspacePath looks good (modules/foo/impl/....) but the filename (//Common/maventest/main/maventest/modules/foo/impl/....) is still being written to changelog.xml. Is that the correct behavior?

Tim Drury
added a comment - 2011-06-22 20:22 I'm running 1.419-SNAPSHOT (I just built it yesterday from git to debug this issue).
I was stepping through your code and in the 'change' object the workspacePath looks good (modules/foo/impl/....) but the filename (//Common/maventest/main/maventest/modules/foo/impl/....) is still being written to changelog.xml. Is that the correct behavior?

Yes, the depot path is still being used by SCM Browser integration, so we need to store both. getAffectedPaths will return the workspacePaths, however. I suspect that the maven plugin may be reading old changesets in order to determine what needs to be rebuilt, in which case the perforce plugin will return null for the affected paths. I've changed the code to provide the workspace path only when it's available. If you've got the time, you can test using the latest snapshot (same link as before).

Rob Petti
added a comment - 2011-06-22 20:31 Yes, the depot path is still being used by SCM Browser integration, so we need to store both. getAffectedPaths will return the workspacePaths, however. I suspect that the maven plugin may be reading old changesets in order to determine what needs to be rebuilt, in which case the perforce plugin will return null for the affected paths. I've changed the code to provide the workspace path only when it's available. If you've got the time, you can test using the latest snapshot (same link as before).
Hopefully that will fix it.

That change eliminated the NPE, but it still triggered a full build of project despite correctly identifying the one changed file. "com.saptest:maventest" is the top POM of the project. I thought it would build just the changed foo.impl module, then the EAR that depends on foo.impl.

and the build page shows only the foo.impl, EAR (depends on foo.impl), and SCA (depends on EAR) being built. I will try it tomorrow on our production Jenkins system which has much, much larger projects on it (which is why this feature is so critical).

Tim Drury
added a comment - 2011-06-22 21:25 Yes! That worked:
Executing Maven: -B -f D:\java\jenkins-src\war\work\jobs\maventest-main\workspace\pom.xml -amd -pl com.saptest:maventest.foo.impl -X -P maventest,netweaver-71 clean install
and the build page shows only the foo.impl, EAR (depends on foo.impl), and SCA (depends on EAR) being built. I will try it tomorrow on our production Jenkins system which has much, much larger projects on it (which is why this feature is so critical).
Many thanks for your work, Rob.

Let me know if you run into any more issues. I'll close this ticket and it's dependent once I clean up the build log output a bit. It'll currently show a line for every file in every changeset that's being pulled down, which can get long depending on project activity.

Rob Petti
added a comment - 2011-06-22 23:18 Thanks for testing it.
Let me know if you run into any more issues. I'll close this ticket and it's dependent once I clean up the build log output a bit. It'll currently show a line for every file in every changeset that's being pulled down, which can get long depending on project activity.

java.lang.NullPointerException
at hudson.plugins.perforce.PerforceSCMHelper.parseWhereMapping(PerforceSCMHelper.java:133)
at com.tek42.perforce.parse.Changes.calculateWorkspacePaths(Changes.java:78)
at com.tek42.perforce.parse.Changes.getChangelist(Changes.java:67)
at com.tek42.perforce.parse.Changes.getChangelistsFromNumbers(Changes.java:403)
at hudson.plugins.perforce.PerforceSCM.checkout(PerforceSCM.java:628)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1182)
at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:537)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:425)
at hudson.model.Run.run(Run.java:1376)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:465)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:146)

Tim Drury
added a comment - 2011-06-23 19:01 After working all morning, I just got this NPE:
java.lang.NullPointerException
at hudson.plugins.perforce.PerforceSCMHelper.parseWhereMapping(PerforceSCMHelper.java:133)
at com.tek42.perforce.parse.Changes.calculateWorkspacePaths(Changes.java:78)
at com.tek42.perforce.parse.Changes.getChangelist(Changes.java:67)
at com.tek42.perforce.parse.Changes.getChangelistsFromNumbers(Changes.java:403)
at hudson.plugins.perforce.PerforceSCM.checkout(PerforceSCM.java:628)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1182)
at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:537)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:425)
at hudson.model.Run.run(Run.java:1376)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:465)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:146)

Tim Drury
added a comment - 2011-06-23 22:05 It appears that readInt() is not handling the bytes as unsigned bytes. At one point, the 4 size bytes are -106,0,0,0 and this is being interpreted as a size of -106.

The conversion of the P4 response StringBuffer to bytes via .toBytes() is producing bad results. For one file, the path length is 143 which shows up in the StringBuffer as an unknown character (at least to Eclipse - it prints a solid diamond with a white '?' inside). When converted to a byte[], the value is 63d which is clearly wrong and it throws the parser off. I tried .toBytes(Charset.forName("UTF8")) as a wild guess and really fouled things up. I haven't dealt with String-to-byte parsing in Java; this was always much easier in C. I'll get it eventually, but was hoping you might have some insight to speed up the process...

Tim Drury
added a comment - 2011-06-24 16:01 The conversion of the P4 response StringBuffer to bytes via .toBytes() is producing bad results. For one file, the path length is 143 which shows up in the StringBuffer as an unknown character (at least to Eclipse - it prints a solid diamond with a white '?' inside). When converted to a byte[], the value is 63d which is clearly wrong and it throws the parser off. I tried .toBytes(Charset.forName("UTF8")) as a wild guess and really fouled things up. I haven't dealt with String-to-byte parsing in Java; this was always much easier in C. I'll get it eventually, but was hoping you might have some insight to speed up the process...

I think that change should fix it. It now pulls the data from the pipe as a byte array, so it never converts it into a string in the first place. The snapshot has been updated if you want to test again. I really appreciate all of your patience and help with this!

Rob Petti
added a comment - 2011-06-24 17:17 I think that change should fix it. It now pulls the data from the pipe as a byte array, so it never converts it into a string in the first place. The snapshot has been updated if you want to test again. I really appreciate all of your patience and help with this!

Still not fixed. Same issue. The output of "where -G" produces a set of length bytes of „,0,0,0 (not sure if that first one will paste) which, according to this table (http://doc.infosnel.nl/extreme_utf-8.html), is 132,0,0,0. But when I look at "bytes" in getRawPerforceResponseBytes, there's 30d instead of 132d. Is this an encoding issue? Our Perforce charset is set to utf8.

Tim Drury
added a comment - 2011-06-24 18:01 Still not fixed. Same issue. The output of "where -G" produces a set of length bytes of „,0,0,0 (not sure if that first one will paste) which, according to this table ( http://doc.infosnel.nl/extreme_utf-8.html ), is 132,0,0,0. But when I look at "bytes" in getRawPerforceResponseBytes, there's 30d instead of 132d. Is this an encoding issue? Our Perforce charset is set to utf8.

Tim Drury
added a comment - 2011-06-24 18:31 - edited I'm thinking that CmdLineExecutor.exec() needs to instantiate the reader with a charset encoding. Ideally it would be from the P4CHARSET variable returned by "p4 set".
UPDATE: I forced the creation of the InputStreamReader to use UTF8 and it made no difference in the output. I can't understand how this issue can be so difficult.

CmdLineExecutor isn't used, and it doesn't make sense to have any character encoding at all. It's pure binary data, which is why I'm attempting to read it as raw bytes. It looks like the readers used by the jenkins remoting api are what's at fault here, since they do the encoding.

Rob Petti
added a comment - 2011-06-24 20:01 CmdLineExecutor isn't used, and it doesn't make sense to have any character encoding at all. It's pure binary data, which is why I'm attempting to read it as raw bytes. It looks like the readers used by the jenkins remoting api are what's at fault here, since they do the encoding.

Tim Drury
added a comment - 2011-06-24 20:25 Well that makes a difference then. After setting a few breakpoints, I found that it's using HudsonP4DefaultExecutor and by hardcoding the reader to instantiate the input stream via UTF8 encoding:
reader = new BufferedReader(new InputStreamReader(p4in, "UTF8"));
I got the byte array to read the size in as -3 which still screws up the parser and, well, I have no idea how that's supposed to be 132d....

It wasn't sure if my changes were mixing in with your stuff and I don't really know how to use git yet, so I blew it all away and recloned. This is what I'm getting now - did I get the right branch of code?

[workspace] $ "c:\Program Files\Perforce\p4.exe" -G where //VM/Base/main/modules/legacy/api/src/main/java/com/sap/me/production/CheckConfigInterface.java
FATAL: Not supported yet.
java.lang.UnsupportedOperationException: Not supported yet.
at hudson.plugins.perforce.HudsonP4DefaultExecutor.getInputStream(HudsonP4DefaultExecutor.java:138)
at com.tek42.perforce.parse.AbstractPerforceTemplate.getRawPerforceResponseBytes(AbstractPerforceTemplate.java:496)
at com.tek42.perforce.parse.Changes.calculateWorkspacePaths(Changes.java:77)
at com.tek42.perforce.parse.Changes.getChangelist(Changes.java:67)
at com.tek42.perforce.parse.Changes.getChangelistsFromNumbers(Changes.java:403)
at hudson.plugins.perforce.PerforceSCM.checkout(PerforceSCM.java:628)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1184)
at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:537)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:425)
at hudson.model.Run.run(Run.java:1376)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:466)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:175)

Tim Drury
added a comment - 2011-06-24 21:34 It wasn't sure if my changes were mixing in with your stuff and I don't really know how to use git yet, so I blew it all away and recloned. This is what I'm getting now - did I get the right branch of code?
[workspace] $ "c:\Program Files\Perforce\p4.exe" -G where //VM/Base/main/modules/legacy/api/src/main/java/com/sap/me/production/CheckConfigInterface.java
FATAL: Not supported yet.
java.lang.UnsupportedOperationException: Not supported yet.
at hudson.plugins.perforce.HudsonP4DefaultExecutor.getInputStream(HudsonP4DefaultExecutor.java:138)
at com.tek42.perforce.parse.AbstractPerforceTemplate.getRawPerforceResponseBytes(AbstractPerforceTemplate.java:496)
at com.tek42.perforce.parse.Changes.calculateWorkspacePaths(Changes.java:77)
at com.tek42.perforce.parse.Changes.getChangelist(Changes.java:67)
at com.tek42.perforce.parse.Changes.getChangelistsFromNumbers(Changes.java:403)
at hudson.plugins.perforce.PerforceSCM.checkout(PerforceSCM.java:628)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1184)
at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:537)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:425)
at hudson.model.Run.run(Run.java:1376)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:466)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:175)

Sorry, I'm not sure what I'm looking at here. I don't see any parsing errors... Can you check the changelog.xml file for that build and make sure workspacePath is correct? If it is, then I would suspect something is wrong with either the maven plugin, or your maven project itself.

Rob Petti
added a comment - 2011-06-28 19:49 Sorry, I'm not sure what I'm looking at here. I don't see any parsing errors... Can you check the changelog.xml file for that build and make sure workspacePath is correct? If it is, then I would suspect something is wrong with either the maven plugin, or your maven project itself.

Rob Petti
added a comment - 2011-06-28 20:06 Are those the only 4 projects? Maybe it's just building everything like it was before. If not, could test and nlp depend on test-data and nlp-data respectively?

Nope, there are 35 projects total, so it is very close to doing the right thing. I thought how this code worked was to parse the submitted changelists for the build and determine the affected modules. Then add -pl switch with the affected modules and -amd will take care of their dependents.

swolk
added a comment - 2011-06-28 20:23 Nope, there are 35 projects total, so it is very close to doing the right thing. I thought how this code worked was to parse the submitted changelists for the build and determine the affected modules. Then add -pl switch with the affected modules and -amd will take care of their dependents.
I did inspect the changelog.xml and workspacePath looks correct.
I ran dependency:tree on these two modules:
[INFO] com.netbase:nlp-data:jar:5.3-SNAPSHOT
[INFO] +- junit:junit:jar:4.8.2:test
[INFO] \- findbugs:findbugs:jar:1.3.9:compile
[INFO] com.netbase:test-data:jar:5.3-SNAPSHOT
[INFO] +- junit:junit:jar:4.8.2:test
[INFO] \- findbugs:findbugs:jar:1.3.9:compile

On the very next build, changes were made to the exact same two projects, yet the -pl switch is completely different from the previous run (-pl com.netbase:consumerbase,com.netbase:elsevier-prospero,com.netbase:engine,com.netbase:megatron,com.netbase:nldemo,com.netbase:nlp,com.netbase:nlp-data,com.netbase:ovid,com.netbase:prospero,com.netbase:test,com.netbase:test-data):

Ok, this looks to be user error, sorry! I noticed that this is happening on an unstable build, and previous to the first incremental build, the nlp had failed test cases. Then on the next run, those other projects had failed test cases. So it looks like the incremental build does include previous failing projects. I'm still unclear as to why the test project gets added since it didn't have code changes and it didn't fail...

swolk
added a comment - 2011-06-28 20:39 Ok, this looks to be user error, sorry! I noticed that this is happening on an unstable build, and previous to the first incremental build, the nlp had failed test cases. Then on the next run, those other projects had failed test cases. So it looks like the incremental build does include previous failing projects. I'm still unclear as to why the test project gets added since it didn't have code changes and it didn't fail...

In Jenkins, projects with status of anything less than "SUCCESS" are added into the list for the -pl argument. We have the same issue because unit tests are failing on several modules so they continue to be built even though nothing has changed within them. I don't agree with this strategy - after all how is a test supposed to succeed if nothing has changed? However, that issue doesn't belong here.

Tim Drury
added a comment - 2011-06-28 20:47 In Jenkins, projects with status of anything less than "SUCCESS" are added into the list for the -pl argument. We have the same issue because unit tests are failing on several modules so they continue to be built even though nothing has changed within them. I don't agree with this strategy - after all how is a test supposed to succeed if nothing has changed? However, that issue doesn't belong here.

I do not believe this is fixed. Below is what I am seeing on Jenkins 1.419 with perforce plugin 1.2.8.

The fallout from getting into this state is that the job get's queued every SCM polling period, fails, and sends out failure notification, every minute, for eternity. Downgrading to perforce plugin 1.2.7 made this go away for me.

Rob, I got another NPE the afternoon before going on a 1 week vacation, so I didn't capture the -G output and we reverted back to the release plugin. I'll update the plugin source, rebuild and deploy and if any new NPEs occur, I'll send you the output via gmail. BTW, I have Google+ invites if you're interested...

Tim Drury
added a comment - 2011-07-11 13:56 Rob, I got another NPE the afternoon before going on a 1 week vacation, so I didn't capture the -G output and we reverted back to the release plugin. I'll update the plugin source, rebuild and deploy and if any new NPEs occur, I'll send you the output via gmail. BTW, I have Google+ invites if you're interested...

I really need that output, or else I can't figure out what the problem is. Since you know you got an NPE, I'm assuming you still have the log? Can't you just run the command it failed on and attach the output? BTW, this functionality was released with 1.2.8, so you don't need to build from source.

Rob Petti
added a comment - 2011-07-11 14:09 I really need that output, or else I can't figure out what the problem is. Since you know you got an NPE, I'm assuming you still have the log? Can't you just run the command it failed on and attach the output? BTW, this functionality was released with 1.2.8, so you don't need to build from source.
Thanks for the G+ offer, but I've already got one.

swolk
added a comment - 2011-07-11 18:04 Rob, I got this same issue yesterday. Turned out the issue was caused by a changelist that had 1 file that was not in my workspace view. Not sure if that is the same issue here.

I've added a retry in the event that the data gets corrupted for some reason, which I think should solve Scott's issue. It should also now correctly handle files that are not in the client-workspace. You can grab the snapshot with these changes here: http://files.robpetti.com/perforce-plugin/target/perforce.hpi

Rob Petti
added a comment - 2011-07-12 15:57 I've added a retry in the event that the data gets corrupted for some reason, which I think should solve Scott's issue. It should also now correctly handle files that are not in the client-workspace. You can grab the snapshot with these changes here: http://files.robpetti.com/perforce-plugin/target/perforce.hpi

I'll gladly grab the snapshot and give it a try as we are still see this issue y intermittently on perforce plugin 1.2.8 ( never on 1.2.7) That said, I have to plead jenkins newbie. What do I do with the perforce.hpi file?

Scott MacDonald
added a comment - 2011-07-13 15:23 I'll gladly grab the snapshot and give it a try as we are still see this issue y intermittently on perforce plugin 1.2.8 ( never on 1.2.7) That said, I have to plead jenkins newbie. What do I do with the perforce.hpi file?

After I go to http://<yourJenkinsServer>/pluginManager/advanced. browse to the perforce.hpi, and select upload, jenkins then shows me the "update center" showing me that I have 1.2.7 installed and that there is a 1.2.8 update available. How do I know if I'm running the snapshot version with the fix? Is the snapshot version 1.2.7 and is that act of uploading it, sufficient to expect that I'm now running that snapshot version? (we never saw this issue on 1.2.7 so I just want to be sure I'm actually running the snapshot with the fix)

Scott MacDonald
added a comment - 2011-07-13 15:36 After I go to http://<yourJenkinsServer>/pluginManager/advanced. browse to the perforce.hpi, and select upload, jenkins then shows me the "update center" showing me that I have 1.2.7 installed and that there is a 1.2.8 update available. How do I know if I'm running the snapshot version with the fix? Is the snapshot version 1.2.7 and is that act of uploading it, sufficient to expect that I'm now running that snapshot version? (we never saw this issue on 1.2.7 so I just want to be sure I'm actually running the snapshot with the fix)