[JIRA] [multijob-plugin] (JENKINS-30906) MultiJobBuild.SubBuild does not contain full job name (if using folders)
Title: Message Title Vasili Galka commented on JENKINS-30906 Re: MultiJobBuild.SubBuild does not contain full job name (if using folders) Hi Chen, I'm not interested in the container. I'm interested in the AbstractBuild corresponding to the SubBuild (the sub-job that was executed). Regards, Vasili Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [multijob-plugin] (JENKINS-30906) MultiJobBuild.SubBuild does not contain full job name (if using folders)
Title: Message Title Vasili Galka commented on JENKINS-30906 Re: MultiJobBuild.SubBuild does not contain full job name (if using folders) Hi Chen Cohen, But my question was, how do I get the mjb corresponding to the subBuild? Best, Vasili Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [multijob-plugin] (JENKINS-30906) MultiJobBuild.SubBuild does not contain full job name (if using folders)
Title: Message Title Vasili Galka commented on JENKINS-30906 Re: MultiJobBuild.SubBuild does not contain full job name (if using folders) Hi hagzag, My apologies for unclear explanation. Let me explain in more detail: Say we have the following job configuration: MultiJob1 Phase1 MyFolder/Job1 Suppose this job was executed and it resulted in build MultiJob1 #1 which in turn executed build MyFolder/Job1 #5. Now, say we write some Java/Groovy code that needs to access this information. For instance, in my specific case I was designing some Email generating code. The code has reference to MultiJobBuild object describing MultiJob1 #1: MultiJobBuild build1; SubBuild subBuild = build1.getBuilders().get(0); // subBuild.getBuildNumber() is 5 // subBuild.getJobName() is "Job1" // There is no "MyFolder/Job1" info in the subBuild object. How do I obtain AbstractBuild object for this subBuild? As far as I understand there is no enough info for that in the SubBuild object. Best, Vasili Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [multijob-plugin] (JENKINS-30906) MultiJobBuild.SubBuild does not contain full job name (if using folders)
Title: Message Title
Vasili Galka edited a comment on JENKINS-30906
Re: MultiJobBuild.SubBuild does not contain full job name (if using folders)
Hi [~hagzag],My apologies for unclear explanation. Let me explain in more detail:Say we have the following job configuration:{noformat}MultiJob1Phase1 MyFolder/Job1{noformat}Suppose this job was executed and it resulted in build _MultiJob1 #1_ which in turn executed build _MyFolder/Job1 #5_.Now, say we write some Java/Groovy code that needs to access this information. For instance, in my specific case I was designing some Email generating code. The code has reference to *MultiJobBuild* object describing _MultiJob1 #1_:{code:java}MultiJobBuild build1;SubBuild subBuild = build1.getBuilders().get(0);// subBuild.getBuildNumber() is 5// subBuild.getJobName() is "Job1"// There is no "MyFolder/Job1" info in the subBuild object.{code} How do I want to obtain AbstractBuild object for this describing _MyFolder/Job1 #5_ basing on the information in subBuild . But how can I do it ? As far as I understand there is no enough info for that in the SubBuild object.Best,Vasili
Add Comment
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] [multijob-plugin] (JENKINS-30906) MultiJobBuild.SubBuild does not contain full job name (if using folders)
Title: Message Title Vasili Galka updated an issue Jenkins / JENKINS-30906 MultiJobBuild.SubBuild does not contain full job name (if using folders) Change By: Vasili Galka Attachment: build.png Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [multijob-plugin] (JENKINS-30906) MultiJobBuild.SubBuild does not contain full job name (if using folders)
Title: Message Title Vasili Galka commented on JENKINS-30906 Re: MultiJobBuild.SubBuild does not contain full job name (if using folders) Hi Chen, No, I don't refer to the project class. I have mentioned the MultiJobBuild.SubBuild class. It contains info about specific build that took place, like #123 you know... See the attached picture. The code building this page has no simple way to know the job was Foo/SvnUpdate. Best, Vasili Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [multijob-plugin] (JENKINS-30906) MultiJobBuild.SubBuild does not contain full job name (if using folders)
Title: Message Title Vasili Galka commented on JENKINS-30906 Re: MultiJobBuild.SubBuild does not contain full job name (if using folders) hagzag As far as I know, project.getFullName() gives the full path e.g. FooFolder/BarFolder/JobA Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [job-dsl-plugin] (JENKINS-30826) 'logDeprecationWarning is deprecated' warnings
Title: Message Title Vasili Galka commented on JENKINS-30826 Re: 'logDeprecationWarning is deprecated' warnings Thank you! That helped Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [job-dsl-plugin] (JENKINS-30826) 'logDeprecationWarning is deprecated' warnings
Title: Message Title Vasili Galka resolved as Fixed Jenkins / JENKINS-30826 'logDeprecationWarning is deprecated' warnings Change By: Vasili Galka Status: Open Resolved Resolution: Fixed Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [job-dsl-plugin] (JENKINS-30826) 'logDeprecationWarning is deprecated' warnings
Title: Message Title Vasili Galka closed an issue as Fixed Jenkins / JENKINS-30826 'logDeprecationWarning is deprecated' warnings Change By: Vasili Galka Status: Resolved Closed Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [job-dsl-plugin] (JENKINS-30826) 'logDeprecationWarning is deprecated' warnings
Title: Message Title Vasili Galka commented on JENKINS-30826 Re: 'logDeprecationWarning is deprecated' warnings Daniel Spilker Hi Daniel, can you please take a look at this? So far I have understood that you deprecated "job", "prop" and "sameNode". As for the first, I understand it shall just be replaced by "phaseJob" to fix the warning. But what is the new syntax for the other two? Thanks! Vasili Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [multijob-plugin] (JENKINS-30906) MultiJobBuild.SubBuild does not contain full job name (if using folders)
Title: Message Title Vasili Galka created an issue Jenkins / JENKINS-30906 MultiJobBuild.SubBuild does not contain full job name (if using folders) Issue Type: Bug Assignee: Unassigned Components: multijob-plugin Created: 12/Oct/15 2:30 PM Priority: Minor Reporter: Vasili Galka When using the MultiJob plugin with the CloudBees folder plugin, the MultiJobBuild.SubBuild class contains only the short job name. For example if we have 'MultiJobA' which runs job 'FolderFoo/JobB' as subtask, the info about the build does not contain 'FolderFoo/JobB' but only 'JobB' (the contained URL is fine). Thus, there is no easy way to understand which JobB was executed. Add Comment
[JIRA] [multijob-plugin] (JENKINS-30906) MultiJobBuild.SubBuild does not contain full job name (if using folders)
Title: Message Title Vasili Galka commented on JENKINS-30906 Re: MultiJobBuild.SubBuild does not contain full job name (if using folders) @ hagzag Haggai, any chance you can take a look on this? Many thanks! Vasili Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [multijob-plugin] (JENKINS-30906) MultiJobBuild.SubBuild does not contain full job name (if using folders)
Title: Message Title Vasili Galka commented on JENKINS-30906 Re: MultiJobBuild.SubBuild does not contain full job name (if using folders) hagzag Haggai, any chance you can take a look on this? Many thanks! Vasili1 Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [multijob-plugin] (JENKINS-30906) MultiJobBuild.SubBuild does not contain full job name (if using folders)
Title: Message Title Vasili Galka updated an issue Jenkins / JENKINS-30906 MultiJobBuild.SubBuild does not contain full job name (if using folders) Change By: Vasili Galka Comment: @ hagzag Haggai, any chance you can take a look on this? Many thanks! Vasili Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [multijob-plugin] (JENKINS-30906) MultiJobBuild.SubBuild does not contain full job name (if using folders)
Title: Message Title Vasili Galka edited a comment on JENKINS-30906 Re: MultiJobBuild.SubBuild does not contain full job name (if using folders) [~hagzag] Haggai, any chance you can take a look on this? Many thanks! Vasili1 Vasili Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [job-dsl-plugin] (JENKINS-30348) Additional classpath locks up JAR files
Title: Message Title Vasili Galka commented on JENKINS-30348 Re: Additional classpath locks up JAR files Daniel Spilker Sorry for delayed reply, we had long holidays here... Indeed, I verified and version 1.39 solves the issue. Many thanks! Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [job-dsl-plugin] (JENKINS-30826) 'logDeprecationWarning is deprecated' warnings
Title: Message Title
Vasili Galka created an issue
Jenkins / JENKINS-30826
'logDeprecationWarning is deprecated' warnings
Issue Type:
Bug
Assignee:
Daniel Spilker
Components:
job-dsl-plugin
Created:
07/Oct/15 4:05 PM
Priority:
Minor
Reporter:
Vasili Galka
Hi,
I have some DSL code which looks like:
jobFactory.multiJob("MainJob")
{
...
steps
{
phase("Phase A") {
job("JobA") { sameNode() }
}
phase("PhaseB") {
job("jobB") {
prop("PLATFORM", 'Win32')
prop("CONFIGURATION", 'Release')
sameNode()
}
continuationCondition("UNSTABLE")
}
}
...
}
When I run this code from a seed job, I get the following warnings:
Warning: (Seed.groovy, line 35) logDeprecationWarning is deprecated
Warning: (Seed.groovy, line 39) logDeprecationWarning is deprecated
...
Where the line numbers correspond to all the "job" and "prop" lines. I'm I doing something wrong? I think these warnings appeared when I upgraded the Job DSL addon to version 1.39.
[JIRA] [job-dsl-plugin] (JENKINS-30826) 'logDeprecationWarning is deprecated' warnings
Title: Message Title
Vasili Galka updated an issue
Jenkins / JENKINS-30826
'logDeprecationWarning is deprecated' warnings
Change By:
Vasili Galka
Hi,I have some DSL code which looks like:{noformat}jobFactory.multiJob("MainJob"){ ... steps { phase("Phase A") { job("JobA") { sameNode() } } phase("PhaseB") { job("jobB") { prop("PLATFORM", 'Win32') prop("CONFIGURATION", 'Release') sameNode() } continuationCondition("UNSTABLE") } } ...}{noformat}When I run this code from a seed job, I get the following warnings:{noformat}Warning: (Seed.groovy, line 35) logDeprecationWarning is deprecatedWarning: (Seed.groovy, line 39) logDeprecationWarning is deprecated...{noformat}Where the line numbers correspond to all the "job" and "prop" lines. Am I 'm I doing something wrong? I think these warnings appeared when I upgraded the Job DSL addon to version 1.39.
Add Comment
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-30721) Filesets on Windows shall be case insensitive
Title: Message Title Vasili Galka commented on JENKINS-30721 Re: Filesets on Windows shall be case insensitive Ok, I agree. The other is older and seems a better solution, since it is configurable. Let's close this one as duplicate. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-30721) Filesets on Windows shall be case insensitive
Title: Message Title Vasili Galka closed an issue as Duplicate Duplicate of JENKINS-5253 Jenkins / JENKINS-30721 Filesets on Windows shall be case insensitive Change By: Vasili Galka Status: Open Closed Resolution: Duplicate Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-30721) Filesets on Windows shall be case insensitive
Title: Message Title Vasili Galka created an issue Jenkins / JENKINS-30721 Filesets on Windows shall be case insensitive Issue Type: Bug Assignee: Unassigned Components: core Created: 30/Sep/15 2:15 PM Priority: Major Reporter: Vasili Galka For historical reasons Windows filesystem is case insensitive (unfortunately). Although the filesystem does store case, frequently the users don't have control over the case of created file/folder names. Windows users expect all tools to be case agnostic. However, this is not the current situation with Jenkins. For example, for ArtifactDeployer Plugin on Windows, setting "Artifacts to deploy" to "Foo/**" will deploy nothing if the filesystem folder is called "foo". This is clearly not a behaviour Windows user would expect. Similar issue happens with JUnit Plugin. The problem root is in the usage of Ant FileSet class which is by default case sensitive (although it can be set to ignore case). Add Comment
[JIRA] [subversion-plugin] (JENKINS-30141) Allow the user to choose sticky/non-sticky depth
Title: Message Title Vasili Galka stopped work on JENKINS-30141 Change By: Vasili Galka Status: In Progress Open Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [multijob-plugin] (JENKINS-30364) Visualization is misleading when using parametrized jobs
Title: Message Title Vasili Galka created an issue Jenkins / JENKINS-30364 Visualization is misleading when using parametrized jobs Issue Type: Improvement Assignee: Unassigned Attachments: MJ_Twice.png Components: multijob-plugin Created: 09/Sep/15 12:14 PM Priority: Major Reporter: Vasili Galka Say we have a multijob which runs some parameterized job. The problem is that the nice table showing the job status always refers to latest run of the parameterized job, no matter if it was triggered from this given multijob or from other place (which could have been with completely different parameters). A more complicated example (parameterized job Param_Pipeline is used TWICE with different parameters): When the multijob is executing, it does not show the progression right - once the 1st (Release phase) Param_Pipeline is running, the second (Debug phase) is being shown executed too, which is not reflecting the reality.
[JIRA] [job-dsl-plugin] (JENKINS-30348) Additional classpath locks up JAR files
Title: Message Title Vasili Galka commented on JENKINS-30348 Re: Additional classpath locks up JAR files I also attempted another workaround, by placing the JARs outside of the workspace. Unfortunately, it seems the "Additional classpath" field does not allow absolute paths (which could have been a nice feature too, and probably deserves a separate issue here). Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [job-dsl-plugin] (JENKINS-30348) Additional classpath locks up JAR files
Title: Message Title Vasili Galka commented on JENKINS-30348 Re: Additional classpath locks up JAR files Not yet. I will try. However, the existence of workaround does not contradict the existence of the bug Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [job-dsl-plugin] (JENKINS-30348) Additional classpath locks up JAR files
Title: Message Title Vasili Galka created an issue Jenkins / JENKINS-30348 Additional classpath locks up JAR files Issue Type: Bug Assignee: Daniel Spilker Components: job-dsl-plugin Created: 08/Sep/15 2:15 PM Priority: Critical Reporter: Vasili Galka Configuration: Jenkins 1.625, job-dsl-plugin 1.37, OS Windows 2012R2 I have a job containing: 1. Clean SVN checkout 2. Gradle step that obtains some dependency libraries. 3. "Process Job DSLs" step that uses these libraries in Groovy script. The job was created basing on example from https://github.com/jenkinsci/job-dsl-plugin/wiki/User-Power-Moves#using-libraries Running this job twice, returns an error on second run. The checkout fails since Java still locks the JAR files: Cleaning local Directory . java.nio.file.FileSystemException: d:\workspace\m\.\lib\antlr-runtime-3.4.jar: The process cannot access the file because it is being used by another process. at sun.nio.fs.WindowsException.translateToIOException(Unknown Source) at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source) at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source) at sun.nio.fs.WindowsFileSystemProvider.implDelete(Unknown Source) at sun.nio.fs.AbstractFileSystemProvider.delete(Unknown Source) at java.nio.file.Files.delete(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at
[JIRA] [job-dsl-plugin] (JENKINS-30348) Additional classpath locks up JAR files
Title: Message Title
Vasili Galka updated an issue
Jenkins / JENKINS-30348
Additional classpath locks up JAR files
Change By:
Vasili Galka
*Configuration:* Jenkins 1.625, job-dsl-plugin 1.37, OS Windows 2012R2I have a job containing:1. Clean SVN checkout2. Gradle step that obtains some dependency libraries.3. "Process Job DSLs" step that uses these libraries in Groovy script.The job was created basing on this example from : https://github.com/jenkinsci/job-dsl-plugin/wiki/User-Power-Moves#using-librariesRunning this job twice, returns an error on second run. The checkout fails since Java still locks the JAR files:{noformat}Cleaning local Directory .java.nio.file.FileSystemException: d:\workspace\m\.\lib\antlr-runtime-3.4.jar: The process cannot access the file because it is being used by another process. at sun.nio.fs.WindowsException.translateToIOException(Unknown Source) at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source) at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source) at sun.nio.fs.WindowsFileSystemProvider.implDelete(Unknown Source) at sun.nio.fs.AbstractFileSystemProvider.delete(Unknown Source) at java.nio.file.Files.delete(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at hudson.Util.deleteFile(Util.java:247) at hudson.Util.deleteRecursive(Util.java:310) at hudson.Util.deleteContentsRecursive(Util.java:212) at hudson.Util.deleteRecursive(Util.java:301) at hudson.Util.deleteContentsRecursive(Util.java:212) at hudson.scm.subversion.CheckoutUpdater$1.perform(CheckoutUpdater.java:81) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:162) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:992) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:973) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:949) at hudson.FilePath.act(FilePath.java:991) at hudson.FilePath.act(FilePath.java:969) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:898) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:834) at hudson.scm.SCM.checkout(SCM.java:485) at hudson.model.AbstractProject.checkout(AbstractProject.java:1277) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:610) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:532) at hudson.model.Run.execute(Run.java:1741) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:98) at hudson.model.Executor.run(Executor.java:408)Finished: FAILURE{noformat}I found someone already reported similar problem few months ago, but no issue was opened: https://groups.google.com/forum/#!topic/job-dsl-plugin/zwSgrtJhOLc
[JIRA] [subversion-plugin] (JENKINS-30141) Allow the user to choose sticky/non-sticky depth
Title: Message Title Vasili Galka commented on JENKINS-30141 Re: Allow the user to choose sticky/non-sticky depth Implemented. Pull request: https://github.com/jenkinsci/subversion-plugin/pull/134 Example of case when this can come handy: JENKINS-2717 Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [subversion-plugin] (JENKINS-30141) Allow the user to choose sticky/non-sticky depth
Title: Message Title Vasili Galka created an issue Jenkins / JENKINS-30141 Allow the user to choose sticky/non-sticky depth Issue Type: Improvement Assignee: Unassigned Components: subversion-plugin Created: 26/Aug/15 8:45 AM Priority: Minor Reporter: Vasili Galka When using svn, user has two flags --depth and --set-depth, which allows to decide if the chosen update depth will be sticky or not. Sometimes it is desirable to choose this in Jenkins as well. Add Comment
[JIRA] [subversion-plugin] (JENKINS-2717) svn polling without checkout or update
Title: Message Title Vasili Galka commented on JENKINS-2717 Re: svn polling without checkout or update Proposed solution: Use svn update with non-sticky depth empty. This does not really update the files/folders in the working copy as desired. However, Jenkins does not currently support non-sticky depth settings (I implemented it, see JENKINS-30141). Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [subversion-plugin] (JENKINS-3580) Workspace deleted when subversion checkout happens
Title: Message Title Vasili Galka commented on JENKINS-3580 Re: Workspace deleted when subversion checkout happens Alexandru Gheorghe: I agree with Daniel Beck, what you described does not seem to be related to the initial point of this issue. Also, I don't fully understand what behaviour you expected. Can you please provide a manual list of svn commands that produce your desired behaviour? Then we can analyze how it differs from what Jenkins does. Beside Alexandru Gheorghe comment from 2015, can anyone please explain what is this issue about and why is it still opened? Does the initial problem still exist? I tried digging all the above history, but I fail to find a clear scenario description defining the problem. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
