[JIRA] (JENKINS-13844) Emulate clean checkout by... does not work with 1.7 subversion repositories
Martin Adam commented on JENKINS-13844 Emulate clean checkout by... does not work with 1.7 subversion repositories Does this explain not deleting unversioned files as well? Because you're mentioning only ignored files... This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13844) Emulate clean checkout by... does not work with 1.7 subversion repositories
Chris Lee commented on JENKINS-13844 Emulate clean checkout by... does not work with 1.7 subversion repositories No. There is more to this issue than just the ignored files. Here's a test case from a simple Jenkins / SVN (Jenkins 1.483, SVN 1.7): After wiping out the workspace and running an initial build: [root@devemr01 UTIL_TRUNK]# ll total 24 drwxrwxr-x 10 jenkins jenkins 4096 Sep 30 00:06 build -rw-rw-r-- 1 jenkins jenkins 376 Sep 30 00:06 build.gradle drwxrwxr-x 2 jenkins jenkins 4096 Sep 30 00:06 lib drwxrwxr-x 2 jenkins jenkins 4096 Sep 30 00:06 releng -rw-rw-r-- 1 jenkins jenkins 37 Sep 30 00:06 settings.gradle drwxrwxr-x 4 jenkins jenkins 4096 Sep 30 00:06 src ...adding an unversioned file: [root@devemr01 UTIL_TRUNK]# touch foo [root@devemr01 UTIL_TRUNK]# svn status ? foo Running the job (note that the unversioned file wasn't detected or removed): 00:07:59 Cleaning up /home/jenkins/workspace/UTIL_TRUNK/. 00:07:59 Updating svn://svn.ma.net/util/trunk to revision '2012-09-30T00:07:58.927 -0700' 00:07:59 At revision 38394 ...and the unversioned file, and the ignored dir 'build', are still present: [root@devemr01 UTIL_TRUNK]# ll total 24 drwxrwxr-x 10 jenkins jenkins 4096 Sep 30 00:06 build -rw-rw-r-- 1 jenkins jenkins 376 Sep 30 00:06 build.gradle -rw-r--r-- 1 rootroot 0 Sep 30 00:07 foo drwxrwxr-x 2 jenkins jenkins 4096 Sep 30 00:06 lib drwxrwxr-x 2 jenkins jenkins 4096 Sep 30 00:06 releng -rw-rw-r-- 1 jenkins jenkins 37 Sep 30 00:06 settings.gradle drwxrwxr-x 4 jenkins jenkins 4096 Sep 30 00:06 src [root@devemr01 UTIL_TRUNK]# It appears that the SVNKit 'status' API call is working differently (and possibly incorrectly) for SVN 1.7 repositories. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12861) klocwork - update to recognize 9.5.x xml schema
Waldek M commented on JENKINS-12861 klocwork - update to recognize 9.5.x xml schema OK, so let me rephrase it; perhaps I wasn't too clear, indeed. Is there a way that I could gather some more detailed logs from the Klocwork plugin? Waldek This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15344) Publishing Findbugs analysis report on a multi-module maven project results in ClassCastException
Thomas Zlika commented on JENKINS-15344 Publishing Findbugs analysis report on a multi-module maven project results in ClassCastException According to the stack trace, it seems to be a class loading problem with dom4j. Using mvn dependency:tree, we can see that dom4j is used twice with 2 slightly different versions: dom4j:dom4j:jar:1.6.1:compile is a transitive dependency of org.jvnet.hudson.plugins.findbugs:library:jar:2.0.1-SNAPSHOT org.jvnet.hudson.dom4j:dom4j:jar:1.6.1-hudson-3:provided is a transitive dependency of org.jenkins-ci.main:jenkins-core:jar:1.409:provided In FindBugsParser.readXml(), where the bug occurs, you change the context class loader. And I can see in the stack trace that an async task is launched in a ThreadPoolExecutor, so the thread in the executor is certainly not using the class loader you tried to impose in FindBugsParser.readXml(), isn't it ? Maybe a quick-and-dirty workaround would be to explicitly exclude dom4j:dom4j:jar:1.6.1 when configuring the findbugs dependency ? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-9785) on OSX a java icon jump on dock for all starting maven build and takes focus
Ulli Hafner edited a comment on JENKINS-9785 on OSX a java icon jump on dock for all starting maven build and takes focus This does not completely work on my machine: 10.8.2 Mountain Lion, Java 6, Maven 3.0.4: When running surefire tests there pop ups a Dock icon for the java process surefire.booter.ForkedBooter. Is there a maven option available to suppress that? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-9785) on OSX a java icon jump on dock for all starting maven build and takes focus
Ulli Hafner reopened JENKINS-9785 on OSX a java icon jump on dock for all starting maven build and takes focus This does not completely work on my machine: 10.8.2 Mountain Lion, Java 6, Maven 3.0.4: When running surefire tests there pop ups a Dock Icon for the java process surefire.booter.ForkedBooter. Is there a maven option available to suppress that? Change By: Ulli Hafner (30/Sep/12 2:11 PM) Resolution: Fixed Status: Resolved Reopened This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15361) Usability: selection buttons like add post-build action should close on escape
Ulli Hafner created JENKINS-15361 Usability: selection buttons like add post-build action should close on escape Issue Type: Bug Assignee: Unassigned Components: core Created: 30/Sep/12 2:19 PM Description: When I'm clicking a "selection button" (a button that opens a list of selectable string options) then a popup menu opens that shows the list of available options. This option menu should close when either pressing the escape key or when clicking outside of the menu. Currently, you need to click again on that button to close the popup. This behavior is not intuitive. Project: Jenkins Priority: Minor Reporter: Ulli Hafner This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13844) Emulate clean checkout by... does not work with 1.7 subversion repositories
Chris Lee
commented on JENKINS-13844
Emulate clean checkout by... does not work with 1.7 subversion repositories
Found the issue; the status objects returned by SVNKit have different values when used against a SVN 1.7 working copy.
Using the original snippet of code, status objects are returned for the correct files, but their status is STATUS_NONE, and hence the subsequent logic for removing files of specific statuses is not triggered:
/home/jenkins/workspace/UTIL_TRUNK/.gradlenone
/home/jenkins/workspace/UTIL_TRUNK/foonone
/home/jenkins/workspace/UTIL_TRUNK/build none
Modifying the code to combine the node contents status yields the correct results:
/home/jenkins/workspace/UTIL_TRUNK/.gradle ignored
Deleting /home/jenkins/workspace/UTIL_TRUNK/.gradle
/home/jenkins/workspace/UTIL_TRUNK/foo unversioned
Deleting /home/jenkins/workspace/UTIL_TRUNK/foo
/home/jenkins/workspace/UTIL_TRUNK/build ignored
The relevant change is:
// for SVN 1.7 working copies, status.getContentsStatus() is STATUS_NONE; need to use the combined status to get the correct status (UNVERSIONED, IGNORED, etc.)
SVNStatusType s = status.getCombinedNodeAndContentsStatus();
//SVNStatusType s = status.getContentsStatus();
The complete test harness is:
import java.io.File;
import java.util.*;
import org.tmatesoft.svn.core.SVNDepth;
import org.tmatesoft.svn.core.SVNException;
import org.tmatesoft.svn.core.wc.ISVNStatusHandler;
import org.tmatesoft.svn.core.wc.SVNClientManager;
import org.tmatesoft.svn.core.wc.SVNStatus;
import org.tmatesoft.svn.core.wc.SVNStatusType;
import org.tmatesoft.svn.core.wc.*;
import org.tmatesoft.svn.core.internal.wc.*;
public class Test
{
public static void main( String[] args ) throws SVNException
{
SVNClientManager clientManager = SVNClientManager.newInstance();
CollectionString changeLists = Collections.emptyList();
//clientManager.getStatusClient().doStatus( new File( args[ 0 ] ).getAbsoluteFile(), SVNRevision.WORKING, SVNDepth.INFINITY, false, false, true, false, new ISVNStatusHandler()
clientManager.getStatusClient().doStatus( new File( args[ 0 ] ), null, SVNDepth.INFINITY, false, false, true, false, new ISVNStatusHandler()
{
@Override
public void handleStatus( SVNStatus status ) throws SVNException
{
// for SVN 1.7 working copies, status.getContentsStatus() is STATUS_NONE; need to use the combined status to get the correct status (UNVERSIONED, IGNORED, etc.)
SVNStatusType s = status.getCombinedNodeAndContentsStatus();
//SVNStatusType s = status.getContentsStatus();
System.out.printf( "%-60s %s\n", status.getFile(), s );
if( s == SVNStatusType.STATUS_UNVERSIONED || s == SVNStatusType.STATUS_IGNORED || s == SVNStatusType.STATUS_MODIFIED )
{
System.out.println( "Deleting " + status.getFile() );
}
}
}, null );
}
}
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13367) Feature request: Checkout ignoring specific folders
Jørgen Tjernø closed JENKINS-13367 as Wont Fix Feature request: Checkout ignoring specific folders This isn't something that belongs in pathignore - it's a feature request for the SCM plugin you're using. Change By: Jørgen Tjernø (30/Sep/12 4:11 PM) Status: Open Closed Resolution: WontFix This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15257) delay before joining channel no longer working
kutzi edited a comment on JENKINS-15257 delay before joining channel no longer working I'm not quite sure that I understand what the issue at hand is: you say that the delay is not working anymore - how does this manifest? And what do you exactly mean with your last sentence: "I'd love to see a way to delay executing joins after auth or similar, such as its possible to have the proper auth before joining resolving issues surrounding the lack of other "perform" or configurables in the bot in general." ? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14808) IOException: Unable to delete FileName on Windows Slaves
Ralf Mühle commented on JENKINS-14808 IOException: Unable to delete FileName on Windows Slaves workaroung: install Pre SCM BuildStep Plugin and execute as pre-scm step the following ant-script ?xml version="1.0"? project default="clean" target name="clean" description="clean" delete dir="dirToDelete"/ /target /project This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13859) Emulate clean check out seems to fail after upgrading to v1.4 of subversion plugin
Chris Lee commented on JENKINS-13859 Emulate clean check out seems to fail after upgrading to v1.4 of subversion plugin The solution for this (requires a code change) is detailed in JENKINS-13844 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14932) Compact encoding for timestamps, alternative to console note encoding
stevengbrown updated JENKINS-14932 Compact encoding for timestamps, alternative to console note encoding Change By: stevengbrown (01/Oct/12 3:46 AM) Description: TheTimestamperplugincurrentlyinsertsaconsolenoteintoeverylineofthebuildslogfile.[Consolenotes|http://javadoc.jenkins-ci.org/byShortName/ConsoleNote]areafeaturesupportedbyJenkins.Theyallowthetimestampstobeformattedatthetimetheconsoleisviewed,ratherthanthetimethatthebuildwasrunning.Anyalternativesolutionalsoneedstosupportformattingatviewtime.Insertingaconsolenoteintoeveryline,astheTimestamperplugindoes,increasesthesizeofthelogfileandmakesthefilemoredifficulttoreadinatexteditor. Arguably,itmayalsomakeitmoredifficultforexternaltools(scriptsandotherplugins)toparsetheconsolelog.AlthoughJenkinswillalreadyinsertconsolenoteswithouttheTimestamperplugininstalled,theTimestamperplugininsertsmanymoreofthemandsoithasexposedbugsinotherplugins. Itwouldbenicetostorethetimestampsinaseparatefiletotheconsole,andinamoreefficientformat.TheTimestamperpluginwouldstillneedawaytoinsertthesetimestampsbackintotheconsolewhenitisbeingviewedinJenkins.Backwardscompatibility:*TheTimestamperpluginshouldtoretaintheabilitytodisplayexistingconsolenotes.*Thereshouldbeanoptiontostilluseconsolenotes,becauseafewpeoplehavewrittenscriptstoreadthemfromthelogfile.*The/timestampsURL(introducedinversion1.3.2)mustcontinuetoreadtheconsolenoteswhenthisoptionhasbeenselected. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15315) Slave polling hungup
Alexey Larsky commented on JENKINS-15315 Slave polling hungup Thanks Rob. I have updated p4 to P4/NTX64/2012.1/490371 (2012/07/02) from 2010.1 on server and client. In workspace's names using only dots and underscores. I will check issue on updated version. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14932) Compact encoding for timestamps, alternative to console note encoding
stevengbrown commented on JENKINS-14932 Compact encoding for timestamps, alternative to console note encoding Implemented by https://github.com/jenkinsci/timestamper-plugin/commit/4526be28a9fd863e8d39ad7ebf811ec2978a3023 To be included in the Timestamper 1.4 release. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
