Skip to end of metadata
Go to start of metadata

Summary

Integrates Jenkins with Perforce SCM Repositories.

View Perforce Plugin on the plugin site for more information.

This plugin is very old and not very well maintained anymore. It's recommended that you use the official plugin from Perforce instead: P4 Plugin

With this plugin you can use a workspace (aka Clientspec in Perforce speak) that will synchronize files to the Jenkins workspace. At the moment, this plugin supports:

  • Polling
  • Synchronizing
  • Browsing latest changes
  • Labeling builds (tagging)

If polling is enabled, the plugin will automatically sync to the latest revision when new changelists are found. This will also trigger a new build. Also, whenever a new build is triggered manually in Jenkins, the plugin will sync to the latest revision in the Perforce depot.

Requirements

The plugin requires that the command line client p4 is installed on the machine running Jenkins.

Usage

  1. Allow the plugin to communicate with Perforce...
    1. Either create a new user or use an existing "daemon" type user
      • Note: This "daemon" user must be logged in prior to configuring or running builds with Jenkins. And you must not specify the P4CLIENT environment variable because this will overwrite anything that Jenkins is trying to do.
    2. Create a workspace (clientspec) for the plugin to use. Name it "jenkins-jobname" or something.
    3. Ensure that the workspace matches your development settings for your project (e.g., LineEnd, Options, etc.)
    4. Important Note: If you will be concurrently building multiple projects from Perforce, it would be best to create a Perforce workspace for each project.
  2. Install the plugin. Download it here.
  3. Create a new project, under "Source Code Management," choose Perforce.
  4. Enter your server specific details along with the information for the user that Jenkins will be using for polling/syncing. If you are familiar with Perforce, this all should be second nature. Remember, click on the question mark icons for context sensitive help.
  5. Under Build Triggers, check "Poll SCM."
  6. Save your changes and let Jenkins do its job.

Post Configuration

A new option will appear on your project's details page: "Perforce Polling Log." You can check this to see what Perforce has been up to...

Within any build for your project, a new option appears: "Label This Build." Click on this to see the following screen. Here you can create a Perforce Label allowing your team to sync to this build.

Quirks

  • If Jenkins's copy of the project is modified outside of Perforce (say a user deletes the entire project within the workspace directory), the builds following will likely fail. This is because the local copy is out of sync with what is in the depot. Perforce tracks what you have sync'd via the workspace and the way to bring down files that you deleted "accidentally" is to do a "force" sync. If this happens, you can use the option "One Time Force Sync" in the project configuration screen. The next time a build is triggered, p4 sync will be run with the -f option.
  • Perforce has specific issues when projects within a depot exist in different local locations that don't map directly to the depot. This is precisely how Jenkins operates. To get around this requirement, we have to do some non-standard things. Every build will grab the Perforce workspace and then modify it to suit the needs of the current Jenkins project. It then syncs the projects files and performs the build. This means that no two projects utilizing the same Perforce workspace should be built at the same time. It is unknown what will happen if you are synchronizing with one build, but another build attempts to modify the same Perforce workspace. It will probably be Not Good(tm). If builds must be performed concurrently, multiple workspaces can be used to get around this.

Advanced Configuration

Sync multiple builds to the same changeset


Say you have a stream of builds that need to run and you need every build to sync to the same changeset. There are a couple of ways to accomplish this. The first is to use a counter. In your job configuration for Job A, you will need to define a P4 Counter (say "projectA-counter") and check "Update counter to most recent changeset". Assuming your perforce user has sufficient privileges to create and set counters, this will check out Job A with the latest changeset, and update the counter with that changeset number. Then you can configure the rest of the jobs to use the counter "projectA-counter" and they will automatically sync to that changeset.

The alternative way is to pass the changeset through the builds as a parameter using the parameterized trigger plugin. In order to do this, you will need to dump the changeset number from the build environment into a properties file so the trigger can read it. A build step with

echo p4.changelist=$P4_CHANGELIST > change.properties

will create the properties file that can be loaded with the parameterized trigger plugin. After that it's just a matter of adding the 'p4.changelist' parameter to the downstream job, and using it in the "P4 Label" configuration field of the perforce plugin.

Note that with both these techniques, the changelog information for the downstream builds will not be available.

Other notes

  • Please file all bugs/feature requests in the Jenkins bugtracker: http://issues.jenkins-ci.org/
  • If you have a question or need troubleshooting, please address the jenkins-user mailing list or the Jenkins irc channel. If you fail to get a response, you may contact rpetti directly via email.

Version 1.3.8 "Create Workspace" breakage


In version 1.3.8 a new option was introduced to allow users the ability to disable automatic creation of clients. Unfortunately, the default for pre-existing jobs was not being correctly set. All existing jobs have this option set to false, which can cause build errors in dynamic environments.

If this has happened, and you want to set all jobs back to their original behavior, you can run the following groovy script in the jenkins script console:

hudson.model.Hudson.instance.projects.each{proj ->
  if(proj.scm instanceof hudson.plugins.perforce.PerforceSCM){
    proj.scm.setCreateWorkspace(true);
  }
};

Note that if you went from <=1.3.7 to >=1.3.9, this issue will not affect you.

Version History

Version 1.3.36 - (Feb 11, 2016)

  • Bug fix: p4 login issue when tickets valid on every host is disallowed by the perforce server (JENKINS-28367)

Version 1.3.35 - (June 5, 2015)

  • Bug fix: failing to report error when the client returns 'Request too large'
  • Bug fix: p4 login issue when tickets valid on every host is disallowed by the perforce server (JENKINS-28367)

Version 1.3.34 - (Feb 2, 2015)

  • Bug fix: Concurrency issue in ChangeSet Buikder's parseDateWithTimezone() method (JENKINS-26839, since 1.3.31)
  • Bug fix: Properly propagate InterruptedException during the hostname calculation
  • Improvement: Decrease the log level of "Cannot find the "hostname" method

Version 1.3.33 - (Dec 30, 2014)

  • Bug fix: Escape special symbols in JOB_NAME variable (JENKINS-26119)
  • Bug fix: NullPointerException if global user/password fields are empty (JENKINS-26076)

Version 1.3.32 - Skipped due to the release process issues

