date:20170320

[JIRA] (JENKINS-42763) Env var HOME for containers has regressed

2017-03-20 Thread parag.doke+tec...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Parag Doke commented on  JENKINS-42763  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Env var HOME for containers has regressed   
 

  
 
 
 
 

 
 I think inheriting from a template is a workaround. Why make it mandatory for everyone to: 1) Have an invalid HOME 2) Else inherit from a template If their kube cluster is not on OpenShift. I think we need to fix this the right way ... which should be to add an optional param (ensure HOME is valid ... or something to that effect). I wish I were better at development ... would make an attempt and raise a PR myself.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)  
 
 

 
   
 

  
 

  
 

   





-- 
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-40825) "Pipe not connected" errors when running multiple builds simultaneously

2017-03-20 Thread jr...@vendasta.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Jesse Redl commented on  JENKINS-40825  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: "Pipe not connected" errors when running multiple builds simultaneously   
 

  
 
 
 
 

 
 Lars Lawoko thanks so much for posting the work around. I was about to throw the towel in on Jenkins today and this saved me.  For reference to others, rather than pulling directly from the office jenkinsci images I brought in the relevant bits from the published docker files: 
 
https://github.com/jenkinsci/docker-slave 
 
 
https://github.com/jenkinsci/docker-jnlp-slave 
 Another win for this workaround is that by dropping the container block you also cut out all of the noise being generated from: https://issues.jenkins-ci.org/browse/JENKINS-42048 

 

Jenkins 2.51
Kubernetes plugin 0.11 
Kubernetes 1.5.3 on GKE 

    
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)  
 
 

 
   
 

  
 

  
 

   





-- 
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

[JIRA] (JENKINS-42954) Jenkins unable to operate SonarQube block

2017-03-20 Thread ia...@il.ibm.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Idan Adar created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-42954  
 
 
  Jenkins unable to operate SonarQube block   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Sonar Team  
 
 
Components: 
 sonar  
 
 
Created: 
 2017/Mar/21 4:49 AM  
 
 
Environment: 
 Jenkins 2.48  Linux (CentOS)  SonarQube 6.2  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 Idan Adar  
 

  
 
 
 
 

 
 (Based on: https://stackoverflow.com/questions/42909439/using-waitforqualitygate-in-a-jenkins-declarative-pipeline)   It appears that stage like these are not possible? stage ("SonarQube analysis") { steps { script { STAGE_NAME = "SonarQube analysis"  if (BRANCH_NAME == "develop")  { echo "In 'develop' branch, don't analyze." }  else { // this is a PR build, run sonar analysis withSonarQubeEnv("SonarGate")  { sh "../../../sonar-scanner-2.9.0.670/bin/sonar-scanner" }  } } } }  stage ("SonarQube Gatekeeper") { steps { script { STAGE_NAME = "SonarQube Gatekeeper"  if (BRANCH_NAME == "develop")  { echo "In 'develop' branch, skip." }  else { // this is a PR build, fail on threshold spill def qualitygate = waitForQualityGate() if (qualitygate.status != "OK") { error "Pipeline aborted due to quality gate coverage failure: $ {qualitygate.status} " }  } } } }  It fails with: "Please use the 'withSonarQubeEnv' wrapper to run your analysis.", but I am using it... Jenkins does not recognize it? full logs in the question link above.

[JIRA] (JENKINS-42937) Massive slowdown of pipeline execution when making massive use of parallel

2017-03-20 Thread svano...@cloudbees.com (JIRA)

Title: Message Title

Sam Van Oort edited a comment on JENKINS-42937

Re: Massive slowdown of pipeline execution when making massive use of parallel

It's a bit more complex than that, because it actually has to do with the graph heads structure vs. the iteration behavior. Essentially we can walk back to the beginning of the directed-acyclic flow graph multiple times for parallels. This gives ~ O(m*n) performance for each BlockStartNode checked, where m is the number of nodes previously run, and n is the number of branches, assuming each branch is an equal number of nodes long. This version removes that behavior, which should greatly improve performance with many parallels. In theory it is still far from optimal, because we *could* simply store the hierarchy of inclosing blocks in memory while running a flow, reducing an O(m) scan to O(d) where d is depth (linear check) or O(1) if a hashset is used to store enclosing blocks. However in practice any of that would require some very significant internal changes, and copyLogs is slated to disappear in the future.

Add Comment

This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)

--
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-42937) Massive slowdown of pipeline execution when making massive use of parallel

2017-03-20 Thread svano...@cloudbees.com (JIRA)

Title: Message Title

Sam Van Oort commented on JENKINS-42937

Re: Massive slowdown of pipeline execution when making massive use of parallel

It's a bit more complex than that, because it actually has to do with the graph heads structure vs. the iteration behavior. Essentially we can walk back to the beginning of the directed-acyclic flow graph multiple times for parallels. This gives O(m*n) performance for each BlockStartNode checked, where m is the number of nodes previously run, and n is the number of branches, assuming each branch is an equal number of nodes long. This version removes that behavior, which should greatly improve performance with many parallels. In theory it is still far from optimal, because we could simply store the hierarchy of inclosing blocks in memory while running a flow, reducing an O(m) scan to O(d) where d is depth (linear check) or O(1) if a hashset is used to store enclosing blocks. However in practice any of that would require some very significant internal changes, and copyLogs is slated to disappear in the future.

Add Comment

This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)

[JIRA] (JENKINS-42937) Massive slowdown of pipeline execution when making massive use of parallel

2017-03-20 Thread svano...@cloudbees.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Sam Van Oort started work on  JENKINS-42937  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
Change By: 
 Sam Van Oort  
 
 
Status: 
 Open In Progress  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)  
 
 

 
   
 

  
 

  
 

   





-- 
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-42937) Massive slowdown of pipeline execution when making massive use of parallel

2017-03-20 Thread svano...@cloudbees.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Sam Van Oort assigned an issue to Sam Van Oort  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-42937  
 
 
  Massive slowdown of pipeline execution when making massive use of parallel   
 

  
 
 
 
 

 
Change By: 
 Sam Van Oort  
 
 
Assignee: 
 Sam Van Oort  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)  
 
 

 
   
 

  
 

  
 

   





-- 
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-42522) Metadata plugin deletes old data on startup

2017-03-20 Thread abrid...@blackberry.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Tony Bridges assigned an issue to recampbell  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-42522  
 
 
  Metadata plugin deletes old data on startup   
 

  
 
 
 
 

 
Change By: 
 Tony Bridges  
 
 
Assignee: 
 rsandell recampbell  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)  
 
 

 
   
 

  
 

  
 

   





-- 
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-42522) Metadata plugin deletes old data on startup

2017-03-20 Thread abrid...@blackberry.com (JIRA)

Title: Message Title

Tony Bridges commented on JENKINS-42522

Re: Metadata plugin deletes old data on startup

I hit this issue during an upgrade. To reproduce : 1. configure the use of a plugin in a job. Call this CanaryPlugin 2. Verify the presence of the CanaryPlugin configuration in XML. 3. Delete the CanaryPlugin that added this data from the file system 4. Upgrade the metadata plugin. 5. Restart. On startup, the MD plugin upgrade causes the job configuration to be resaved, effectively deleting the configuration for the CanaryPlugin from all jobs. I ran into this problem when attempting a manual sync of plugins between two systems. The tool used to seed the plugins did not handle internally developed plugins, and the first attempt to restart the system after the upgrade caused the configuration for all internal plugins to be stripped. The expectation here was that the "missing plugin" error could be addressed post restart by restoring the missing plugins, and restarting again.

1 2 3 >

1 - 100 of 250 matches

Mail list logo