[JIRA] (JENKINS-38886) Polling broken on Matrix configuration

2016-10-12 Thread mic...@ejdys.eu (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Michal Ejdys updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-38886  
 
 
  Polling broken on Matrix configuration   
 

  
 
 
 
 

 
Change By: 
 Michal Ejdys  
 

  
 
 
 
 

 
 After upgrading p4-plugin from 1.0.14 to 1.4.8, all our matrix build configurations started triggering continuously. It turns out, the plugin changed the way it resolves variables in the workspace name for the matrix configuration. The way the SCM polling does it and the actual build is different, which leads to the polling trying to use a non-existent workspace name, and always detecting new changes.Build name: test-build-configWorkspace name in configuration: jenkins-$\{NODE_NAME\}-$\{JOB_NAME\}Polling log, observe the workspace name has been calculated using the JOB_NAME of the job of the first matrix axis combination. In previous versions of the plugin, this would be the build name, so the workspace would be 'jenkins-master-test-build-config'.{code}Perforce Software Polling LogStarted on Oct 11, 2016 12:15:00 AMPolling SCM changes on masterP4: Polling on: master with:jenkins-master-test-build-config-AXIS_1-value_1-AXIS_2-Value_2-AXIS_3-Value_3... p4 client -o jenkins-master-test-build-config-AXIS_1-value_1-AXIS_2-Va___ +... p4 info +P4 Task: establishing connection server: perforce-ci.tomtomgroup.com:1666... node: michi-jenkins-00P4: Polling with cstat: //jenkins-master-test-build-config-AXIS_1-value_1-AXIS_2-Value_2-AXIS_3-Value_3/.. p4 cstat //jenkins-master-test-build-config-AXIS_1-value_1- AXIS_3 AXIS_2 -Valu___ +... p4 change -o 2418201 +... found change: 2418201... p4 change -o 2364282 +... found change: 2364282... p4 change -o 2357042 +... found change: 2357042Done. Took 1.7 secChanges found{code}Build log (the kick off of the master build, before spawning the builds for each matrix axis combination), however, checks out 'jenkins-master-test-build-config'. So the polling workspace and the build workspace are different. And since the former does not exist, each poll triggers a build.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 


[JIRA] (JENKINS-38886) Polling broken on Matrix configuration

2016-10-11 Thread mic...@ejdys.eu (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Michal Ejdys updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-38886  
 
 
  Polling broken on Matrix configuration   
 

  
 
 
 
 

 
Change By: 
 Michal Ejdys  
 

  
 
 
 
 

 
 After upgrading p4-plugin from 1.0.14 to 1.4.8, all our matrix build configurations started triggering continuously. It turns out, the plugin changed the way it resolves variables in the workspace name for the matrix configuration. The way the SCM polling does it and the actual build is different, which leads to the polling trying to use a non-existent workspace name, and always detecting new changes.Build name: test-build-configWorkspace name in configuration: jenkins-$ \ {NODE_NAME \ }-$ \ {JOB_NAME \ }Polling log, observe the workspace name has been calculated using the JOB_NAME of the job of the first matrix axis combination. In previous versions of the plugin, this would be the build name, so the workspace would be 'jenkins-master-test-build-config'.{code}Perforce Software Polling LogStarted on Oct 11, 2016 12:15:00 AMPolling SCM changes on masterP4: Polling on: master with:jenkins-master-test-build-config-AXIS_1-value_1-AXIS_2-Value_2-AXIS_3-Value_3... p4 client -o jenkins-master-test-build-config-AXIS_1-value_1-AXIS_2-Va___ +... p4 info +P4 Task: establishing connection server: perforce-ci.tomtomgroup.com:1666... node: michi-jenkins-00P4: Polling with cstat: //jenkins-master-test-build-config-AXIS_1-value_1-AXIS_2-Value_2-AXIS_3-Value_3/.. p4 cstat //jenkins-master-test-build-config-AXIS_1-value_1-AXIS_3-Valu___ +... p4 change -o 2418201 +... found change: 2418201... p4 change -o 2364282 +... found change: 2364282... p4 change -o 2357042 +... found change: 2357042Done. Took 1.7 secChanges found{code}Build log (the kick off of the master build, before spawning the builds for each matrix axis combination), however, checks out 'jenkins-master-test-build-config'. So the polling workspace and the build workspace are different. And since the former does not exist, each poll triggers a build.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

 

[JIRA] (JENKINS-38886) Polling broken on Matrix configuration

2016-10-11 Thread mic...@ejdys.eu (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Michal Ejdys created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-38886  
 
 
  Polling broken on Matrix configuration   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 p4-plugin  
 
 
Created: 
 2016/Oct/11 8:12 AM  
 
 
Environment: 
 Jenkins ver. 2.19.1  p4-plugin version 1.4.8  matrix-project 1.6  
 
 
Priority: 
  Critical  
 
 
Reporter: 
 Michal Ejdys  
 

  
 
 
 
 

 
 After upgrading p4-plugin from 1.0.14 to 1.4.8, all our matrix build configurations started triggering continuously. It turns out, the plugin changed the way it resolves variables in the workspace name for the matrix configuration. The way the SCM polling does it and the actual build is different, which leads to the polling trying to use a non-existent workspace name, and always detecting new changes. Build name: test-build-config Workspace name in configuration: jenkins-$ {NODE_NAME} -$ {JOB_NAME} Polling log, observe the workspace name has been calculated using the JOB_NAME of the job of the first matrix axis combination. In previous versions of the plugin, this would be the build name, so the workspace would be 'jenkins-master-test-build-config'. 

 

Perforce Software Polling Log

Started on Oct 11, 2016 12:15:00 AM
Polling SCM changes on master
P4: Polling on: master with:jenkins-master-test-build-config-AXIS_1-value_1-AXIS_2-Value_2-AXIS_3-Value_3
... p4 client -o jenkins-master-test-build-config-AXIS_1-value_1-AXIS_2-Va___ +
... p4 info +

P4 Task: establishing connection.
... server: perforce-ci.tomtomgroup.com:1666
... node: michi-jenkins-00
P4: Polling with cstat: //jenkins-master-test-build-config-AXIS_1-value_1-AXIS_2-Value_2-AXIS_3-Value_3/...
... p4 cstat 

[JIRA] [coverity-plugin] (JENKINS-19451) Broken links to coverity instance when SSL is used

2014-12-03 Thread mic...@ejdys.eu (JIRA)














































Michal Ejdys
 commented on  JENKINS-19451


Broken links to coverity instance when SSL is used















Still happens on the plugin version 1.4.1



























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







-- 
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] [coverity-plugin] (JENKINS-25885) Coverity plugin runs cov-build regardless if it was requested or not

2014-12-03 Thread mic...@ejdys.eu (JIRA)














































Michal Ejdys
 created  JENKINS-25885


Coverity plugin runs cov-build regardless if it was requested or not















Issue Type:


Bug



Assignee:


Ken Dang



Components:


coverity-plugin



Created:


03/Dec/14 11:27 AM



Description:


Post-build action Coverity has an option called "Perform Coverity build, analysis and commit". The documentation says that when enabling it, the plugin will monitor the build with cov-build and trigger analyse and commit automatically. If not enabled, the build script has to do it itself.

Unfortunately, regardless if the option is enabled or disabled, the build script is invoked through cov-build. This conflicts with the documentation.

The undesired effect is that the coverity config needs to be provided externally to the build as it needs to be available when cov-build is starting, so before the build script is triggered. This is undesirable as it prevents the job definition from being self contained. Also, as - in my case - it is the build that decides on what compiler and in what versions to use, so I would prefer to set up the coverity config on every build from inside the script.




Environment:


jenkins - 1.581

coverity plugin - 1.4.1




Project:


Jenkins



Priority:


Minor



Reporter:


Michal Ejdys

























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







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