Version 1.3.31 - (Dec 10, 2014)

  • New feature: Added the support of global credentials (PR #57)
  • Bug fix: Substitute build environment variables with a high priority to avoid the usage of default values (JENKINS-25559)
  • Bug fix: Don't fail with NPE if an external plugins injects null environment variable (JENKINS-25732)
  • Bux fix: Take server timezone offset into account when displaying change date (JENKINS-24401)
  • Minor fixes of possible NPEs in the code

Version 1.3.30 - Skipped due to the release process issues

Version 1.3.29 - (Nov 01, 2014)

  • Bug fix: Wrong variable substitution order of build parameters: default value is used instead of actual one (JENKINS-25226)
  • Bug fix: No variable substitution in multi-line strings (JENKINS-25365)

Version 1.3.28 - (Oct 10, 2014)

  • New feature: Support of commit info retrieval by Email-ext plugin (JENKINS-11600)
  • Enhancement: New variables substitution engine (JENKINS-23467)
  • Bug fix: Proper variables substitution order in effective client name resolution
  • Bug fix: View mask and clean can get stuck in an enabled state (JENKINS-19649)
  • Bug fix: Cannot check out folders whose path contains two matching brackets and a dash between them (JENKINS-21609)

    Warning!

    The version is not available via Jenkins update center. It also contains several major regressions caused by a new variables handling JENKINS-23467. Use the version at your own risk

Version 1.3.27 - (Jan 10, 2014)

  • Bug fix: refactoring to fix multiple SCM issues (JENKINS-18583)
  • Minor change: Always display at least one change in the changelog when building an older changeset
  • Enhancement: Added the ability to build changesets sequentially (JENKINS-17889)
  • Enhancement: Administrators can now globally disable password exposure

Version 1.3.26 - (Oct 09, 2013)

  • Bug fix: properly escape xml in changelogs (JENKINS-19548)
  • Bug fix: support overridable numbered workspace separator for concurrent workspaces (JENKINS-19519)
  • Bug fix: Improved MacroStringHelper in order to avoid substitution errors and improve performance (JENKINS-19557)
  • Major bug fix: fixed issue with new timeout code causing truncated p4 output

Version 1.3.25 - (Sep 09, 2013)

  • Enhancement: Check for correct variables substitution in SCM operations (checkout, poll, workspace cleanup) (JENKINS-18346)
  • Enhancement: View mask for changelog is now a separate option (JENKINS-9342)
  • Enhancement: Regex-based naming policy for Perforce client (JENKINS-18378)
  • Major bug fix: added timeout for perforce operations (JENKINS-15315)
  • Bug fix: fixed typo in charset help path (JENKINS-18783)
  • Bug fix: fixed build issue caused by java version

Version 1.3.24 - (May 17, 2013)

Version 1.3.23 - (May 16, 2013)

  • adding a warning if a file still exists after being quick cleaned (JENKINS-17439)
  • removing 'disable sync and changelog' and adding 'disable changelog' (JENKINS-16120)
  • reimplemented changelog deserialization to maintain compatibility with Hudson 3.

Version 1.3.22 - (Apr 29, 2013)

  • making improvements and fixes to exclude paths functionality (JENKINS-17652)

Version 1.3.21 - (Apr 12, 2013)

  • added more output when getting submitted changenumbers fails
  • fixed potential NPE when syncing

Version 1.3.20 - (Mar 12, 2013)

  • added SSL support

Version 1.3.19 - (Jan 10, 2013)

  • fixing issue with ticket parsing when perforce server is using login triggers that generate extra output (JENKINS-15994)

Version 1.3.18 - (Nov 28, 2012)

  • added P4USER as valid substitution during polling (JENKINS-14787)
  • fixing issue when retrying a login using tickets
  • 'status' field in job descriptions now optional (JENKINS-15043)
  • added general substitution support for P4USER and P4PORT (JENKINS-15053)
  • allow whitespaces at end of view mappings
  • fixed issue with saving configurations when blanking out system root and system drive (JENKINS-15348)
  • only overwrite p4ticket if there's a ticket to save
  • fixing P4CLIENT env variable when running concurrent builds (JENKINS-10125)
  • disable form validation on the view map, since it causes issues with large maps (JENKINS-12806)
  • fixed ticket handling problems (JENKINS-15862)
  • use the ticket when running quick clean commands when it's available (JENKINS-15807)
  • prefer the workspace changeset before depot changeset (JENKINS-15515)
  • improved perforce job handling
  • export build changenumber from perforcetagaction (JENKINS-15603)

Version 1.3.17 - (Aug 12, 2012)

Version 1.3.16 - (Aug 7, 2012)

  • added ability to use the same changeset as upstream job
  • fixed NPE when polling with view from file (JENKINS-14216)
  • update documentation (JENKINS-14363)
  • removed code that was breaking remote (UNC) workspace paths (JENKINS-14125)
  • removed redundant api exports (JENKINS-14335)

Version 1.3.15 - (June 8, 2012)

  • added 'owner' and 'description' fields to label post build action
  • fixed issue with incorrect changeset being used for syncing (JENKINS-13879)
  • fixing issue where the password was being exposed internally in jenkins' config files (JENKINS-10326)
  • added new 'quick' clean feature. this emulates a wipe+force sync, but should be faster in many circumstances

Version 1.3.14 - (May 14, 2012)

  • suppressing client spec parse warnings for blank and quoted lines
  • tagging now only requires TAG permission (as opposed to admin privileges) (JENKINS-13736)
  • fixed quoted paths issue in view parsing (JENKINS-7496)
  • added 'owner' field to advanced options for client ownership (JENKINS-13646)

Version 1.3.13 - (April 19, 2012)

  • don't return invalid perforce email addresses in the mailresolver (JENKINS-13324)
  • don't update client view when flushing workspace to 0 on workspace deletion (JENKINS-13080)
  • avoid possible NPE during startup (JENKINS-13394)
  • removed redundant slash from Perfbrowse URL
  • fixed issue with excluded files not working for changesets that include files not in the workspace view (JENKINS-13296)
  • updated pom to use new jenkins maven repository
  • avoid benign NPE when saving a config on a master with no executors (JENKINS-13353)
  • fixed issue with parameter substitution in counter name field
  • added support for displaying integrated changesets
  • always put P4TICKET into environment (JENKINS-13270)
  • added limit for number of files per changelist in order to avoid OOM on large changes (JENKINS-13109)

Version 1.3.12 - (March 29, 2012)

  • fixed NPE that occurs when parsing changes containing a deleted perforce user (JENKINS-13271)

Version 1.3.11 - (March 26, 2012)

  • added case sensitivity option for exclusion of files from polling (JENKINS-13147)
  • exclude .p4config from wipe on checkout (JENKINS-13108)
  • fixed some issues with the mailresolver (JENKINS-13103)
  • added concurrent build support (Thanks Mikko!) (JENKINS-10125)
  • added warning to build log when stripping invalid lines from client spec (JENKINS-13027)
  • wipe before build option no longer flushes the client (since it's just doing a force sync anyways) (JENKINS-13073)
  • allow the usage of build parameters during workspace deletion (JENKINS-13073)
  • fixing some log messages for workspace deletion
  • build properties now override global ones as expected
  • use 'p4' by default if no global p4 installation is defined (JENKINS-13062)

Version 1.3.10 - (March 8, 2012)

  • added support for parameters in stream names
  • added support for controlling 'Disable Sync' and 'Disable Sync and Changelog' options using job parameters
  • improved email resolution for mailer plugins to increase speed and prevent potential hangs
  • added form validation for '-p' and '-f' perforce flag conflict (JENKINS-12948)
  • added support for multiple tags (JENKINS-12906)
  • fixed node-level tool installation location overrides

Version 1.3.9 - (Feb 28, 2012)

  • fixed incorrect default for "Create Workspace" when upgrading to 1.3.8.
  • perforce installations now use the Jenkins ToolInstallation model and are globally and node-level configurable (JENKINS-11369)

Version 1.3.8 - (Feb 21, 2012) (See the note above if you installed this version)

  • added support for Perfbrowse repository browser (thanks verbitan!)
  • fixed some inconsistent string references in help (thanks 4ndrew!)
  • api changes for better artifactory plugin support (thanks yossis!)
  • added 'Let Jenkins Create Workspace' checkbox (thanks garious!)
  • added support for perforce streams (thanks miktap!)
  • fixed form validation on exclude fields when using parameters (JENKINS-12202)
  • fixed issue with slow email resolution (JENKINS-12672)
  • added substitution for counter field (JENKINS-12755 thanks Andy!)
  • plugin now uses the full build environment for parameter substitution, not just job/global parameters (JENKINS-12837)

Version 1.3.7 - (Jan 10, 2012)

  • fixed issue where list of changes includes pending ones, which can cause consistency problems
  • added substitution support to Files/User exclusion fields (JENKINS-12202)

Version 1.3.6 - (Dec 12, 2011)

Version 1.3.5 - (Nov 17, 2011)

  • fixed issue with labeling not working when using a client spec from a file in perforce
  • fixed parameter substitution when using client spec from a file
  • only use the label field for syncing if the parameters in it actually resolve to something non-empty (JENKINS-11677)
  • fixed typo in log output (JENKINS-11740)

Version 1.3.4 - (Nov 3, 2011)

  • perform parameter substitution on clientSpec path when using a file from perforce for the client spec (JENKINS-11423)
  • fixed support for date and revision changelog information in email-ext (JENKINS-11600)

Version 1.3.3 - (Sep 29, 2011)

  • added support for promoted builds plugin to perforce label publisher/notifier
  • don't set P4_CHANGELIST when no changelist is (yet) available. Should solve some consistency issues with envinject.

Version 1.3.2 - (Sep 21, 2011)

Version 1.3.1 - (Sep 8, 2011)

  • add the possibility to use a textual ClientSpec file from the depot to setup the workspace view
  • make all matrixruns use the same changeset as the parent (JENKINS-10592)
  • fixing minor issue with label changeset retreival
  • reimplementation of 'where' mapping for changelog information (JENKINS-10732)

Version 1.3.0 - (July 27, 2011)

  • fixing possible cast exception with new polling method (JENKINS-10411)
  • updated to new polling api to fix issue with polls queuing up additional builds when one is already syncing (this increased the minimum jenkins/hudson version from 1.339 to 1.346)

Version 1.2.9 - (July 15, 2011)

  • minor tweak to docs explaining that 'sync -p' can't work at the same time as 'sync -f' due to a weird limitation in perforce (JENKINS-9819)
  • added nodename substitution for client workspace names on slave machines, with the disclaimer that it may not work with all slave names (JENKINS-10334)
  • removing tek42 depot from pom, since it's down indefinitely
  • fixed issue with 'p4 where' parsing (JENKINS-7618)
  • minor tek42 api bugs

Version 1.2.8 - (July 4, 2011)

  • fixed maven incremental builds integration (JENKINS-7618)
  • changed FishEye links to use changelist number instead of revision number for file diffs (for reals this time) (JENKINS-7747)

Version 1.2.7 - (Jun 20, 2011)

  • check to see if the user exists before attempting to get it's email address (JENKINS-6079)
  • added option to set the owner of a label when manually tagging a build (JENKINS-8354)
  • labels will now have their owner set to the configured perforce user by default (JENKINS-8354)
  • added support for 'p4 sync -p' (JENKINS-9819)
  • fixed issue with JOB_NAME substitutions including incompatible characters for client names (JENKINS-9906)
  • fixed '500' error when saving a user config (caused by missing field)

Version 1.2.6 - (Jun 3, 2011)

  • fixed issue with email ext plugin not displaying changelists (courtesy of 8nevil8 from Oracle)

Version 1.2.5 - (Apr 22, 2011)

  • fixed bad javascript on configuration page that could result in the config page not loading

Version 1.2.4 - (Mar 24, 2011)

  • added "Poll only on Master" option for distributed build environments (JENKINS-9067)
  • fixed NPE when wiping out workspace using the jenkins UI (JENKINS-9022)
  • refactored the way user IDs are stored in order to support email retreival for oddly formatted user names (ie. domain\user) (JENKINS-8987)
  • refactored polling to use configured nodes without needing online workspaces. It will now fall back to polling on the master if none are available (JENKINS-8173)
  • changed hostname retrieval to use the more reliable function provided by jenkins

Version 1.2.3 - (Mar 1, 2011)

  • strip quotes from View Mask entries to prevent issues on the command line (JENKINS-8731)
  • add error logging and detection for file-specific sync errors (JENKINS-8840)
  • add ability to clean .repository for every build (by popular demand) (JENKINS-7182) (JENKINS-8211)

Version 1.2.2 - (Feb 21, 2011)

  • fixed major problem with client name substitution on slave machines (sorry)

Version 1.2.1 - (Feb 18, 2011)

  • fixed major problem with client name substitution on slave machines

Version 1.2.0 - (Feb 11, 2011)

  • be more aggressive with closing pipes
  • adding Disable Syncing Only option (JENKINS-8260)
  • added exclude users and exclude files polling options
  • fixed potential issue where "Enter Password:" could be used as the perforce ticket in certain circumstances
  • changed branding to consider Hudson->Jenkins rename
  • allow changeset number to decrease between builds (in case of forced builds, or p4 server rebuild)
  • added log filtering for p4 sync, which should prevent out of memory issues during large syncs (JENKINS-2142)

Version 1.1.14 - (Jan 6, 2011)

  • adding p4 response output when some more obscure parsing errors occur (JENKINS-8409)
  • don't launch a new build when polling when the client-workspace is 'new'. this should avoid continuous building when using the broken remoting api in hudson (for hudson versions >= 1.378)
  • first release from github!

Version 1.1.13 - (Dec 7, 2010)

  • added another partial fix for intermittent connection issues in hudson >=1.378 (thanks Kohsuke!) (JENKINS-7664)

Version 1.1.12 - (Nov 18, 2010)

  • added a partial fix for intermittent connection issues in hudson >=1.378 (JENKINS-7664)

Version 1.1.11 - (Oct 29, 2010)

  • skip Maven private .repository directory when wiping out the workspace. More appropriate fix for this should be coming eventually. (JENKINS-7182)
  • use changelist number instead of revision number when loading links to fisheye for file diffs (JENKINS-7747)
  • make P4PASSWD environment variable (if enabled) always contain the password, instead of defaulting to the p4 ticket when it's available. Also added P4TICKET environment variable for those who need the ticket instead. (JENKINS-7757)

Version 1.1.10 - (Oct 6, 2010)

  • fixed issue with changeset parsing when comments contained certain reserved phrases (JENKINS-7679)
  • changed polling logic to fall back to another available node when the last one used to build is unavailable. only applies to workspaces names that are constant across slaves (JENKINS-7665)
  • fixed parsing issue when labelling using client specs from perforce, ie. when hudson is not set to manage the workspace. (JENKINS-7642)
  • removed noisy logging from requiresWorkspaceForPolling function (JENKINS-7622)

Version 1.1.9 - (Sep 29, 2010)

  • fixed problem where polling will not work on slaves when using client name substitutions (JENKINS-7610)
  • fixed empty dropdown menu for line endings option when creating new jobs (JENKINS-7606)
  • added better error messages when user fails to create a workspace for hudson when hudson isn't set to manage it on it's own (JENKINS-7555)
  • fixing NPE when labelling a build that isn't configured to let hudson manage the client workspace (JENKINS-7558)

Version 1.1.8 - (Sep 22, 2010)

  • adding support for client mappings of the form //depot/... "//workspace/..." in order to allow spaces in the workspace path when they don't exist in the depot path. (JENKINS-7496)

Version 1.1.7 - (Sep 16, 2010)

  • work around to prevent the job history plugin from recording a change in the perforce configuration when none has been made (JENKINS-6994)
  • adding automatic labeling functionality (JENKINS-7301)

Version 1.1.6 - (Sep 7, 2010)

  • adding parameter substitution support for p4Client (JENKINS-7011)
  • trim whitespace from all config fields (JENKINS-7290)

Version 1.1.5 - (Aug 23, 2010)

  • making changeLogFilename transient so it doesn't pollute the config.xml with unneeded parameters (JENKINS-6994)
  • perform a force sync or clean workspace when P4FORCESYNC or P4CLEANWORKSPACE parameters are set to true respectively (JENKINS-6526)

Version 1.1.4 - (July 2, 2010)

  • Fixed an issue with file and diff links when using fisheye. (JENKINS-6911)
  • Added changeNumber and changeTime to the xml api output for builds. (JENKINS-6836)
  • Reverting hack to prevent polling from running when a job has just been copied, but not yet configured. This is handled by hudson core now. (JENKINS-5975)

Version 1.1.3 - (Jun 14, 2010)

Version 1.1.2 - (Jun 11, 2010)

  • Added support for parameter substitution in view spec during polling. (JENKINS-6696)
  • Fixed a case when using view masks for polling that may cause builds to run continuously. (JENKINS-6576)
  • Adding support for parameter substitution in the view mask.

Version 1.1.1 - (Jun 2, 2010)

  • Added IMPORT as a valid perforce change during changelog parsing. (JENKINS-6686)

Version 1.1.0 - (May 21, 2010)

  • Fixed issue with polling and distributed builds. Thanks martinfr62! (JENKINS-6575)
  • Added parameter substitutions on base client name. (JENKINS-6519)
  • Made the plugin always clear the Host: field in the client spec for shared clients. (JENKINS-6412)
  • Limit number of changesets pulled on the first run of a job (JENKINS-6391)
  • Prevent builds from getting triggered by polling when the job has never run before (JENKINS-5975)
  • Updated documentation (JENKINS-6304)

Version 1.0.29 - (Apr 19, 2010)

  • Fixed potential problem where a job with client updating disabled will always force sync if the client workspace root is different.
  • Added some logging in the event the remote call for determining the slave hostname fails. (JENKINS-6257)
  • Added option to poll and/or sync a subset of depot paths in a job (JENKINS-2926)
  • Added options for P4CHARSET and P4COMMANDCHARSET (JENKINS-6284)

Version 1.0.28 - (Apr 9, 2010)

  • Fixed issue with LineEnd option getting set to 'null'. (JENKINS-6173)
  • Added code to trigger force-sync when job workspace root is changed in the project configuration. (JENKINS-6219)

Version 1.0.27 - (Apr 5, 2010)

  • Added line endings option to select the LineEnd field used by the client workspace. (JENKINS-6074)
  • Added some processing to the client root to avoid things like double slashes.
  • Added error handling to perforcemailresolver to avoid error when running the build for the first time. (JENKINS-6079)
  • Made force syncing optional (but highly recommended) for matrix builds.

Version 1.0.26 - (Mar 25, 2010)

  • Fixed build issue with unix slaves that don't have hostnames properly defined.
  • Fixed problem with workspace paths that contain single-character path elements (JENKINS-6064).
  • Adding support for changeset links to p4web.

Version 1.0.25 - (Mar 20, 2010)

  • Changed polling code so that it won't trigger a build if the job has never been run before. (JENKINS-5975).
  • Adding code to clear the P4CONFIG environment variable before executing any operations on the node. This should alleviate issues with config files interfering with the hudson perforce config. (JENKINS-4595)
  • Removed "do not rename workspace" option and replaced it with a formatted string to allow for more robust customization of the client workspace name on slaves.
  • Added the environment variable HUDSON_CHANGELOG_FILE that contains the location of the changelog xml, so builds with custom sync logic can modify it.
  • Added advanced option to disable syncing (for builds that need custom syncing logic in scripts)
  • Added advanced option for disabling client updating entirely (JENKINS-5841).

Version 1.0.24 - (Mar 12, 2010)

  • Changed the automatically generated client name for slaves to use the hashcode of the slave name instead of the hostname, so that hosts running multiple slaves can sync correctly (JENKINS-5917).
  • Fixed an issue where polling wouldn't work correctly if the client spec was recently changed (JENKINS-5915).
  • Made matrix/multiconfiguration builds always force sync in order to overcome client workspace consistency issues.
  • Improved the readability of the online configuration help.
  • Added option to clean the entire workspace and resync before every build (JENKINS-5182).
  • Fixed possible issue during build tagging when depot view contains spaces.
  • Fixed possible NPE that can occur during build tagging.

Version 1.0.23 - (Mar 5, 2010)

  • Adding support for parameters to the View and Label configuration fields. (JENKINS-5690) Users can now use ${PARAMNAME} to substitute values into the View and Label fields. If substitutions are present, however, polling will be disabled.
  • Fixed form validation false negatives when using certain browsers. (JENKINS-5849).
  • Added support for "Wipe Out Workspace" and added new "Always Force Sync" option. (JENKINS-5182).
  • Reverted form validation change (JENKINS-5342). A better solution is in the works.
  • Added logger to PerforceMailResolver

Version 1.0.22 - (Feb 27, 2010)

  • Adding error reporting when 'Request too large' problems occur during changeset population and syncing.
  • Changed form validation to recognise depot-only view lines as being invalid to avoid confusion (JENKINS-5343).
  • Applying fix provided by avolanis to resolve issue when using counters in downstream builds that are triggered by polling.

Version 1.0.21 - (Feb 19, 2010)

  • Adding additional logging for the email resolver to help troubleshoot issues some are having.
  • Added a retry to the email resolver commands.
  • Fixed an issue with the email resolver when running a linux slave on a windows master and vice versa (JENKINS-5403)

Version 1.0.20 - (Feb 16, 2010)

Version 1.0.19 - (Feb 13, 2010)

  • Fixed issue with p4 executable config parameter not being used properly for all perforce operations (JENKINS-5506)
  • Changed requiresWorkspaceForPolling to allow polling to take place during a build (JENKINS-5545)
  • Removed deprecated call to AbstractProject.getWorkspace
  • Added sanity check to cause perforce commands to fail immediately if the executable path doesn't point to an executable (used to cause hang on windows)
  • Added code that tries to clean-up pipes after a failure described above.
  • Added extra checking and robustness to perforcemailresolver to try and address issues people are having with email resolution.

Version 1.0.18 - (Feb 1, 2010)

  • Fixed issue with P4CLIENT environment variable passing in wrong value on slave machines. (JENKINS-5332)
  • Adding '@' to revision field in labels during label generation. (JENKINS-5398)
  • Added the ability to sync an entire build stream to a single changeset. (JENKINS-4603)
  • Added an option to pass the perforce password into the environment as P4PASSWD.
  • Fixed a minor login bug in the tek42 perforce api.
  • Fixed an issue where the full path to the p4 executable was not being used in the tek42 perforce api.

Version 1.0.17 - (Jan 20, 2010)

  • Fixed minor bug with changelog items not saving correctly (JENKINS-5217)
  • Replaced sun base64 encoder/decoder classes with apache commons codec (JENKINS-4446)
  • Fixed setting of P4CLIENT in the build environment variables (JENKINS-5317)

Version 1.0.16 - (Jan 4, 2010)

  • added common p4 variables to the build environment: P4PORT, P4USER, P4CLIENT
  • Cleaned up view mapping regular expressions, and how they were used to parse and check views.
  • Added automatic workspace path inference for the most common 1:1 depot:workspace paths.
  • Removed p4 retry loop since Hudson now has global SCM retry support.
  • Removed the p4java jar from the deps in the pom since it is not yet used by this version in the trunk.
  • (some of these may have been released in 1.0.15)

Version 1.0.15 - (Nov 19, 2009)

  • Reorganized the config controls for the Perforce plugin to gather most of the options into
    main groups of Setup, Depot and Project.
  • Updated the help as well.
  • Included P4Java jar in deps (unused for now)
  • Applied the patch provided by jmax01, to add new enum values for MOVE/ADD MOVE/DELETE operations (JENKINS-4425)
  • Removed 'depot' instance variable that was being modified by multiple threads simultaneously, this allows perforce commands to be issued from the correct slave nodes.
  • Changed master matrix job to not alter the perforce client root, so that the child matrix job would get the update. (JENKINS-1022)

Version 1.0.14 - (July ?, 2009)

Version 1.0.13 - (4/6/2009)

Version 1.0.12 - (5/15/2008)

  • Fixed issue: 1163, Sync'ing on Hudson Slaves is now supported. Thanks go to Victor (vicsz).
  • Fixed issue: 1681, Labeling builds on JVMs earlier than 1.6 were failing.

Version 1.0.11 - (4/22/2008)

  • Fixed issue: 1313, Sync'ing to Perforce labels is now supported.
  • Added enhancement: 1374, Hudson user's email address is retrieved from Perforce user account if it exists.

Version 1.0.10 - (1/26/2008)

  • Fix issues: 1070, 1072, 1073/1100, 1092, 1093
    • Now supports changelists with purged files.
    • The current changelist number is available as an enviroment variable: P4_CHANGELIST. Thanks go to Eike and gerhard6.
    • Fixed changelist parsing with certain versions of Perforce, thanks go to Kiril.
    • Fixed il8n parsing of changelists, thanks go to gerhard6.
  • Using the latest P4Java version, 0.7.5.

Version 1.0.4 - (11/13/2007)

  • Support for polling/sync'ing with multiple views in a single workspace
  • Uses new P4Java version that supports Perforce security level 3
  • Fixed issue when prior build does not have any changes

Version 1.0.3 - (10/26/2007)

  • Fixed issue where the last sync'd changelist would be lost on a restart of Hudson. This resulted in the next build after a restart being marked as containing all prior changes.
  • Fixed issue with improper XML encoding of changelist history.
  • Fixed issue with invalid characters in XML of changelist history.
  • Fixed issue where a manual build would always be marked as failed if there were no new changes present.
  • Changed validation to allow project paths that start with something other than //depot/
  • Fixed problem with changelist icons not showing up on unix systems.
  • Fixed NPE on first build of a new project
  • Added ability to specify first change to record history from
  • Added ability to use workspace with custom views specified by end user.

Version 1.0 - (10/09/2007)

  • Support for repository browsing with P4Web and Fisheye
  • Support for tagging of builds (Referred to as Labels in Perforce, so that is what is used in the plugin)
  • Support for doing a force sync to head (allowing Hudson to bring down all project files)
  • Perforce security level 3 is supported on unix systems. Windows currently requires a workaround.
  • Fixed bug on unix systems where workspace root was incorrect.
  • Validation of Perforce settings is now done on configuration page.
  • The Perforce workspace (clientspec) descriptions are no longer lost after a build.

Version 0.9 - (10/04/2007)

  • Production ready release. Includes support for displaying change history. Perforce specific details, such as Jobs, are included in reporting.

Version 0.5 - (9/29/2007)

  • Initial release. Includes support for polling and synchronizing. Repository browsing and latest changes still to come. 

Disclaimer

As mentioned above, do NOT use the wiki comments to ask for support! If you have a question, you should ask the mailing list or the irc channel. You should also check the list of open issues on the issue tracker. Failing that, you can contact rpetti directly for assistance.

133 Comments

  1. Anonymous

    Nice! Have been waiting for Perforce support.

  2. Anonymous

    Nice plugin. Unfortunately this plugin (v1.0.10) can not check out from a label yet, see https://hudson.dev.java.net/servlets/BrowseList?list=dev&by=thread&from=976444

    1. Unknown User (mike@tek42.com)

      Version 1.0.11 now supports this.

  3. In my environment, when a file is deleted Hudson does not detect it. It might be a Perforce configuration issue, but thanks to Hudson's flexibility, I could provide a quick workaround by enabling the "Shell script" option and adding the following command:

    p4 sync "$PWD/..."

    (sure, it's a Unix-only trick, but I don't even consider running CI on Winblows (smile)

    1. Unknown User (mike@tek42.com)

      The Perforce plugin for Hudson interacts directly with the P4 client so there should be no need to run this command. I wonder if the workspace is being used in multiple projects? It might be thinking the file was already removed when executed from the other project. Though it sounds like you are fine with it, this can be fixed if you wish to pursue it.

  4. Anonymous

    Hi,

    Trying to use this plugin with our version of perforce (2003.2 56323), but am getting these error:Caught Exception communicating with perforce. Error in client specification. Error detected at line 7. Null directory (//) not allowed in '///...'.
    For Command: p4 -s client -i
    With Data:
    ===================
    Client:
    Description:
    Root: C:\Development\XP\CI\Hudson\jobs\Framework\workspace\
    Options:
    LineEnd:
    View:
    //depot/Framework/current/... ///...

    Why isnt there a clientspec name in the view definition?

    Thanks

    Mike 

    1. Unknown User (mike@tek42.com)

      This looks to be the same problem described here:

      https://hudson.dev.java.net/issues/show_bug.cgi?id=1070

      I believe that 2003.x and earlier servers do something different that the Perforce library does not support. Unfortunately, the oldest version of Perforce I can get my hands on is 2005. So I can't even reproduce the problem.

      1. I have run into a similar issue, with a different error message running P4 server version (Server 2006.1/109255.).

        I assumed this error meant that the client needed the environment variable P4CHARSET=utf8, but I have tried setting this in the environment variables with no luck and didn't see a way to specify it through the plugin.  I noticed that the client workspace appears to be null as the plugin tries to set the client view to ///... so it seems like this might be related.

         Here is the error from the logs:

        ======
        workspace $ p4 workspace -o bld-blbaker-a7-blaze-windows-continuous-hudson
        Changing P4 Client Root to: c:\tomcat6\webapps\hudson\jobs\blaze-continuous\workspace\
        Changing P4 Client View to: //blaze/trunk/... ///...
        workspace $ p4 -s client -i
        Caught Exception communicating with perforce. Unicode server permits only unicode enabled clients.
        ======
         Any ideas of what I am doing wrong?  I tried running "p4 -u bld -s client" from a comand prompt and it seems to work fine (-u bld is because I am running as a different p4 user than the user logged into the build box).

        Thanks,

        ~D

  5. Unknown User (bilabee)

    Hello,

     When building on a slave machine our code is being checked out on the master machine.  Is there anyway to get it to checkout to the slave machine?

     Thanks,

    Bila

    1. Unknown User (mike@tek42.com)

      Not yet, unfortunately. See this issue for updates:

      https://hudson.dev.java.net/issues/show_bug.cgi?id=1163

  6. Unknown User (guiding5@gmail.com)

    Hi,

    Is it possible to name a build by latest change list number ?

    Is it possible to add change list number to notification emails ?

  7. Hi.

    hudson : ver1.270
    p4.exe  P4/NTX86/2007.3/143793 (2008/01/21).
    perforce_plugin :1.0.12

     When I tried to label a build , I get the following exception:

    --

    java.io.IOException: Failed to issue perforce label. Error in label specification. Error detected at line 5. Unknown field name 'Revision'.
    For Command: p4 -s label -i
    With Data:
    ===================
    Label: hoge-Build-57
    Owner:
    Description:
        Changelist: 106
    Revision: 106
    Options:
    View:
        //depot/...

  8. Hi!

    I was looking for a fix of an issue in Perforce plugin, and I found out, that it has already been fixed in the source code, but it has NOT yet been published in a stable build. Please see my comment in issue #1100 (https://hudson.dev.java.net/issues/show_bug.cgi?id=1100). Further, I'm interested in getting the fix for issue #1745 (https://hudson.dev.java.net/issues/show_bug.cgi?id=1745), because I encountered the same problem.

    I am looking very much forward to a new stable build of the Perforce plugin - when will it be released?

    Or how can I access a snapshot-version (talking in Maven dialect) of the Perforce plugin?

    Thanks for your help,

    Chris

  9. Unknown User (cashman@filidh.org)

    The 1.0.13 release no longer appears to honor the Let Hudson Manage Workspace View flag; Hudson always tries to manage the workspace view, even when the flag is deliberately unset, and as a result it can't cope with the Depot Path set to //... .  Had to revert to 1.0.12 of the plugin after this generated a series of build failures.

    1. Unknown User (david@saff.net)

      I'm having the same problem, Brett.  Did you log a bug I can vote on?

        David Saff

      1. Unknown User (cashman@filidh.org)

        David, didn't, sorry. But if you log one, I'll vote for it. (smile)

  10. I installed the Trac Plugin and wanted to set "Trac" for the "Repository browser" setting in the Source Code Management section for Perforce but it is not available (it is available for the SVN SCM)

    How  can Trac be added there (P4Web and FishEye are available) or has it to be implemented which would be nice if you could do (smile)

  11. Unknown User (cdave)

    Hi! All,

    I'm trying to use perforce plugin for setting up my contineous build environment.

    The worst part here is i am not getting any error from perforce plugin so that i can debug that where am i going wrong in configuring environment.

    I am following steps described in this tutorial.

    whenever it invokes perforce plugin logs shows up  onlyStarted on Jul 23, 2009 2:23:37 PM
    Looking for changes...
    Using master perforce client: chirag.dave_hudson
    workspace $ p4 workspace -o chirag.dave_hudson
    and hangs up. 

    I am using hudson 1.314

    and perforce :- 1.0.14

    Perforce client version - 2008.1/158777

    Here is the configuration data that i have been trying.

    perforce_plugin_err.bmp

    Any help will be appreciated.

    Thanks,

    Dave. 

    1. Unknown User (chris.hilton@zilliant.com)

      It looks like your view specification is incomplete. Click on the question mark to the right and you'll see that your view should include depot and workspace file specs.

  12. Unknown User (chris.hilton@zilliant.com)

    On another note, I'm just getting started on Hudson and wonder how is the FishEye integration supposed to work? My project has a view like this:

    //depot/userbranches/ulfertsm-main/main/... //hudson_ulfertsm-main-DEVBUILD-HUDSON-V/...
    
    //depot/zpm/main/build/new-nightly/bamboo/local-product.properties //hudson_ulfertsm-main-DEVBUILD-HUDSON-V/local.properties
    
    //depot/3rdparty/jboss/4.2.3/... //hudson_ulfertsm-main-DEVBUILD-HUDSON-V/jboss/...
    

    And I've defined the FishEye URL as "http://devtools2-v.austx.zilliant.com/browse/Zilliant_Perforce/", the top of the Perforce depot which may or may not be correct (I'm mostly interested in being able to see files under the userbranch above). I do end up with hyperlinked files in the changes area, but a file like this:

     //depot/userbranches/ulfertsm-main/main/policymgt/optimization/server/product/config/pricingDocumentDefinitions/optimization/EngineRecommendations.xml
    

    ends up with a link like this:

     http://devtools2-v.austx.zilliant.com/depot/userbranches/ulfertsm-main/main/policymgt/optimization/server/product/config/pricingDocumentDefinitions/optimization/EngineRecommendations.xml
    

    Which doesn't work nor any URL that begins with depot after the server. The URL I might have expected Hudson to make that does work is:

     http://devtools2-v.austx.zilliant.com/browse/Zilliant_Perforce/userbranches/ulfertsm-main/main/policymgt/optimization/server/product/config/pricingDocumentDefinitions/optimization/EngineRecommendations.xml
    

    So is this something wrong with my configuration or with the plugin?

  13. Unknown User (ickis)

    Hi, Perforce is strongly being used in our build processes @ EA. I was able to configure the Perforce plugin in hudson but really need to be able to just sync a certain directory of the current workspace like in the Perforce front end. So multiple Hudson jobs would share a workspace but "filtering"it to just get a single unique directory.

    Could that be handled by adding some options to the p4.exe called by the client? (wrapping the call with another script for instance). If not where I could place this request?

    thanks 

    1. I have a similar requirement. 

      Is it possible to sync different directories to different CLs?

       

      1. Perforce doesn't support that in client specs. You will need to call the CLI yourself in a build action in order to manually sync different folders to different CLs.

  14. I recently updated to Hudson 1.326 from 1.299... I also update to the latest perforce plugin, and now, although some projects work, others do not... In my catalina log I get the following error (over and over again):

    com.thoughtworks.xstream.converters.reflection.NonExistentFieldException: No such field hudson.plugins.perforce.PerforceSCM.nodeSuffix
            at com.thoughtworks.xstream.converters.reflection.FieldDictionary.field(FieldDictionary.java:106)
            at com.thoughtworks.xstream.converters.reflection.PureJavaReflectionProvider.getFieldType(PureJavaReflectionProvider.java:152)
            at hudson.util.RobustReflectionConverter.determineType(RobustReflectionConverter.java:327)
            at hudson.util.RobustReflectionConverter.doUnmarshal(RobustReflectionConverter.java:218)
            at hudson.util.RobustReflectionConverter.unmarshal(RobustReflectionConverter.java:173)
            at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:82)
            at com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:63)
            at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:76)
            at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:60)
            at hudson.util.RobustReflectionConverter.unmarshallField(RobustReflectionConverter.java:262)
            at hudson.util.RobustReflectionConverter.doUnmarshal(RobustReflectionConverter.java:222)
            at hudson.util.RobustReflectionConverter.unmarshal(RobustReflectionConverter.java:173)
            at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:82)
            at com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:63)
            at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:76)
            at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:60)
            at com.thoughtworks.xstream.core.TreeUnmarshaller.start(TreeUnmarshaller.java:137)
            at com.thoughtworks.xstream.core.AbstractTreeMarshallingStrategy.unmarshal(AbstractTreeMarshallingStrategy.java:33)
            at com.thoughtworks.xstream.XStream.unmarshal(XStream.java:923)
            at hudson.util.XStream2.unmarshal(XStream2.java:67)
            at com.thoughtworks.xstream.XStream.unmarshal(XStream.java:909)
            at com.thoughtworks.xstream.XStream.fromXML(XStream.java:853)
            at hudson.XmlFile.read(XmlFile.java:126)
            at hudson.model.Items.load(Items.java:106)
            at hudson.model.Hudson$9.call(Hudson.java:1995)
            at hudson.model.Hudson$9.call(Hudson.java:1988)
            at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
            at java.util.concurrent.FutureTask.run(FutureTask.java:138)
            at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
            at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
            at java.lang.Thread.run(Thread.java:619)
    Oct 2, 2009 12:03:00 PM hudson.util.RobustReflectionConverter doUnmarshal

    What do I need to do to make this work? Is there a newer version in the works?

  15. Information is showing lot of success stories of Perforce integration with Hudson but I have issues while setting up as Master/Slave configuration. I am getting following exception:

    [workspace] $ p4 workspace -o
    Caught Exception communicating with perforce. Connect to server failed; check $P4PORTcom.tek42.perforce.PerforceException: Connect to server failed; check $P4PORT
    at com.tek42.perforce.parse.AbstractPerforceTemplate.getPerforceResponse(AbstractPerforceTemplate.java:324)
    at com.tek42.perforce.parse.Workspaces.getWorkspace(Workspaces.java:53)
    at hudson.plugins.perforce.PerforceSCM.getPerforceWorkspace(PerforceSCM.java:699)
    at hudson.plugins.perforce.PerforceSCM.checkout(PerforceSCM.java:295)
    at hudson.model.AbstractProject.checkout(AbstractProject.java:973)
    at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:400)
    at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:349)
    at hudson.model.Run.run(Run.java:1120)
    at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
    at hudson.model.ResourceController.execute(ResourceController.java:88)
    at hudson.model.Executor.run(Executor.java:123)

  16. Unknown User (hanjun.ryu)

    I'd find critical defect using linux master with linux slave ( Ubuntu 9.04 64bit ).
    Both of perforce version 1.0.13 & 1.0.14 has this problem when using perforce.hpi.
    ===========================================================================================================================
    Using shared perforce client: (my_client_workspace_name)
    Caught Exception communicating with perforce. No output for: p4 workspace -o (my_client_workspace_name) com.tek42.perforce.PerforceException: No output for: p4 workspace -o SE_SCM_TEST_USER_1
    at com.tek42.perforce.parse.AbstractPerforceTemplate.getPerforceResponse(AbstractPerforceTemplate.java:326)
    at com.tek42.perforce.parse.Workspaces.getWorkspace(Workspaces.java:53)
    at hudson.plugins.perforce.PerforceSCM.getPerforceWorkspace(PerforceSCM.java:1417)
    at hudson.plugins.perforce.PerforceSCM.getWorkspaceFull(PerforceSCM.java:397)
    at hudson.plugins.perforce.PerforceSCM.checkout(PerforceSCM.java:343)
    at hudson.model.AbstractProject.checkout(AbstractProject.java:978)
    at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:421)
    at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:370)
    at hudson.model.Run.run(Run.java:1120)
    at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
    at hudson.model.ResourceController.execute(ResourceController.java:88)
    at hudson.model.Executor.run(Executor.java:123)
    =========================

  17. Unknown User (hanjun.ryu)

  18. Unknown User (julian.h.hudson@gmail.com)

    Hi!

    First of all, let me thank you for this nice plugin.

    However, there is one thing that doesn't work as expected: From time to time the plugin won't check out (e.g. get latest version) all the changed files in a directory.

    There are, for example, two files that have been changed in the latest submitted changelist:

    - file1.build

    - file2.vbs

    The perforce plugin, however, only detects the .build-file as being changed - the other file won't be checked out by the plugin at all!

    What can I do? Can you give me some advice or maybe some hints?

    Best Regards,

    Julian

    1. Hi,

      We are seeing the same issue.  In our case the file that won't update is pom.xml.  A one-time force sync resolved the issue, but we are wondering about why it appears to be happening and what we can do to avoid it in the future.

      Any information would be greatly appreciated!

      Thanks,

      Bobbi

      1. In Mr. Haslinger's case the problem was wrong configuration. They used the same clientspec for several jobs/hudson slaves. Maybe that's your problem too?

        Regards,
        Judith

  19. Unknown User (btomasini)

    Hi,

    Thanks for this plugin.  When I try to congiure it, I get this below the workspace name:

    "Unable to check workspace against depot"

    When I run the job, this repeats over and over.  I have the depot working fine from my command line.
    Using master perforce client: btomasini-ws-hudson
    workspace $ p4 workspace -o btomasini-ws-hudson
    Caught Exception communicating with perforce. Connect to server failed; check $P4PORTcom.tek42.perforce.PerforceException: Connect to server failed; check $P4PORT
    at com.tek42.perforce.parse.AbstractPerforceTemplate.getPerforceResponse(AbstractPerforceTemplate.java:324)
    at com.tek42.perforce.parse.Workspaces.getWorkspace(Workspaces.java:53)
    at hudson.plugins.perforce.PerforceSCM.getPerforceWorkspace(PerforceSCM.java:649)
    at hudson.plugins.perforce.PerforceSCM.checkout(PerforceSCM.java:260)
    at hudson.model.AbstractProject.checkout(AbstractProject.java:1005)
    at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:431)
    at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:378)
    at hudson.model.Run.run(Run.java:1176)
    at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:304)
    at hudson.model.ResourceController.execute(ResourceController.java:88)
    at hudson.model.Executor.run(Executor.java:123)

    1. Unknown User (pip)

      I had the same issue, which was resolved by ensuring that perforce was in the system path (ie you could run p4 from any command window - for some reason the P4 installer hadn't set this on my system) and ensuring that perforce had also set the P4PORT and P4CLIENT environment variables (ie ensure you have a default clientspec). Don't know which one it was. But Hudson no longer sits in an infinite p4 workspace -o loop for me.

  20. I've installed the latest version of Hudson in combination with the latest version of the Perforce Plugin, but I can't getting it to work. This is my output :

    Started by user anonymous
    Using master perforce client: HUDSON-BUILD
    [workspace] $ p4 workspace -o HUDSON-BUILD
    Caught exception communicating with perforce. No output for: p4 workspace -o HUDSON-BUILD com.tek42.perforce.PerforceException: No output for: p4 workspace -o HUDSON-BUILD
        at com.tek42.perforce.parse.AbstractPerforceTemplate.getPerforceResponse(AbstractPerforceTemplate.java:322)
        at com.tek42.perforce.parse.Workspaces.getWorkspace(Workspaces.java:53)
        at hudson.plugins.perforce.PerforceSCM.getPerforceWorkspace(PerforceSCM.java:670)
        at hudson.plugins.perforce.PerforceSCM.checkout(PerforceSCM.java:293)
        at hudson.model.AbstractProject.checkout(AbstractProject.java:1013)
        at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:486)
        at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:412)
        at hudson.model.Run.run(Run.java:1179)
        at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
        at hudson.model.ResourceController.execute(ResourceController.java:88)
        at hudson.model.Executor.run(Executor.java:122)
    Finished: FAILURE

    My environment is : Ubuntu Linux 8.04.3 - 64 bit / Hudson 1.3339 / Perforce plugin 1.0.16

    Also the configuration of a project gives problems : I always get the message "Unable to check workspace against depot", but my "p4" executable is available for all users on the system.

    1. try running the command that is failing yourself. You may see a perforce error message that indicate the problem. That's what happened to me the first time I setup a workspace/job (I can't remember what my error was but I know I figured it out from the p4 error message).

  21. Where can I file a request for the Perforce plugin to provide a way to consume a Hudson property when specifying the View in the plugin GUI. In the current version (1.0.16), the Perforce View requires you to specify both the depot-location and local-workspace as such:

    //depot-location/... //local-workspace-view-of-depot

    I'd like to be able to define my own Hudson properties some.property and some.other.property, and have them consumed by the Perforce plugin:

    //some.property //some.other.property

    A colleague of mine mentioned there are other Hudson plugins which consume Hudson properties as I've described, and makes the Perforce plug-in a lot more robust.

  22. I used this on one mac without any issues. But when I tried on a second mac, set up identically (afaict), when a build starts it just hangs. when I abort the build I see this call stack (interrupted by my abort):

    at java.lang.Object.wait(Native Method)
    at java.lang.Object.wait(Object.java:474)
    at hudson.slaves.WorkspaceList.acquire(WorkspaceList.java:173)
    at hudson.slaves.WorkspaceList.acquire(WorkspaceList.java:161)
    at hudson.slaves.WorkspaceList.allocate(WorkspaceList.java:129)
    at hudson.model.AbstractBuild$AbstractRunner.decideWorkspace(AbstractBuild.java:391)
    at hudson.model.FreeStyleBuild$RunnerImpl.decideWorkspace(FreeStyleBuild.java:56)
    at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:405)
    at hudson.model.Run.run(Run.java:1198)
    at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
    at hudson.model.ResourceController.execute(ResourceController.java:88)
    at hudson.model.Executor.run(Executor.java:122)

    I don't know how to start to debug this!? The perforce info was accepted (eg no red message about not being able to view/read the workspace).

    How can I get more info to debug? Is this a perforce plugin issue or a hudson issue (or combination?).

    Any help/suggestions appreciated.
    Peter

    1. I deleted the project, and afaik entered the same info/setup, but this time it worked!-P

  23. Feature request for Perforce plugin (where is the best place to post this?): "Changelist to sync to"

    I may take a stab at looking at the source, but for now, I'll request somebody else do this for me!-)

    Rather than a label (which some have reported doesn't work), I'd like to be able to manually specify a changelist number to be used for the sync and build. Seems like it would be close to the label option, hopefully somebody else would find this useful?

    Peter

    1. This would be extremely useful.

      Now that this plugin supports parameter substitution in the view I expected I could just append the following to the view spec

      //depot/MyProject/...@${CHANGELIST_TO_SYNC_TO}
      

      ... but the plugin tries to be smart about it and moves the option into the "Sync to label" field automatically.

      In the meantime you have to disable automatic syncing add the following shell command task

      p4.exe sync @%CHANGELIST_TO_SYNC_TO%
      

      This works, but unfortunately prevents the changelist view from working.

      1. Hi,

        i need that feature to build large code base in different jenkins projects. All projects have to use the same changelist. Currently is us parameterized build to give the changelist number to downstream projects.

        Thanx

        1. There are several ways to do that. Contact me directly if you need assistance.

          Also, please do not use the wiki comments for support, bug reports, or feature requests. I don't check it very often.

  24. I used copy project to start a new project (workspace). It's a complete branch of an existing project so the only thing to change was the perforce workspace name. Everything seems to work but the perforce plugin section says that the workspace does not exist (even though it does). I'm wondering if this is because of creating the project via copy project or something?

    1. Considering the fact Hudson can manage the workspace for you and you didn't have a pre-configured workspace for the protect during job configuration hudson displays an error.
      If it's the first time don't worry about it just make sure to have the "One Time Force Sync" chekcbox selected and you are good to go.

      Another option which seems the wrong way to go - is to use your P4 desktop client create a workspace and add it to hudson this will prevent the error message.

  25. I am using Hudson 1.343 with the Perforce plugin 1.0.18, and the value for "Path to p4 executable" now requires "p4.exe" to be appended to the path.  Was this change intended?

  26. Is there a way to make the plugin perform a force sync every time a build is started?

    1. Unknown User (john.bolton@quest.com)

      The latest version of the plug-in allows you to configure each job to perform a full sync for each build. The option name is "always force sync".

  27. Enhancement wish / request

    I am using Perforce with multiple views whilst a certain area of the view has build related tools for example:
    //depot/Common/Infra/JEE/ver1.0/... //Infra-JEE-ver1.0-site/...
    //depot/Configuration/cm/... //Infra-JEE-ver1.0-site/cm/...

    If I change something in path: //depot/Configuration/cm/ all SCM triggered builds are queued for build is there a way to exclude changes by path e.g like in subversion plugin see example screenshot:

  28. I don't know if this is a plugin question or hudson api question but I noticed that the email extension has some replace macros/variables one of which is CHANGES so that you can embed the changelists. It would be nice if similar things could be exposed to the batch scripts eg the changelist it is syncing to, list of changes, etc

  29. Unknown User (rory)

    After updating to 1.0.19, it seems to have lost the ability to poll the perforce server. Is there a way to get at the previous version again?

    Oh, it syncs fine if I schedule the build manually by the way. I see this in the log:

    Feb 15, 2010 7:52:22 PM hudson.triggers.SCMTrigger$Runner runPolling
    SEVERE: Failed to record SCM polling
    java.lang.NullPointerException
    at hudson.plugins.perforce.PerforceSCM.getPerforceWorkspace(PerforceSCM.java:739)
    at hudson.plugins.perforce.PerforceSCM.pollChanges(PerforceSCM.java:538)
    at hudson.scm.SCM.poll(SCM.java:344)
    at hudson.model.AbstractProject.poll(AbstractProject.java:1150)
    at hudson.triggers.SCMTrigger$Runner.runPolling(SCMTrigger.java:319)
    at hudson.triggers.SCMTrigger$Runner.run(SCMTrigger.java:346)
    at hudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:118)
    at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
    at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
    at java.util.concurrent.FutureTask.run(Unknown Source)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
    at java.lang.Thread.run(Unknown Source)

    1. Unknown User (john.bolton@quest.com)

      I ran into a problem where the latest Perforce plug-in doesn't work for me. I discovered that each time a Hudson plug-in is upgraded, the previous one is renamed to *.bak. The plug-ins are stored in %HUDSON_HOME%\plugins.You can simply stop the Tomcat server, go into that directory, delete perforce.hpi and it's directory, rename perforce.bak to perforce.hpi, and finally restart Tomcat, or whatever your Java server is.

  30. Unknown User (trelony)

    It looks like the plugin uses master's P4 path on a slave (master is 64 bit Windows, but slaves are 32 bit). This is what I get after few recent updates:

    XXX $ "C:\Program Files (x86)\Perforce\p4.exe" workspace -o YYY
    Caught exception communicating with perforce. No output for: C:\Program Files (x86)\Perforce\p4.exe workspace -o YYY
    com.tek42.perforce.PerforceException: No output for: C:\Program Files (x86)\Perforce\p4.exe workspace -o YYY
    at com.tek42.perforce.parse.AbstractPerforceTemplate.getPerforceResponse(AbstractPerforceTemplate.java:336)
    at com.tek42.perforce.parse.Workspaces.getWorkspace(Workspaces.java:53)
    at hudson.plugins.perforce.PerforceSCM.getPerforceWorkspace(PerforceSCM.java:723)
    at hudson.plugins.perforce.PerforceSCM.checkout(PerforceSCM.java:330)
    at hudson.model.AbstractProject.checkout(AbstractProject.java:1024)
    at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:479)
    at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:411)
    at hudson.model.Run.run(Run.java:1198)
    at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
    at hudson.model.ResourceController.execute(ResourceController.java:88)
    at hudson.model.Executor.run(Executor.java:122)
    Archiving artifacts
    Sending e-mails to: ZZZ
    Finished: FAILURE

  31. Unknown User (rory)

    Thanks for fixing that previous issue so quickly. I have another problem though now. I'm using just one perforce workspace and allowing Hudson to change the view according to the current job. The problem is that it doesn't force the sync to the changelist for each job. This means that one job will sync correctly to the changelist number, but the next one won't get any files since perforce thinks that the workspace is up to date.

    How do I work around this? I'm using the free perforce, so I only have 5 workspaces to use.

    1. Unknown User (john.bolton@quest.com)

      The latest Perforce plugin (1.0.25) has an option to "always force sync" for each project. This should workaround your issue problem.

  32. Hi,

    I upgraded Hudson as well as Perforce to 1.349 and 1.023 respectively.

    Hudson syncs in a maven project from Perforce server and my build process depends on the pom.xml which was synced recently.

    But to my surprise, the pom.xml gets deleted every time I trigger a build, to sync latest from Perforce. This makes my build fail due to unavailability of the pom.xml.

    Please help as this crucial for my project needs.

    1. I tried with the older versions till 1.011 but I still face the same issue. (sad)

  33. I have Hudson 1.351 and the Perforce plugin 1.0.24 installed.  Is there a limit to the length of the string used for the client name?  I had a client named "TEST-CI-cmo-app-main-master", and when the system attempted to poll perforce for changes (in a master slave environment), I got the following error:

    [TEST-CI-cmo-app-main] $ c:\\perforce
    p4.exe changes -m 2 //TEST-CI-cmo-app-main-master-854888031/...
    ERROR: Failed to record SCM polling
    java.lang.NumberFormatException: For input string: "-"
        at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
        at java.lang.Integer.parseInt(Integer.java:474)
        at java.lang.Integer.<init>(Integer.java:620)
        at com.tek42.perforce.parse.Changes.getChangeNumbers(Changes.java:144)
        at hudson.plugins.perforce.PerforceSCM.needToBuild(PerforceSCM.java:663)
        at hudson.plugins.perforce.PerforceSCM.pollChanges(PerforceSCM.java:570)
        at hudson.scm.SCM.poll(SCM.java:370)
        at hudson.model.AbstractProject.poll(AbstractProject.java:1153)
        at hudson.triggers.SCMTrigger$Runner.runPolling(SCMTrigger.java:330)
        at hudson.triggers.SCMTrigger$Runner.run(SCMTrigger.java:359)
        at hudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:118)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
        at java.util.concurrent.FutureTask.run(FutureTask.java:123)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
        at java.lang.Thread.run(Thread.java:595)

    I changed the client name in the job configuration to "T-CI-cmo-app-main", and the polling error went away.

    1. Are you building on a Hudson master or a Hudson slave.

      If it's on a slave I noticed the same issue until I updated the salve.jar which solved the issue.

  34. Unknown User (john.bolton@quest.com)

    I have been unable to upgrade to the latest version of the P4 Hudson plugin.Perforce plug-in version 1.0.15 is the last version that seems to work. As soon as I upgrade (everything works fine beforehand), I see the following error in the job configuration view: "Unable to check workspace against depot"

    Tomcat log shows:


    hudson home directory: c:\src\hudson
    Green Balls!
    93 [Handling GET /hudson/scm/PerforceSCM/validatePerforceLogin : http-8080-2] INFO perforce - Executing: C:\Program Files\Perforce counter change
    109 [Handling GET /hudson/scm/PerforceSCM/validateP4Client : http-8080-2] INFO perforce - Executing: C:\Program Files\Perforce counter change
    156 [Handling GET /hudson/scm/PerforceSCM/checkChangeList : http-8080-3] INFO perforce - Executing: C:\Program Files\Perforce counter change
    10186 [Handling GET /hudson/scm/PerforceSCM/validateP4Client : http-8080-3] INFO perforce - Executing: C:\Program Files\Perforce counter change
    Problem: Could not run perforce command.
    com.tek42.perforce.PerforceException: Could not run perforce command.
        at hudson.plugins.perforce.HudsonP4Executor.exec(HudsonP4Executor.java:83)
        at com.tek42.perforce.parse.AbstractPerforceTemplate.getPerforceResponse(AbstractPerforceTemplate.java:289)
        at com.tek42.perforce.parse.Workspaces.getWorkspace(Workspaces.java:53)
        at hudson.plugins.perforce.PerforceSCM.getPerforceWorkspace(PerforceSCM.java:835)
        at hudson.plugins.perforce.PerforceSCM.pollChanges(PerforceSCM.java:632)
        at hudson.scm.SCM.poll(SCM.java:370)
        at hudson.model.AbstractProject.poll(AbstractProject.java:1153)
        at hudson.triggers.SCMTrigger$Runner.runPolling(SCMTrigger.java:330)
        at hudson.triggers.SCMTrigger$Runner.run(SCMTrigger.java:359)
        at hudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:118)
        at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
        at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
        at java.util.concurrent.FutureTask.run(Unknown Source)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
        at java.lang.Thread.run(Unknown Source)
    Caused by: java.io.IOException: Cannot run program "C:\Program Files\Perforce" (in directory "c:\src\hudson\jobs\PA_for_UC_9.0.0_Windows_Incremental\workspace"): CreateProcess error=5, Access is denied
        at java.lang.ProcessBuilder.start(Unknown Source)
        at hudson.Proc$LocalProc.<init>(Proc.java:149)
        at hudson.Proc$LocalProc.<init>(Proc.java:121)
        at hudson.Launcher$LocalLauncher.launch(Launcher.java:633)
        at hudson.Launcher$ProcStarter.start(Launcher.java:268)
        at hudson.plugins.perforce.HudsonP4Executor.exec(HudsonP4Executor.java:74)
        ... 15 more
    Caused by: java.io.IOException: CreateProcess error=5, Access is denied
        at java.lang.ProcessImpl.create(Native Method)
        at java.lang.ProcessImpl.<init>(Unknown Source)
        at java.lang.ProcessImpl.start(Unknown Source)
        ... 21 more
    42057 [Handling GET /hudson/scm/PerforceSCM/validatePerforceLogin : http-8080-3] INFO perforce - Executing: C:\Program Files\Perforce counter change
    43102 [Handling GET /hudson/scm/PerforceSCM/validatePerforceLogin : http-8080-3] INFO perforce - Executing: C:\Program Files\Perforce counter change
    48328 [Handling GET /hudson/scm/PerforceSCM/validatePerforceLogin : http-8080-3] INFO perforce - Executing: C:\Program Files\Perforce counter change
    48344 [Handling GET /hudson/scm/PerforceSCM/validatePerforceLogin : http-8080-3] INFO perforce - Executing: C:\Program Files\Perforce counter change
    52603 [Handling GET /hudson/scm/PerforceSCM/checkChangeList : http-8080-3] INFO perforce - Executing: C:\Program Files\Perforce counter change
    Could not get effective client name: null
    Exception in thread "Executor #0 for Linux Build Machine" java.lang.NullPointerException
        at hudson.model.Computer.getNode(Computer.java:385)
        at hudson.slaves.SlaveComputer.getNode(SlaveComputer.java:138)
        at hudson.slaves.SlaveComputer.getRetentionStrategy(SlaveComputer.java:436)
        at hudson.slaves.SlaveComputer.taskCompletedWithProblems(SlaveComputer.java:238)
        at hudson.model.Executor.run(Executor.java:138)


    The Perforce client works just fine when I revert the plug-in back to its previous version. Nothing has changed on the system during the upgrade other than the Perforce plug-in.

    I am using Hudson version 1.352 on Windows 2008 R2, Tomcat 6.0.20, Perforce client is 2009.2, Perforce server is 2009.2.

    Ideas?

    Thanks,

    John

    1. Unknown User (john.bolton@quest.com)

      One note, JDK is 1.6U16, 64-bit. We're also using the 64-bit platform Tomcat binary files, and of course Windows 2008 R2 is 64-bit only.

  35. Unknown User (snemetz@hotmail.com)

    Version 1.0.27 - (Apr 5, 2010) Adding the LineEnd field broke all my builds

    It appears that it is now sending the LineEnd option whether it has been set or not. When it sends it without a valid value perforce returns an error and the build fails.

    Please update to only send the LineEnd field if it has been set in hudson.

    Also, it would be nice to set this globally, instead of having to define it in every job.

    Thanks,

    Steven

    1. Unknown User (sparky7891)

      Yes, I find that a release of this plugin breaks all of our builds about every 3 months.  I recommend upgrading with extreme caution.

      A couple examples:

      -Perforce user's password is now encrypted (issue #2499, issue #3302)

      *The change didn't encrypt current passwords, it just assumed they were all now incorrect since they don't decrypt correctly.

      -Added automatic workspace path inference for the most common 1:1 depot:workspace paths.

      *The maven pom.xml I was referencing was no longer in the root of the workspace, so all maven builds failed

  36. Unknown User (stang2)

    Anybody having any problems with this latest release on Hudson 1.355?  I like to upgrade to the Hudson pre release and the latest P4Plugin.  Running on Linux with no nodes.

  37. A great addition would be to be able and name the workspace with a variable, for exmaple "hudson_$JOB_NAME"

    What happens today is I am managing over 80 different perforce workspaces for our hudson instance, and when copying a job I need to "remember" to change the client name and unless I do so I corrupt two builds the new one and the old one with the same workspace name.

    This also means I never have to configure the workspace name once I set this param - my build is good to go ...

    I tried the following - which I presume isn't supported

  38. I am creating a matrix project to compile on windows and ubuntu. How do I specify the p4 binary location?

    1. Unknown User (john.bolton@quest.com)

      Specify the full path including the binary.

      For example, /usr/bin/p4 or C:\Program Files\Perforce\p4.exe.

      1. Right that's how you would do it on a single os build. In a matrix project I can tie the build to two slaves, one unix and the other windows. The perforce section asks for a p4 path. The p4 path is different on each os. So is it possible to enter two locations, leaving "Path to p4 executable" blank will not pick it up from the path. It seems to use a environment variable at execute time. Maybe a environment variable can be set per node, so if you leave it blank it picks up the environment variable...

        1. Unknown User (john.bolton@quest.com)

          Sorry I somehow missed that. (sad) I don't know the answer.

        2. If p4 exec is in the path of both windows and linux machines all you have to specify is p4 which will work for you.

          1. That doesn't work for me. We have windows slaves with perforce installed in different locations (e.g. c:/program files/p4.exe and e:/program files/p4.exe). The Perforce directory is already in the PATH but it still says "No output for: C:\Program Files\\Perforce
            p4.exe workspace -o xxxx-1970421364 " when executed on the machine with perforce installed on E drive.
            Is there any other chance as to install perforce in the same location on every slave?

  39. Unknown User (koblucki)

    I am developing a plugin that needs changelist number and the changelist owner but can't quite figure out how to get the last PerforceChangeLogEntry.  Could anyone help?

    Nevermind.  I must have been blind.

  40. Is there a way to get an email (or other alert trigger) when the Perforce Polling has failed? When someone changes the password, but forgets to update the P4PASSWD in Hudson, everything looks good on the surface, but no new builds are made since Hudson can't sync new source but it doesn't notify anyone that there is a problem.

    ---
    [workspace] $ /usr/bin/p4 workspace -o hudson
    [workspace] $ /usr/bin/p4 login -p
    [workspace] $ /usr/bin/p4 login -p
    Caught exception communicating with perforce. Login attempt failed: Password invalid.com.tek42.perforce.PerforceException: Login attempt failed: Password invalid.
    at com.tek42.perforce.parse.AbstractPerforceTemplate.p4Login(AbstractPerforceTemplate.java:488)
    at com.tek42.perforce.parse.AbstractPerforceTemplate.login(AbstractPerforceTemplate.java:430)
    at com.tek42.perforce.parse.AbstractPerforceTemplate.getPerforceResponse(AbstractPerforceTemplate.java:329)
    at com.tek42.perforce.parse.Workspaces.getWorkspace(Workspaces.java:53)
    at hudson.plugins.perforce.PerforceSCM.getPerforceWorkspace(PerforceSCM.java:951)
    at hudson.plugins.perforce.PerforceSCM.checkout(PerforceSCM.java:499)
    at hudson.model.AbstractProject.checkout(AbstractProject.java:1061)
    at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:479)
    at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:411)
    at hudson.model.Run.run(Run.java:1272)
    at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
    at hudson.model.ResourceController.execute(ResourceController.java:88)
    at hudson.model.Executor.run(Executor.java:129)
    ---

  41. Has anyone seen the following behavior:  If I navigate into a job and click on "Recent Changes", some comments that were supplied in Perforce do not show up.  The changelist, author, date all show up fine.  I have checked the comments from the p4 command line to make sure the whitespace is correct; I have compared them to other comments that do show up and cannot find any kind of whitespace difference.  This particular project also generates a maven site, and in the maven site, the comments show up.  It appears to be isolated to one user, but does not always happen to that user.  I also tried a completely different browser after re-doing the whitespace to be sure that it wasn't a whitespace issue and that it wasn't cached in the browser...no change.  The comments were submitted via P4V, but so were the ones that show up for this user.  Most other users in our environment use either Eclipse or the command line client.  The comments are definitely there, as shown by running p4 changes from the command line as well as p4 change -o <specific changelist number> (and looking at them from P4V, too). 

    Any ideas?

    Thanks.

    1. They're probably inserting something into their comments that the perforce plugin doesn't like. I recently fixed a problem where using reserved phrases (Such as "Job fixed" and "Affected files) will cause the changeset parsing to fail. If you are still having this issue with 1.1.10, please file a bug.

      I'll also note that the wiki page is a bad place to ask for help. Either ask the newsgroup, irc, or failing both of those you can email me directly.

  42. Unknown User (yonghsiang)

    Are there any plans in future releases to allow the plugin to get the changes without having to sync?

    1. What use would that have? If you really want to do it, you might be able to pull it off by having an empty client view, with the view mask set to the changes you want to pull into the changelog. Keep in mind that polling might not work if you do this.

      1. Unknown User (yonghsiang)

        I just prefer to have the management and syncing of clientspecs handled through scripts instead of the "Poll SCM" feature in multiple-configuration projects. I like the change history that the plugin generates in Hudson so I would really like to get this to work without having to sync files.

  43. We're starting to link change submissions to Perforce Jobs. I see the Job listed under "View Details" for the Hudson job. But if a change is linked to more than one Job, which Perforce allows, only one Job is displayed in the Hudson Job details. Some questions:

    Has anyone seen this behavior?

    Is there something I can do in our Hudson config to correct it?

    Does anyone know if it's fixed in a specific version of the Perforce plugin?

    Thanks!

    Paul M.

  44. I'd like to be able to use the Perforce label generated from this plugin as a parameter for a downstream job. Is this accessible as an environment variable I can pass to the downstream job?

    Thanks,
    Lester

  45. I added a comment to http://issues.jenkins-ci.org/browse/JENKINS-2678 which doesn't seem fixed.
    I also added a description of how I'd like to use the poll/sync behavior. Is it so strange?

    I would think a lot of people moving current build scripts to hudson would be starting in a similar situation (where the scripts are already perforce and changelist aware and base actions on their own results of doing these operations) and it's not that easy to extricate this from a pre-synced workspace. So I just want the plugin to track last successful CL and new CL and tell my script and a successbuild would update the last successful CL. But otherwise let the scripts do the syncing. It seems the options are there to do that (view mask with polling/syncing options) but it doesn't seem like the actual functionality matches what is described by these options.

    1. Please don't use the wiki comments for technical advice. Nobody checks it (See the disclaimer above). Either ask the mailing lists, irc, email the developers, or file an issue.

      I'll look into implementing a disable sync option, since the View Mask workaround doesn't seem to work well enough for your purposes.

  46. Hi, I'm using perforce plugin 1.3.0 and enabled Poll SCM to check perforce changes every 5 minutes. I used custom workspace "/home/dfu/main". Here is the configuration I have:

    But when start polling Perforce, I saw the following error in which it complained about missing Root field. But I didn't see a way in the above Perforce configuration area where we can set the P4ROOT. Any idea how I resolve this issue?
    Started on Aug 18, 2011 2:53:31 PM
    Looking for changes...
    Using node: Jenkins
    Using master perforce client: build-jenkins
    hudson $ /usr/local/bin/p4 workspace -o build-jenkins
    Changing P4 Client View from:

    Changing P4 Client View to:
    //depot/Iocaine/main/... //build-jenkins/...
    Saving new client build-jenkins
    hudson $ /usr/local/bin/p4 -s client -i
    Caught Exception communicating with perforce. Error in client specification. Missing required field 'Root'.
    For Command: /usr/local/bin/p4 -s client -i
    With Data:
    ===================
    Client: build-jenkins
    Description:
    Root:
    Options: noallwrite noclobber nocompress unlocked nomodtime normdir
    LineEnd: local
    View:
    //depot/Iocaine/main/... //build-jenkins/...

    ===================

    FATAL: Unable to communicate with perforce. Check log file for: Error in client specification. Missing required field 'Root'.
    For Command: /usr/local/bin/p4 -s client -i
    With Data:
    ===================
    Client: build-jenkins
    Description:
    Root:
    Options: noallwrite noclobber nocompress unlocked nomodtime normdir
    LineEnd: local
    View:
    //depot/Iocaine/main/... //build-jenkins/...

    ===================

    java.io.IOException: Unable to communicate with perforce. Check log file for: Error in client specification. Missing required field 'Root'.
    For Command: /usr/local/bin/p4 -s client -i
    With Data:
    ===================
    Client: build-jenkins
    Description:
    Root:
    Options: noallwrite noclobber nocompress unlocked nomodtime normdir
    LineEnd: local
    View:
    //depot/Iocaine/main/... //build-jenkins/...

    ===================

    at hudson.plugins.perforce.PerforceSCM.compareRemoteRevisionWith(PerforceSCM.java:858)
    at hudson.scm.SCM._compareRemoteRevisionWith(SCM.java:354)
    at hudson.scm.SCM.poll(SCM.java:371)
    at hudson.model.AbstractProject.poll(AbstractProject.java:1305)
    at hudson.triggers.SCMTrigger$Runner.runPolling(SCMTrigger.java:420)
    at hudson.triggers.SCMTrigger$Runner.run(SCMTrigger.java:449)
    at hudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:118)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
    at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
    at java.util.concurrent.FutureTask.run(FutureTask.java:138)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
    at java.lang.Thread.run(Thread.java:662)
    Done. Took 0.8 sec
    No changes

    1. Please don't use the wiki comments for technical advice. Nobody checks it (See the disclaimer above). Either ask the mailing lists, irc, email the developers, or file an issue.

  47. Is there any other environment variables that this plugin sets? I have a Jenkins job that uses a Python script to check out\in some files from our P4 repo. I have to pass in the P4 client workspace that the current job uses. I could hard code it , but when I run the the job on a slave node, the P4 workspace  has a number appended to it. Is there an environment variable that is set that reflects the current client workspace?

    D

    1. Obligatory "don't use the wiki comments for support".

      The plugin sets P4USER, P4CLIENT and optionally, P4PASSWD. you can get the client name from P4CLIENT, and if you need the full spec you can run perforce using 'p4 client -o $P4CLIENT'.

      1. Thanks Rob. When you say the plug-in sets P4CLIENT, you mean the internal P4 properties, correct? Not setting environment variables.

        1. I'm not sure what you mean by "internal P4 properties". P4CLIENT is an environment variable that is exposed to both the perforce commands that the plugin runs, and to the build environment to the user can make use of it in thier build scripts if they so wish.

  48. Does this plugin plan on supporting perforce streams?  Right now we are using perforce version 2011.1 and we are using "streams".  In the current plugin we have "ClientSpec" and "Mappings", but no options for streams.

  49. Hi,

    I am wondering is anyone know how to configure perforce plugin to remove the client spce form the perforce server after finish the build.

    if we use the Client name format for slaves  apends hash for the base name then perforce plugin creates the client spec for each build runnign on the slave

    Thanks,

    Venkat Annangi

    1. A couple things:

      - Clients are only created on a per job*slave basis. They are not created for every single build as you suggest.

      - A jobs client should never be deleted unless it's workspace is deleted as well. Deleting the client without wiping out the synced files will result in syncing problems on the next run.

      If you still want to delete the client spec, you can easily do so by adding "p4 client -d $P4CLIENT" to your build steps. I would still strongly advise against doing this, however.

      Can I ask why you want to have the client deleted after each run?

      1. Hi Rob,

         Thanks for getting back to my query. Clients created on the slave based on the configuration of your job. If you configured to append the hash for the base name then for each and every build on client will be created and appending the has is default option .if we don’t want to do that we can remove the hash so that it always creates the one client per job.
        If we want to use P4 command to delete it might remove the workspace and the artefact for the builds   one more issue with this is normal user cannot delete the client spec created by other user, in order to use this we might need to tweak the environmental variables point p4 user to super user on the box which we don’t want to do. So we want graceful deletion without affecting the workspace

        And answer to your question is if we don’t delete the clients perforce DB files will grow and creating check point is taking so much long and consumes large amount of space.

        Thanks,

        Venkat Annangi

        1. - The hash used in that field is the hashcode for the slave, not the build. Meaning only one client is created for each slave the job is executed on. Again the plugin does not create a new client spec for each and every build.

          - Removing the hash will result in the same client being used on multiple slaves. This is worse than deleting the client after each run, since each sync will be incomplete if you are using multiple slaves for your job.

          - 'p4 client -d $P4CLIENT' does not modify the filesystem. No files are deleted when you execute this command. Also note that when you run this command as a build step, it uses the same perforce user that created the client spec in the first place (the one defined in your perforce configuration) so there should be no permission issues.

          I hope this clears things up. Feel free to email me if you have any further questions.

          1. Hi Rob,

            Thanks for your inputs 

  50. I tried to use multiple SCM plugin to access to two different perforce servers in one jenkins job, wrote script code in powershell. Every time I build my job, it will automatically sync the work space (map to different subdirectory in the workspace), since my job contains two perforce clients, it needs to sync from two servers. But the changeset number is always the first server's, so when I came to the second server, there will be an issue, the second server has a much larger change set, it will take a long time to describe the change because the changeset number is from the first server, at last I met the OutOfMemory error:

    Building in workspace C:\jenkins\jobs\VCOPS_PLATFORM_AUTOTEST\workspace
    Using master perforce client: VCOPSPLAT_STATS_SANDBOX
    [workspace] $ C:\perforce-r10.2\p4.exe workspace -o VCOPSPLAT_STATS_SANDBOX

    Last build changeset: 129940

    [workspace] $ C:\perforce-r10.2\p4.exe changes -s submitted -m 1 //...
    [workspace] $ C:\perforce-r10.2\p4.exe -s changes -s submitted //VCOPSPLAT_STATS_SANDBOX/... (129941,)129982
    Sync'ing workspace to changelist 129982.
    [workspace] $ C:\perforce-r10.2\p4.exe -s sync //VCOPSPLAT_STATS_SANDBOX/...@129982
    Sync complete, took 364 ms
    Using master perforce client: VCOPSPLAT_CLOUDVM_SANDBOX
    [workspace] $ C:\perforce-r10.2\p4.exe workspace -o VCOPSPLAT_CLOUDVM_SANDBOX

    Last build changeset: 129940

    [workspace] $ C:\perforce-r10.2\p4.exe changes -s submitted -m 1 //...
    [workspace] $ C:\perforce-r10.2\p4.exe -s changes -s submitted //VCOPSPLAT_CLOUDVM_SANDBOX/... (129941,)1934948
    [workspace] $ C:\perforce-r10.2\p4.exe describe -s 1934844
    [workspace] $ C:\perforce-r10.2\p4.exe -G where //...
    [workspace] $ C:\perforce-r10.2\p4.exe describe -s 1934765
    ...

    Is this due to perforce plugin or multiple SCM plugin? I have update to the latest plugins.

  51. Just curious to know. Is there any way I can have my jenkins monitor perforce workspace and trigger a build as soon as a developer checks in his code.. Is there any other plugin available for this job already. I know there is an option for Poll SCM , but it uses cron expression. I want the trigger to be driven by check ins.

    Appreciate you help.

    1. Well your cron expression can be really short . . . we use 5 minutes.

      If you don't want polling, then it really isn't a Jenkins issue.  You need to write a Perforce Trigger (assuming your Perforce admin allows that) that will kick Jenkins when the software arrives.

      It would be Perforce's job to proactively start the Jenkins job, not the other way around.

      Frank

  52. It would be nice if the Perforce Plugin had an option for processing only one changelist per Job run.  (To prevent the "dog pile" affect where several changelists participate in a given build.)

    I get this request from customers regularly as they want to be able to determine the EXACT PERSON that broke the build.

    I always explain the impact on their slaves, they are always sure they want it anyway.

    I'm not saying it would work well, in fact I get that in most cases it won't (the build backlog will just grow until you are processing last week's checking).

    It would be nice if the Perforce Plugin supported this JUST so I could easily turn it on and have them watch their servers bog down and die.

    As it stands now, I will be implementing this using two Jenkins jobs . . . one to "get the list of changelists" from Perforce which then runs a second job giving it a new changelist number each time.

    Frank

    1. I think that is something that would need to be supported by Jenkins core. There's currently no mechanism for running one build for every changeset discovered during polling.

      An alternative would be to simply use a parameterized build and a perforce post-commit trigger. Set it up to hit the build url with the specific changeset as a parameter, and it will queue up builds for every changeset as they are committed.

      1. I guess my thinking was that you already look for changes since the last job run . . . and then describe the list of changelists found.

        The only different is instead of moving to the last changelist found . . . move only to the first changelist found.

        I can wait for the next polling cycle (after the job completes) to discover the next changelist.

        BTW: Since I have your attention:

        I know P4_CHANGELIST contains the CL# we are moving to . . . is there a way from the job to get a list of the CL#s associated with this job (if there is more than one)?

        Frank

        1. I'm not sure if we can do that unless we lie to Jenkins during polling. The polling mechanism has changed so that both polling and syncing need to provide Jenkins with a state object so Jenkins can intelligently decide what to do on the next polling interval.

          As for your second question, the only way to get the list is to query Jenkins directly using one of it's APIs. There's no way to store that amount of data into something like an environment variable.

          If you have any more questions, feel free to shoot me an email. I don't usually pay attention to the wiki comments.

  53. It appears that the P4_CHANGELIST environment variable has disappeared. I have been using this variable for many months now and after I updated Jenkins to 1.502 along with a few plugins and voila this variable was no longer available. 

    Perforce plugin: 1.3.19

    Environment Injector plugin: 1.83

    1. I believe that's a problem with the EnvInject plugin. A lot of plugins have been having issues with it overwriting or removing environment variables. JENKINS-16637 describes one such example, so I imagine the other env variables would have the same problem.

      1. And as always, questions should go to the mailing list or the developers directly, and issues should go into the issue tracker. The wiki is a poor place to ask questions or report issues, as I've outlined above. Many people subscribe to the wiki page to get notifications of updates, and I don't like to spam their inboxes like I'm doing right now.

  54. I'd like to know how "poll SCM" works in the plugin? What is the p4 command running behind the scene to detect if code has been changed on Perforce?

    I'd like to write a bash/python script doing so instead of using the UI. Thanks!

    1. It's just a simple 'p4 changes -m 1 //workspace/...' command. It compares the last synced changeset number to the latest changeset available in the workspace. Why do you need to script this functionality instead of using the one already available?

      1. Hi Rob, due to system security reason, we can't save the P4 password in the plugin. If I need to implement that poll SCM feature in bash script, how could I do it?

        1. It would be quite difficult. You would first need to get the last synced changeset from Jenkins somehow, then compare it to the output of the command I posted above. Two other alternatives:

          - Log in on every machine you need to perform perforce actions on. The plugin will automatically use the ticket if there is one available.

          - Implement a perforce trigger that will start Jenkins builds remotely as checkins are performed.

          I don't check the wiki often, so please use email or irc if you have any further questions.

  55. I just wanted to warn people that I found a bug in the "quick clean" option leaving intermediate files in my build. I would not recommend using it until it's debugged and fixed.

    1. If anyone else runs into this, please update the ticket with as much information as possible: https://issues.jenkins-ci.org/browse/JENKINS-17439

      I regularly run quick clean on my builds, with hundreds of thousands of files in my workspace, and have never run into this issue. As you might imagine, that makes it incredibly difficult to debug. :(

  56. Support for Read-Only (replicant) Perforce server

    We have one of the larger Perforce installations and for it to scale we have put a read-only replicant server next to our regular Perforce server.  The read-only version lags the RW version by only a few seconds.

    We have been asked to move Jenkins Polling onto the RO server.  Unfortunately, because the Perforce Plugin updates the Perforce Client Spec and such, this isn't as straight forward as we at first thought.

    Basically, polling wants to be done against the RO server, but if ANY UPDATE command is required, then the plugin will need to revert to the main RW server for the remainder of that polling cycle.

    If I forked the depot and made the changes necessary for a RO/RW setup (under an advanced tab) would you be willing to take them into the main branch?   (Assuming they were done with quality and to whatever your current coding standard are, etc) . . . or is this setup just too "corner case" for you to consider merging into the main line?

    I really do NOT want to be holding some special version of the plugin on the side that I have to maintain moving forward . . . I don't want to take up this project unless there is at least a chance it would be accepted in the mainline.

    Frank

    1. Absolutely. Send off a pull request, and I'll review it.

      1. Cool! . . . I don't want this to be some skunk works project . . . let me get this approved so I can spend some quality time on it . . . once that is done . . . I'll go figure out "git" and be in touch.

        Frank

      2. So, looks like we aren't going to need this . . . I thought I would update you just in case you are interested.

        So our Perforce Read Only server is really . . . well . . . read-mostly.  You cannot check in a file, but you can for instance create a workspace and clientspec.  In this case this clientspec is NOT copied to the RW server.  (The RW server updates the RO server, but not the other way around.)  The IT guys like this, because in their view automation cspecs are not "business related" requiring full archive and backup.  So they are happy that all our "non-business" cspec aren't in their production database.  This definition grinds on me a little bit, but I sort of see their point, if the RO cspec is lost, Jenkins will just recreate it as needed.  (Yes, our Perforce archive is big enough and with enough users that points like this are becoming important.)

        So, we point the Perforce Plugin at the RO server and it runs just fine.

        Our build scripts are 99% read-only as well . . . very rare that they actually check into Perforce.  So for the most part, those scripts have problems pointing at the RO server as well.  In those rare rare cases, we switch to the RW server, copy the cspec from the RO server and proceed as normal for THAT COMMAND ONLY and then switch back to the RO server.

        I was skeptical at first, but it seems to be working well.

    2. Perforce's recommend solution here is to set up a broker. point all clients at the broker, which is configured to redirect RO commands to the replica and write commands to the main server.

      see: http://scm-perforce.blogspot.com/2010_12_05_archive.html

      1. Yeah, we are Perforce's flagship . . . we aren't just big, we are VERY BIG . . . We have broker too.  However, IT is asking for automation to stay off the even the broker where possible.

  57. thanks for the update to set disableChangeLogOnly.  however, it does not work.  setting disable changelogs, without setting disablesync, still gathers changelogs.

    seems like the default value is incorrect:

     

    boolean disableChangeLogOnly = overrideWithBooleanParameter("P4DISABLECHANGELOG", build, this.disableAutoSync);

    1. Issues should be reported in Jira. I'll take a look anyways...

  58. When two changeset commits are done in the same poll the plugin has a problem in building one at a time. It builds only the last one....

    There's an open bug regarding this issue:

    https://issues.jenkins-ci.org/browse/JENKINS-17889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel#issue-tabs

    Does anyone know when it's gonna be solved?

    Is there workaround meanwhile?

    Regarding the other solution of writing a Perforce post-commit trigger, I'm not the administrator of the environment so it might be a problem.

  59. Hello,

    I am wondering how I can access label tag (name) in groovy script (say in email plugin).

    I try to call getTag() from PerforceTagAction associated with build, however it returns null, meanwhile isTagged() returns true for builds with label and false without it.

    As I can see in code isTagged function is overriden in PerforceTagAction and it returns tag != null

    I am confused ... ;)

    Please help!

    1. You are looking at old code. You can have multiple tags, so you should be using getTags(), not getTag().

  60. I am using Performance plugin to display JMeter results.
    Is it possible to modify it to use Median values instead of Average values when "Performance Per Test Case Mode" is checked ?
    For example, by changing public void doRespondingTimeGraphPerTestCaseMode (?)

    1. This is the Perforce Plugin, not the Performance Plugin.

    2. This is the Perforce Plugin, not the Performance Plugin.

  61. Perhaps this is implied by the second bullet under "Quirks", but from what I can see parallel builds with multi-configuration jobs and the Perforce plugin do not appear to work. (One note: Our job is syncing to a label - not sure if this is relevant.) Because each configuration shares the Perforce clientspec of the top-level job, if two run at the same time only one seems to actually get any files and the other fails when it gets an empty workspace. The "Clean Workspace Before Each Build" checkbox is checked as recommended. If I check the "Run each configuration sequentially" checkbox, all the configurations complete successfully. But of course, one of the goals here is to be as efficient as possible (with a focus on time), so running in parallel is what we ultimately want to do.

    So first, I'd like to make sure I'm not missing something - am I?

    Assuming the answer is no, without any changes to how things are (Jenkins & plugin-wise), the only way to support parallel builds would seem to be converting each configuration to a stand-alone job with its own clientspec. This isn't ideal from a general job management standpoint, but also not a huge problem.

    What I'm wondering is if the Perforce plugin could create a separate clientspec for each configuration in multi-configuration jobs, with each configuration's clientspec name adding some suffix to the parent's clientspec name. Perhaps the naming convention could be configurable, but that wouldn't be too important. I can add a JIRA ticket to request this, but want to make sure it's reasonable (and that I'm not missing something) first.

    Thank you!

    1. Try putting

      ${JOB_NAME}

      in the name of your client spec. IIRC, it resolves to a different value for each matrix run.

      1. That worked! Somehow I just assumed that we wouldn't be able to use variables in workspace names and didn't even try it.

        Thank you for opening my eyes!

  62. Hi. Rob.

    I again have a troubles with cleaning ws.

    Workspace doesn't cleaning and I see error "Exception occurred while cleaning files: Invalid argument".

    === Log start =======================================================================

    15:05:51 Building on master in workspace c:\ProjectsA
    15:05:51 Using master perforce client: ProjectsA
    15:05:51 [ProjectsA] $ p4 workspace -o ProjectsA
    15:05:52 'Don't update client' is set. Not saving the client changes.
    15:05:52 Note: .repository directory in workspace (if exists) is skipped during clean.
    15:05:52 Quickly cleaning workspace...
    15:05:52 [ProjectsA] $ p4 -d c:\ProjectsA -x- have
    15:12:46 Exception occurred while cleaning files: Invalid argument
    15:13:40 Workspace is clean.
    15:13:40 Restoring changed and deleted files...
    15:13:40 [ProjectsA] $ p4 -d c:\ProjectsA -x- sync -f
    15:13:40 [ProjectsA] $ p4 -d c:\ProjectsA diff -se
    ...
    15:30:55 Process leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information - file(s) not in client view.
    15:30:55 [ProjectsA] $ p4 -d c:\ProjectsA -x- sync -f
    15:30:55 [ProjectsA] $ p4 -d c:\ProjectsA diff -sd
    15:37:10 //3rdparty/OpenSource/Zlib/1.2.8/zconf.h#2 - refreshing c:\ProjectsA\3rdparty\Zlib\zconf.h
    15:37:10 Files restored.
    15:37:10 Clean complete, took 1877997 ms
    15:37:10 Last build changeset: 456416
    15:37:10 [ProjectsA] $ p4 changes -s submitted -m 1 //ProjectsA/...
    15:37:10 [ProjectsA] $ p4 -s changes -s submitted //ProjectsA/...456416
    15:37:11 Sync'ing workspace to changelist 456416.
    15:37:11 [ProjectsA] $ p4 -s sync //ProjectsA/...@456416
    15:37:13 Sync complete, took 2463 ms
    15:05:51 Building on master in workspace c:\ProjectsA

    15:05:51 Using master perforce client: ProjectsA

    15:05:51 [ProjectsA] $ p4 workspace -o ProjectsA

    15:05:52 'Don't update client' is set. Not saving the client changes.

    15:05:52 Note: .repository directory in workspace (if exists) is skipped during clean.

    15:05:52 Quickly cleaning workspace...

    15:05:52 [ProjectsA] $ p4 -d c:\ProjectsA -x- have

    15:12:46 Exception occurred while cleaning files: Invalid argument

    15:13:40 Workspace is clean.

    15:13:40 Restoring changed and deleted files...

    15:13:40 [ProjectsA] $ p4 -d c:\ProjectsA -x- sync -f

    15:13:40 [ProjectsA] $ p4 -d c:\ProjectsA diff -se

    ...

    15:30:55 Process leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information - file(s) not in client view.

    15:30:55 [ProjectsA] $ p4 -d c:\ProjectsA -x- sync -f

    15:30:55 [ProjectsA] $ p4 -d c:\ProjectsA diff -sd

    15:37:10 //3rdparty/OpenSource/Zlib/1.2.8/zconf.h#2 - refreshing c:\ProjectsA\3rdparty\Zlib\zconf.h

    15:37:10 Files restored.

    15:37:10 Clean complete, took 1877997 ms

    15:37:10 Last build changeset: 456416

    15:37:10 [ProjectsA] $ p4 changes -s submitted -m 1 //ProjectsA/...

    15:37:10 [ProjectsA] $ p4 -s changes -s submitted //ProjectsA/...456416

    15:37:11 Sync'ing workspace to changelist 456416.

    15:37:11 [ProjectsA] $ p4 -s sync //ProjectsA/...@456416

    15:37:13 Sync complete, took 2463 ms

    === Log end =====================================================================

    C:\>p4 info

    ...
    Server version: P4D/LINUX26X86_64/2011.1/428451 (2012/03/08)
    Proxy version: P4P/LINUX26X86/2013.3/740675 (2013/11/11)
    Broker version: P4BROKER/LINUX26X86_64/2011.1/370818
    ...

    1. That issue happens only on huge workspaces with ~150 000+ files into it.

  63. Hi,

    I'd like t know how does the plugin detect "Last build changeset", since I've another script that needs the previous and the current changeset. I know that i can save $P4_CHANGELIST and save it, and then use p4 changes -m 1 //workspace/... if there are new changes on perforce. But i'd like to know how actually the plugin determines it since i ran into a problem in which i use another script to actually make the sync but then a timeout happened which caused an abortion in the project, but when new check-ins happen i can see the changes only from the last aborted build $P4_CHANGELIST till head changes not from not from Last build changeset of the previous project till the head.

    - To explain what i ran into is that i've for example 20 changes, 10 of them ran them were captured in one run in which i can see the changes but i do sync using separate script but this got aborted, so with the next run of the project i can see the changes from 10-20 not 1-20. If there is a way to reset the previous changeset if there is sync failure please let me know how to do it.

    - Also is there a way to push upstream project changes into downstream project changes? I've proj A which makes the syncing, then proj B which makes the build, I'd like to see perforce changes of proj A in the changes of proj B, I'm currently using Last build changes plugin to view the changes in upstream projects, but this doesn't help when pressing changes or trying to e-mail upstream committers (I had to do a groovy script to be able to mail upstream committers)

  64. Am seeing a lot of the below in our slave log just before it closes channel : Anyone else seen it ? Know what it is ? And what is the connection ( if any ) to the perforce plugin ? 

     900 WARNING: Process leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information

     901 java.lang.Exception
     902         at hudson.Proc$LocalProc.join(Proc.java:329)
     903         at hudson.plugins.perforce.HudsonP4RemoteExecutor$RemoteCall.call(HudsonP4RemoteExecutor.java:168)
     904         at hudson.plugins.perforce.HudsonP4RemoteExecutor$RemoteCall.call(HudsonP4RemoteExecutor.java:141)
     905         at hudson.remoting.UserRequest.perform(UserRequest.java:121)
     906         at hudson.remoting.UserRequest.perform(UserRequest.java:49)
     907         at hudson.remoting.Request$2.run(Request.java:324)
     908         at hudson.remoting.InterceptingExecutorService$1.call(InterceptingEx     ecutorService.java:68)
     909         at java.util.concurrent.FutureTask.run(FutureTask.java:262)
     910         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecu     tor.java:1145)
     911         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExec     utor.java:615)
     912         at java.lang.Thread.run(Thread.java:745)
     913 

Write a comment…