[JIRA] (JENKINS-62044) EXCLUDE patterns can't protect directories included by "**"

2020-04-24 Thread andreas.ringlstet...@gmail.com (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 Andreas Ringlstetter updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-62044  
 
 
  EXCLUDE patterns can't protect directories included by "**"   
 

  
 
 
 
 

 
Change By: 
 Andreas Ringlstetter  
 

  
 
 
 
 

 
 Consider the following pipeline code:{code:java}void deleteOthers(List pathList) { def prefixes = [] for(path in pathList) {  def currentPrefix = path;  while(true) {   def prefixEnd = currentPrefix.lastIndexOf("/")   if(prefixEnd > 0) {currentPrefix = currentPrefix.substring(0, prefixEnd);prefixes.add(currentPrefix)   } else {break;   }  } } prefixes.unique()  def patterns = [] for(path in prefixes) {  patterns.add([   pattern: '/' + path,   type: 'EXCLUDE'  ]) } for(path in pathList) {  patterns.add([   pattern: '/' + path,   type: 'EXCLUDE'  ])  patterns.add([   pattern: '/' + path + '/**',   type: 'EXCLUDE'  ]) } patterns.add([  pattern: '/**/*',  type: 'INCLUDE' ])   cleanWs deleteDirs: true, patterns: patterns return}def keep = [ 'foo', 'foo2', 'bar/foo', 'bar/foo2', 'bar/foo3/bla']for(path in keep) { dir(path) {  writeFile file:'expected', text:''    }}writeFile file:'unexpected', text:''writeFile file:'bar/unexpected', text:'' writeFile file:'bar/foo3/unexpected', text:'' deleteOthers(keep){code}*Expected behavior:* All the listed directories listed in "keep" are preserved (as both the directories themselves, as well as all parents are explicitly excluded!) and the included files are preserved.Only the files created outside of directories listed in "keep" are expected to be removed.*Actual behavior:* Only the directories + paths "foo/expected" and "foo2/expected" are preserved. All the directories with a nested paths, relative to include pattern, are impossible to preserve.It appears as if excludes fail to apply to any directory, if the directory was matched using a non-empty{code:java}**{code}part of the INCLUDE wildcard. Directories only matched by a single star, or an empty double-star have their EXCLUDE rules evaluated correctly.For files, excludes are properly evaluated even if the INCLUDE was matching with a non-empty double-star.E.g. with "deleteDirs: false", all expected files are protected correctly.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment

[JIRA] (JENKINS-62044) EXCLUDE patterns can't protect directories included by "**"

2020-04-24 Thread andreas.ringlstet...@gmail.com (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 Andreas Ringlstetter updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-62044  
 
 
  EXCLUDE patterns can't protect directories included by "**"   
 

  
 
 
 
 

 
Change By: 
 Andreas Ringlstetter  
 

  
 
 
 
 

 
 Consider the following pipeline code:{code:java}void deleteOthers(List pathList) { def prefixes = [] for(path in pathList) {  def currentPrefix = path;  while(true) {   def prefixEnd = currentPrefix.lastIndexOf("/")   if(prefixEnd > 0) {currentPrefix = currentPrefix.substring(0, prefixEnd);prefixes.add(currentPrefix)   } else {break;   }  } } prefixes.unique()  def patterns = [] for(path in prefixes) {  patterns.add([   pattern: '/' + path,   type: 'EXCLUDE'  ]) } for(path in pathList) {  patterns.add([   pattern: '/' + path,   type: 'EXCLUDE'  ])  patterns.add([   pattern: '/' + path + '/**',   type: 'EXCLUDE'  ]) } patterns.add([  pattern: '/**/*',  type: 'INCLUDE' ])   cleanWs deleteDirs: true, patterns: patterns return}def keep = [ 'foo', 'foo2', 'bar/foo', 'bar/foo2', 'bar/foo3/bla']for(path in keep) { dir(path) {  writeFile file:'expected', text:''    }}writeFile file:'unexpected', text:''writeFile file:'bar/unexpected', text:''deleteOthers(keep){code}*Expected behavior:* All the listed directories listed in "keep" are preserved (as both the directories themselves, as well as all parents are explicitly excluded!) and the included files are preserved.Only the files created outside of directories listed in "keep" are expected to be removed.*Actual behavior:* Only the directories + paths "foo/ dummy expected " and "foo2/ dummy expected " are preserved. All the directories with a nested paths, relative to include pattern, are impossible to preserve.It appears as if excludes fail to apply to any directory, if the directory was matched using a non-empty{code:java}**{code}part of the INCLUDE wildcard. Directories only matched by a single star, or an empty double-star have their EXCLUDE rules evaluated correctly.For files, excludes are properly evaluated even if the INCLUDE was matching with a non-empty double-star.E.g. with "deleteDirs: false", all expected files are protected correctly.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment

[JIRA] (JENKINS-62044) EXCLUDE patterns can't protect directories included by "**"

2020-04-24 Thread andreas.ringlstet...@gmail.com (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 Andreas Ringlstetter updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-62044  
 
 
  EXCLUDE patterns can't protect directories included by "**"   
 

  
 
 
 
 

 
Change By: 
 Andreas Ringlstetter  
 

  
 
 
 
 

 
 Consider the following pipeline code:{code:java}void deleteOthers(List pathList) { def prefixes = [] for(path in pathList) {  def currentPrefix = path;  while(true) {   def prefixEnd = currentPrefix.lastIndexOf("/")   if(prefixEnd > 0) {currentPrefix = currentPrefix.substring(0, prefixEnd);prefixes.add(currentPrefix)   } else {break;   }  } } prefixes.unique()  def patterns = [] for(path in prefixes) {  patterns.add([   pattern: '/' + path,   type: 'EXCLUDE'  ]) } for(path in pathList) {  patterns.add([   pattern: '/' + path,   type: 'EXCLUDE'  ])  patterns.add([   pattern: '/' + path + '/**',   type: 'EXCLUDE'  ]) } patterns.add([  pattern: '/**/*',  type: 'INCLUDE' ])   cleanWs deleteDirs: true, patterns: patterns return}def keep = [ 'foo', 'foo2', 'bar/foo', 'bar/foo2', 'bar/foo3/bla'] writeFile file:'dummy', text:''    for(path in keep) { dir(path) {  writeFile file:' dummy expected ', text:''    }} writeFile file:'unexpected', text:''writeFile file:'bar/unexpected', text:'' deleteOthers(keep){code}*Expected behavior:* All the listed directories listed in "keep" are preserved (as both the directories themselves, as well as all parents are explicitly excluded!) and the included files are preserved.Only the  file  files  created outside  the tree is  of directories listed in "keep" are  expected to be removed.*Actual behavior:* Only the directories + paths "foo/dummy" and "foo2/dummy" are preserved. All the directories with a nested paths, relative to include pattern, are impossible to preserve.It appears as if excludes fail to apply to any directory, if the directory was matched using a non-empty   {code:java}  **{code}   part of the INCLUDE wildcard. Directories only matched by a single star, or an empty double-star have their EXCLUDE rules evaluated correctly.For files, excludes are properly evaluated even if the INCLUDE was matching with a non-empty double-star.E.g. with "deleteDirs: false", all expected files are protected correctly.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment

[JIRA] (JENKINS-62044) EXCLUDE patterns can't protect directories included by "**"

2020-04-24 Thread andreas.ringlstet...@gmail.com (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 Andreas Ringlstetter updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-62044  
 
 
  EXCLUDE patterns can't protect directories included by "**"   
 

  
 
 
 
 

 
Change By: 
 Andreas Ringlstetter  
 

  
 
 
 
 

 
 Consider the following pipeline code:{code:java}void deleteOthers(List pathList) { def prefixes = [] for(path in pathList) {  def currentPrefix = path;  while(true) {   def prefixEnd = currentPrefix.lastIndexOf("/")   if(prefixEnd > 0) {currentPrefix = currentPrefix.substring(0, prefixEnd);prefixes.add(currentPrefix)   } else {break;   }  } } prefixes.unique()  def patterns = [] for(path in prefixes) {  patterns.add([   pattern: '/' + path,   type: 'EXCLUDE'  ]) } for(path in pathList) {  patterns.add([   pattern: '/' + path,   type: 'EXCLUDE'  ])  patterns.add([   pattern: '/' + path + '/**',   type: 'EXCLUDE'  ]) } patterns.add([  pattern: '/**/*',  type: 'INCLUDE' ])   cleanWs deleteDirs: true, patterns: patterns return}def keep = [ 'foo', 'foo2', 'bar/foo', 'bar/foo2', 'bar/foo3/bla']writeFile file:'dummy', text:''   for(path in keep) { dir(path) {  writeFile file:'dummy', text:''    }}deleteOthers(keep){code}*Expected behavior:* All the listed directories listed in "keep" are preserved (as both the directories themselves, as well as all parents are explicitly excluded!) and the included files are preserved.Only the file created outside the tree is expected to be removed.*Actual behavior:* Only the directories + paths "foo/dummy" and "foo2/dummy" are preserved. All the directories with a nested paths, relative to include pattern, are impossible to preserve.It appears as if excludes fail to apply to any directory, if the directory was  * matched using a non-empty {code:java}** {code} part of the INCLUDE wildcard * . Directories only matched by a single  `*` (  star, or an empty  "**")  double-star  have their EXCLUDE rules evaluated correctly.For files, excludes are properly evaluated even if the INCLUDE was matching with a non-empty  "**"  double-star .E.g. with "deleteDirs: false", all expected files are protected correctly.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment

[JIRA] (JENKINS-62044) EXCLUDE patterns can't protect directories included by "**"

2020-04-24 Thread andreas.ringlstet...@gmail.com (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 Andreas Ringlstetter updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-62044  
 
 
  EXCLUDE patterns can't protect directories included by "**"   
 

  
 
 
 
 

 
Change By: 
 Andreas Ringlstetter  
 

  
 
 
 
 

 
 Consider the following pipeline code:{code:java}void deleteOthers(List pathList) { def prefixes = [] for(path in pathList) {  def currentPrefix = path;  while(true) {   def prefixEnd = currentPrefix.lastIndexOf("/")   if(prefixEnd > 0) {currentPrefix = currentPrefix.substring(0, prefixEnd);prefixes.add(currentPrefix)   } else {break;   }  } } prefixes.unique()  def patterns = [] for(path in prefixes) {  patterns.add([   pattern: '/' + path,   type: 'EXCLUDE'  ]) } for(path in pathList) {  patterns.add([   pattern: '/' + path,   type: 'EXCLUDE'  ])  patterns.add([   pattern: '/' + path + '/**',   type: 'EXCLUDE'  ]) } patterns.add([  pattern: '/**/*',  type: 'INCLUDE' ])   cleanWs deleteDirs: true, patterns: patterns return}def keep = [ 'foo', 'foo2', 'bar/foo', 'bar/foo2', 'bar/foo3/bla']writeFile file:'dummy', text:''   for(path in keep) { dir(path) {  writeFile file:'dummy', text:''    }}deleteOthers(keep){code}*Expected behavior:* All the listed directories listed in "keep" are preserved (as both the directories themselves, as well as all parents are explicitly excluded!) and the included files are preserved.Only the file created outside the tree is expected to be removed.*Actual behavior:* Only the directories + paths "foo/dummy" and "foo2/dummy" are preserved. All the directories with a nested paths, relative to include pattern, are impossible to preserve.It appears as if excludes fail to apply to any directory, if the directory was *matched using a non-empty  "  {code:java} ** "  {code}  part of the INCLUDE wildcard*. Directories only matched by a single  "  ` * " `  (or an empty "**") have their EXCLUDE rules evaluated correctly.For files, excludes are properly evaluated even if the INCLUDE was matching with a non-empty "**".E.g. with "deleteDirs: false", all expected files are protected correctly.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment

[JIRA] (JENKINS-62044) EXCLUDE patterns can't protect directories included by "**"

2020-04-24 Thread andreas.ringlstet...@gmail.com (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 Andreas Ringlstetter created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-62044  
 
 
  EXCLUDE patterns can't protect directories included by "**"   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Oliver Gondža  
 
 
Components: 
 ws-cleanup-plugin  
 
 
Created: 
 2020-04-24 09:56  
 
 
Priority: 
  Major  
 
 
Reporter: 
 Andreas Ringlstetter  
 

  
 
 
 
 

 
 Consider the following pipeline code: 

 

void deleteOthers(List pathList) {
	def prefixes = []
	for(path in pathList) {
		def currentPrefix = path;
		while(true) {
			def prefixEnd = currentPrefix.lastIndexOf("/")
			if(prefixEnd > 0) {
currentPrefix = currentPrefix.substring(0, prefixEnd);
prefixes.add(currentPrefix)
			} else {
break;
			}
		}
	}
	prefixes.unique()
	
	def patterns = []
	for(path in prefixes) {
		patterns.add([
			pattern: '/' + path,
			type: 'EXCLUDE'
		])
	}
	for(path in pathList) {
		patterns.add([
			pattern: '/' + path,
			type: 'EXCLUDE'
		])
		patterns.add([
			pattern: '/' + path + '/**',
			type: 'EXCLUDE'
		])
	}
	patterns.add([
		pattern: '/**/*',
		type: 'INCLUDE'
	])
	
	
	cleanWs deleteDirs: true, patterns: patterns
	return
}

def keep = [
	'foo',
	'foo2',
	'bar/foo',
	'bar/foo2',
	'bar/foo3/bla'
]
writeFile file:'dummy', text:''   
for(path in keep) {
	dir(path) {
		writeFile file:'dummy', text:''   
	}
}
deleteOthers(keep)
 

 Expected behavior: All the listed directories listed in "keep" are preserved (as both the directories themselves, as well as all parents are explicitly excluded!) and the included files are preserved. Only the file created outside the tree is expected to be removed. Actual behavior: Only the directories + paths "foo/dummy" and "foo2/dummy" are preserved. All the directories with a nested paths, relative to include

[JIRA] (JENKINS-58068) Races / corruption on revision.txt in pipeline-parallel

2019-06-18 Thread andreas.ringlstet...@gmail.com (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 Andreas Ringlstetter updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-58068  
 
 
  Races / corruption on revision.txt in pipeline-parallel   
 

  
 
 
 
 

 
Change By: 
 Andreas Ringlstetter  
 

  
 
 
 
 

 
 In the scope of JENKINS-39968 When used in a pipleine parallel block , the subversion plugin suffers from  additional races  raceconditions  due to the dependency on the "revision.txt" file as part of the checkout and change log computation process.Unsynchronized access to "revision.txt" causes `SubversionChangeLogBuilder ` to fail spuriously, as the file may be written to concurrently by other running checkout processes.The final "revision.txt" eventually reaches a stable state where it only contains the revision of the last "checkout" step, but in the process `SubversionChangeLogBuilder` has failed to record changes repeatedly (bailout with "No revision found for ") and the "build.xml" is corrupted and contains fragments like the following:{code:java}svn http://redacted/trunked/trunk16122svn http://redacted/trunk12362  {code}In summary:* Unsafe reads from "revision.txt" which contains data from parallel checkout processes* Lost writes to "revision.txt" from previous checkout steps in the same build, with unstable resultsWhile producing "revision.txt" as a side product of the build process may be desired to keep as a side effect, using it internally means state between `SubversionSCM` instances in the same build is shared in an unsafe way. Assuming it is only written to once per build may be somewhat fitting to Freestyle projects, but is unsuited for pipeline projects.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
 

[JIRA] (JENKINS-58068) Races / corruption on revision.txt in pipeline-parallel

2019-06-18 Thread andreas.ringlstet...@gmail.com (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 Andreas Ringlstetter updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-58068  
 
 
  Races / corruption on revision.txt in pipeline-parallel   
 

  
 
 
 
 

 
Change By: 
 Andreas Ringlstetter  
 

  
 
 
 
 

 
 In the scope of JENKINS-39968, the subversion plugin suffers from additional races due to the dependency on the "revision.txt" file as part of the checkout and change log computation process.Unsynchronized access to "revision.txt" causes `SubversionChangeLogBuilder ` to fail spuriously, as the file may be written to concurrently by other running checkout processes.The final "revision.txt" eventually reaches a stable state where it only contains the revision of the last "checkout" step, but in the process `SubversionChangeLogBuilder` has failed to record changes repeatedly (bailout with "No revision found for ") and the "build.xml" is corrupted and contains fragments like the following:{code:java}svn http://redacted/trunked/trunk16122svn http://redacted/trunk12362  {code}In summary:* Unsafe reads from "revision.txt" which contains data from parallel checkout processes* Lost writes to "revision.txt" from previous checkout steps in the same build, with unstable resultsWhile producing "revision.txt" as a side product of the build process may be desired to keep as a side effect, using it internally means state between `SubversionSCM` instances in the same build is shared in an unsafe way.  Assuming it is only written to once per build may be somewhat fitting to Freestyle projects, but is unsuited for pipeline projects.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
 

[JIRA] (JENKINS-58068) Races / corruption on revision.txt in pipeline-parallel

2019-06-18 Thread andreas.ringlstet...@gmail.com (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 Andreas Ringlstetter created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-58068  
 
 
  Races / corruption on revision.txt in pipeline-parallel   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Ivan Fernandez Calvo  
 
 
Components: 
 subversion-plugin  
 
 
Created: 
 2019-06-18 12:44  
 
 
Priority: 
  Major  
 
 
Reporter: 
 Andreas Ringlstetter  
 

  
 
 
 
 

 
 In the scope of JENKINS-39968, the subversion plugin suffers from additional races due to the dependency on the "revision.txt" file as part of the checkout and change log computation process. Unsynchronized access to "revision.txt" causes `SubversionChangeLogBuilder ` to fail spuriously, as the file may be written to concurrently by other running checkout processes. The final "revision.txt" eventually reaches a stable state where it only contains the revision of the last "checkout" step, but in the process `SubversionChangeLogBuilder` has failed to record changes repeatedly (bailout with "No revision found for ") and the "build.xml" is corrupted and contains fragments like the following: 

 

"workflow-scm-step@2.9">
  

  svn http://redacted/trunk
  "subversion@2.12.1">

  
ed/trunk
16122long>
  
  
svn http://redacted/trunk
12362long>
  

  

  

 

 In summary: 
 
Unsafe reads from "revision.txt" which contains data from parallel checkout processes 
Lost writes to "revision.txt" from previous checkout steps in the

[JIRA] (JENKINS-56007) Can't copy source files from slave to master if security is enabled

2019-03-19 Thread andreas.ringlstet...@gmail.com (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 Andreas Ringlstetter updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-56007  
 
 
  Can't copy source files from slave to master if security is enabled
 

  
 
 
 
 

 
Change By: 
 Andreas Ringlstetter  
 
 
Comment: 
 "Slave to Master Access Control" only has an effect on *creating the target directory*, not on the copy. (And it should not have either. Please fix that.)The logic around AffectedFilesResolver::copy is plain wrong, it *always* tries to perform a local copy. That only works under the assumption that the Jenkins archive is on a shared drive which both master and slave can see and access identically. Specifically, this requires the slave to have *full write access* to the archive, which is not advisable in any setup.For the generalized case, where the slave does *not* have direct access to the archive, it still fails regardless. You must use `RemoteInputStream` or `RemoteWriter` to copy files from the workspace.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
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] (JENKINS-56007) Can't copy source files from slave to master if security is enabled

2019-03-19 Thread andreas.ringlstet...@gmail.com (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 Andreas Ringlstetter edited a comment on  JENKINS-56007  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Can't copy source files from slave to master if security is enabled
 

  
 
 
 
 

 
 "Slave to Master Access Control" only has an effect on *creating the target directory*, not on the copy. (And it should not have either. Please fix that.)The logic around AffectedFilesResolver::copy is plain wrong, it *always* tries to perform a local copy. That only works under the assumption that the Jenkins archive is on a shared drive which both master and slave can see  and access  identically.  Specifically, this requires the slave to have *full write access* to the archive, which is not advisable in any setup. For the generalized case, where the slave does *not* have direct access to the archive, it still fails regardless. You must use `RemoteInputStream` or `RemoteWriter` to copy files from the workspace.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
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] (JENKINS-56007) Can't copy source files from slave to master if security is enabled

2019-03-19 Thread andreas.ringlstet...@gmail.com (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 Andreas Ringlstetter commented on  JENKINS-56007  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Can't copy source files from slave to master if security is enabled
 

  
 
 
 
 

 
 "Slave to Master Access Control" only has an effect on creating the target directory, not on the copy. (And it should not have either. Please fix that.) The logic around AffectedFilesResolver::copy is plain wrong, it always tries to perform a local copy. That only works under the assumption that the Jenkins archive is on a shared drive which both master and slave can see identically. For the generalized case, where the slave does not have direct access to the archive, it still fails regardless. You must use `RemoteInputStream` or `RemoteWriter` to copy files from the workspace.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
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] (JENKINS-9104) Visual studio builds started by Jenkins fail with "Fatal error C1090" because mspdbsrv.exe gets killed

2019-02-15 Thread andreas.ringlstet...@gmail.com (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 Andreas Ringlstetter edited a comment on  JENKINS-9104  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Visual studio builds started by Jenkins fail with "Fatal error C1090" because mspdbsrv.exe gets killed   
 

  
 
 
 
 

 
 Solution is still the same, before invoking `msbuild`, set the following environment variables to something unique:{code:java}_MSPDBSRV_ENDPOINT_=TMP=TEMP=$TMPTMPDIR=$TMP{code}Once you have done that, you can launch as many parallel MSBuild instances as you like, even mixing different msbuild versions or whatever. They will not interfere in any way. Doing that on a regular base with mixed MSVC12, MSVC14 and MSVC15 toolchains on the same machine, and didn't have any issues since. The "official" fix for this problem (trying not to kill the job scheduler) is plain wrong, and causes massive issues. Mostly because MSBuild itself isn't exactly stable either when using the same job server for multiple parallel builds. And if the builds are using different toolchains, a crash is ensured.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
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] (JENKINS-9104) Visual studio builds started by Jenkins fail with "Fatal error C1090" because mspdbsrv.exe gets killed

2019-02-15 Thread andreas.ringlstet...@gmail.com (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 Andreas Ringlstetter edited a comment on  JENKINS-9104  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Visual studio builds started by Jenkins fail with "Fatal error C1090" because mspdbsrv.exe gets killed   
 

  
 
 
 
 

 
 Solution is still the same, before invoking `msbuild`, set the following environment variables to something unique:{code:java}_MSPDBSRV_ENDPOINT_=TMP=TEMP=$TMPTMPDIR=$TMP{code}Once you have done that, you can launch as many parallel MSBuild instances as you like, even mixing different msbuild versions or whatever. They will not interfere in any way.  Dong  Doing  that on a regular base with mixed MSVC12, MSVC14 and MSVC15 toolchains on the same machine, and didn't have any issues since.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
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] (JENKINS-9104) Visual studio builds started by Jenkins fail with "Fatal error C1090" because mspdbsrv.exe gets killed

2019-02-15 Thread andreas.ringlstet...@gmail.com (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 Andreas Ringlstetter commented on  JENKINS-9104  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Visual studio builds started by Jenkins fail with "Fatal error C1090" because mspdbsrv.exe gets killed   
 

  
 
 
 
 

 
 Solution is still the same, before invoking `msbuild`, set the following environment variables to something unique: 

 
_MSPDBSRV_ENDPOINT_=
TMP=
TEMP=$TMP
TMPDIR=$TMP 

 Once you have done that, you can launch as many parallel MSBuild instances as you like, even mixing different msbuild versions or whatever. They will not interfere in any way. Dong that on a regular base with mixed MSVC12, MSVC14 and MSVC15 toolchains on the same machine, and didn't have any issues since.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
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] (JENKINS-50901) EXCLUDE pattern fails to protect parent dir with deleteDir option

2018-04-19 Thread andreas.ringlstet...@gmail.com (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 Andreas Ringlstetter created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-50901  
 
 
  EXCLUDE pattern fails to protect parent dir with deleteDir option   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Oliver Gondža  
 
 
Components: 
 ws-cleanup-plugin  
 
 
Created: 
 2018-04-19 15:28  
 
 
Environment: 
 Workspace Cleanup Plugin 0.34  
 
 
Priority: 
  Major  
 
 
Reporter: 
 Andreas Ringlstetter  
 

  
 
 
 
 

 
 When using WsCleanup with a blacklist-based filter (only EXCLUDE type patterns) and the deleteDirs=true option, parent directories of explicitly excluded paths are not protected. As a result, the parent directory is then deleted recursively, also deleting the explicitly excluded child directory. If an exclude pattern matches a file, all parent directories (but not their contents!) would need to be implicitly excluded as well. The required logic is inverse from use cases where the parent directory would need to be included implicitly (e.g. a copy).  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment