[JIRA] (JENKINS-60579) Impossible to have an invisible property on View that is persisted on save
Title: Message Title
A. Jard created an issue
Jenkins / JENKINS-60579
Impossible to have an invisible property on View that is persisted on save
Issue Type:
Bug
Assignee:
Unassigned
Components:
core
Created:
2019-12-24 10:32
Priority:
Minor
Reporter:
A. Jard
DescriptorVisibilityFilter is not used to filter properties that are displayed on the View edition. The same method View.getApplicablePropertyDescriptors() is used both to filter displayed properties on UI and to filter properties that are saved with the View. The only way to not show a property in UI is to use ViewPropertyDescriptor but then the property is not persisted and is removed when the users edit view and save it.
@Extension
public static final class DescriptorImpl extends ViewPropertyDescriptor {
@Override
public boolean isEnabledFor(View view) {
return false;
}
}
That means that it's not possible to have some hidden properties for View that are persisted. This method is used in jelly to filter properties: https://github.com/jenkinsci/jenkins/blob/d1502bffe8b5d530d31a4d697f064b79a5cab081/core/src/main/resources/hudson/model/View/configure.jelly#L55 And it's also used in View to filter properties that are persisted: https://github.com/jenkinsci/jenkins/blob/d1502bffe8b5d530d31a4d697f064b79a5cab081/core/src/main/java/hudson/model/View.java#L1012 I looked at Job configuration, a specific method based on DescriptorVisibilityFilter is used in jelly. https://github.com/jenkinsci/jenkins/blob/d1502bffe8b5d530d31a4d697f064b79a5cab081/core/src/main/resources/hudson/model/Job/configure.jelly#L51 So this code should work for View when a plugin need to have an invisible property:
[JIRA] (JENKINS-60579) Impossible to have an invisible property on View that is persisted on save
Title: Message Title A. Jard assigned an issue to A. Jard Jenkins / JENKINS-60579 Impossible to have an invisible property on View that is persisted on save Change By: A. Jard Assignee: A. Jard Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.203704.1577183535000.15332.1577183700066%40Atlassian.JIRA.
[JIRA] (JENKINS-60579) Impossible to have an invisible property on View that is persisted on save
Title: Message Title
A. Jard updated an issue
Jenkins / JENKINS-60579
Impossible to have an invisible property on View that is persisted on save
Change By:
A. Jard
DescriptorVisibilityFilter is not used to filter properties that are displayed on the View edition.The same method View.getApplicablePropertyDescriptors() is used both to filter displayed properties on UI and to filter properties that are saved with the View.The only way to *not show a property in UI* is to use ViewPropertyDescriptor but then the property is not persisted and *is removed when the users edit view* and save it.{code:java}@Extensionpublic static final class DescriptorImpl extends ViewPropertyDescriptor {@Overridepublic boolean isEnabledFor(View view) {return false;}}{code}*That means that it's not possible to have some hidden properties for View that are persisted.*This method is used in jelly to filter properties: [https://github.com/jenkinsci/jenkins/blob/d1502bffe8b5d530d31a4d697f064b79a5cab081/core/src/main/resources/hudson/model/View/configure.jelly#L55]And it's also used in View to filter properties that are persisted: [https://github.com/jenkinsci/jenkins/blob/d1502bffe8b5d530d31a4d697f064b79a5cab081/core/src/main/java/hudson/model/View.java#L1012]I looked at Job configuration, a specific method based on DescriptorVisibilityFilter is used in jelly. [https://github.com/jenkinsci/jenkins/blob/d1502bffe8b5d530d31a4d697f064b79a5cab081/core/src/main/resources/hudson/model/Job/configure.jelly#L51]So this code should work for View when a plugin need to have an invisible property:{code:java}@Extensionpublic static final class DescriptorVisibilityFilterImpl extends DescriptorVisibilityFilter {@Overridepublic boolean filter(Object context, Descriptor descriptor) {return false;}}{code}I already did a test that show this issue , I will link the it's on that PR to this JIRA : https://github . com/jenkinsci/jenkins/pull/4404 I propose to add a new method in View to filter properties that use DescriptorVisibilityFilter to filter properties visible on UI and use it in View/configure.jelly.I will do the code modification in the same PR.
Add Comment
[JIRA] (JENKINS-60580) TaskListener should support a debug flag for finer granined messages
Title: Message Title James Nord created an issue Jenkins / JENKINS-60580 TaskListener should support a debug flag for finer granined messages Issue Type: Improvement Assignee: Unassigned Components: core Created: 2019-12-24 11:27 Priority: Minor Reporter: James Nord Often it is usefull to add some extra logging to a run / task. however this needs to be encased in conditional and all parts need to support this. It would be benificial if the `TaskListener` supported a `debug(String, format)` / `debug(String)` method so that code can call it unconditionally and whatever creates the TaskListener could just set a flag to eanble or disable this logging. Add Comment
[JIRA] (JENKINS-60581) Plugin Compat Tester should not print Maven download logs in process-test-classes steps
Title: Message Title Oleg Nenashev updated an issue Jenkins / JENKINS-60581 Plugin Compat Tester should not print Maven download logs in process-test-classes steps Change By: Oleg Nenashev Labels: newbie-friendly Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.203706.1577188091000.15339.1577188140189%40Atlassian.JIRA.
[JIRA] (JENKINS-60581) Plugin Compat Tester should not print Maven download logs in process-test-classes steps
Title: Message Title Oleg Nenashev created an issue Jenkins / JENKINS-60581 Plugin Compat Tester should not print Maven download logs in process-test-classes steps Issue Type: Improvement Assignee: Unassigned Components: plugin-compat-tester Created: 2019-12-24 11:48 Priority: Minor Reporter: Oleg Nenashev https://github.com/jenkinsci/plugin-compat-tester/search?q=process-test-classes&unscoped_q=process-test-classes Flags for skipping the download are not passed according to the build log ( -Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=warn ): [2019-12-24T11:35:57.092Z] running [mvn, --show-version, --batch-mode, --settings=/home/jenkins/workspace/ries_plugin-compat-tester_PR-194/plugins-compat-tester/target/test-classes/m2-settings.xml, --define=failIfNoTests=false, clean, process-test-classes, -Dmaven.javadoc.skip] in /tmp/junit2590892589758669502/accurev >> /home/jenkins/workspace/ries_plugin-compat-tester_PR-194/plugins-compat-tester/../reports/logs/accurev/v0.7.22_against_org.jenkins-ci.plugins_plugin_1.410.log [2019-12-24T11:35:57.092Z] Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) [2019-12-24T11:35:57.092Z] Maven home: /home/jenkins/tools/hudson.tasks.Maven_MavenInstallation/mvn [2019-12-24T11:35:57.092Z] Java version: 1.8.0_162, vendor: Oracle Corporation, runtime: /home/jenkins/tools/hudson.model.JDK/jdk8/jre [2019-12-24T11:35:57.092Z] Default locale: en, platform encoding: UTF-8 [2019-12-24T11:35:57.092Z] OS name: "linux", version: "5.0.0-1027-azure", arch: "amd64", family: "unix" [2019-12-24T11:35:58.989Z] [INFO] Downloading from UK: http://uk.maven.org/maven2/io/jenkins/tools/incrementals/git-changelist-maven-extension/1.0-beta-4/git-changelist-maven-extension-1.0-beta-4.pom [2019-12-24T11:35:58.989Z
[JIRA] (JENKINS-60582) PCT does not use the Azure mirror for some steps in Jenkinsfile
Title: Message Title Oleg Nenashev commented on JENKINS-60582 Re: PCT does not use the Azure mirror for some steps in Jenkinsfile Log before the timeout: Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.203707.157718922.15342.1577189280301%40Atlassian.JIRA.
[JIRA] (JENKINS-60582) PCT does not use the Azure mirror for some steps in Jenkinsfile
Title: Message Title Oleg Nenashev updated an issue Jenkins / JENKINS-60582 PCT does not use the Azure mirror for some steps in Jenkinsfile Change By: Oleg Nenashev Attachment: image-2019-12-24-13-07-51-506.png Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.203707.157718922.15341.1577189280289%40Atlassian.JIRA.
[JIRA] (JENKINS-60582) PCT does not use the Azure mirror for some steps in Jenkinsfile
Title: Message Title Oleg Nenashev created an issue Jenkins / JENKINS-60582 PCT does not use the Azure mirror for some steps in Jenkinsfile Issue Type: Bug Assignee: Unassigned Attachments: image-2019-12-24-13-07-51-506.png Components: plugin-compat-tester Created: 2019-12-24 12:07 Priority: Minor Reporter: Oleg Nenashev From https://ci.jenkins.io/blue/organizations/jenkins/jenkinsci-libraries%2Fplugin-compat-tester/detail/PR-194/11/pipeline . org.jenkins.tools.test.PluginCompatTesterTest does not seem to use the settings file properly for plugin tests on the Linux agent. I see the settings file in the command line tho [2019-12-24T11:35:57.092Z] running [mvn, --show-version, --batch-mode, --settings=/home/jenkins/workspace/ries_plugin-compat-tester_PR-194/plugins-compat-tester/target/test-classes/m2-settings.xml, --define=failIfNoTests=false, clean, process-test-classes, -Dmaven.javadoc.skip] in /tmp/junit2590892589758669502/accurev >> /home/jenkins/workspace/ries_plugin-compat-tester_PR-194/plugins-compat-tester/../reports/logs/accurev/v0.7.22_against_org.jenkins-ci.plugins_plugin_1.410.log Log: at 0 B/s) [2019-12-24T12:02:49.261Z] [INFO] Downloading from maven.jenkins-ci.org: http://maven.jenkins-ci.org/content/groups/artifacts/commons-beanutils/commons-beanutils/1.7.0/commons-beanutils-1.7.0.pom [2019-12-24T12:03:21.313Z] [INFO] Downloading from repo.jenkins-ci.org: https://repo.jenkins-ci.org/public/commons-beanutils/commons-beanutils/1.7.0/commons-beanutils-1.7.0.pom [2019-12-24T12:03:21.313Z] [INFO] Downloaded from repo.jenkins-ci.org: https://repo.jenkins-ci.org/public/commons-beanutils/commons-beanutils/1.7.0/commons-beanutils-1.7.0.pom (0 B at 0 B/s) [2019-12-24T12:03:21.313Z] [INFO] Downloading from maven.jenkins-ci.org: http://maven.jenkins-ci.org/cont
[JIRA] (JENKINS-60582) PCT does not use the Azure mirror for some steps in Jenkinsfile
Title: Message Title Oleg Nenashev started work on JENKINS-60582 Change By: Oleg Nenashev Status: Open In Progress Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.203707.157718922.15344.1577190540191%40Atlassian.JIRA.
[JIRA] (JENKINS-60582) PCT does not use the Azure mirror for some steps in Jenkinsfile
Title: Message Title Oleg Nenashev assigned an issue to Oleg Nenashev Jenkins / JENKINS-60582 PCT does not use the Azure mirror for some steps in Jenkinsfile Change By: Oleg Nenashev Assignee: Oleg Nenashev Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.203707.157718922.15343.1577190540129%40Atlassian.JIRA.
[JIRA] (JENKINS-60582) PCT does not use the Azure mirror for some steps in Jenkinsfile
Title: Message Title Oleg Nenashev commented on JENKINS-60582 Re: PCT does not use the Azure mirror for some steps in Jenkinsfile It was actually a part of JENKINS-58813, becauseit change the default Maven version to external Maven. Hence the Maven settings were not longer passed by default. Worked it around by the environment check hack Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.203707.157718922.15345.1577192100161%40Atlassian.JIRA.
[JIRA] (JENKINS-60582) PCT does not use the Azure mirror for some steps in Jenkinsfile
Title: Message Title Oleg Nenashev resolved as Not A Defect Jenkins / JENKINS-60582 PCT does not use the Azure mirror for some steps in Jenkinsfile Change By: Oleg Nenashev Status: In Progress Resolved Resolution: Not A Defect Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.203707.157718922.15346.1577192100206%40Atlassian.JIRA.
[JIRA] (JENKINS-60583) PCT - JCasC integration test is unstable
Title: Message Title Oleg Nenashev created an issue Jenkins / JENKINS-60583 PCT - JCasC integration test is unstable Issue Type: Bug Assignee: Unassigned Components: plugin-compat-tester Created: 2019-12-24 13:00 Priority: Minor Reporter: Oleg Nenashev FYI Evaristo Gutierrez Baptiste Mathus Adrien Lecharpentier The integration tests fails on the master branch at the moment, likely due to some version deviation. I am going to disable the test for now to unblock the release Add Comment This mes
[JIRA] (JENKINS-60583) PCT - JCasC integration test is unstable
Title: Message Title Oleg Nenashev updated an issue Jenkins / JENKINS-60583 PCT - JCasC integration test is unstable Change By: Oleg Nenashev Labels: jcasc-devtools-compatibility Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.203708.1577192444000.15348.1577192460342%40Atlassian.JIRA.
[JIRA] (JENKINS-60416) Poll MailBox Trigger : The attached files are not found on the server
Title: Message Title NGAT Dev commented on JENKINS-60416 Re: Poll MailBox Trigger : The attached files are not found on the server Hello Nick Grealy Is there no progress on the issue yet? Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.203476.1575967429000.15350.1577192520118%40Atlassian.JIRA.
[JIRA] (JENKINS-44924) pipeline groovy script - Sort a list with custom comparator or closure not sorting
Title: Message Title Jesse Glick commented on JENKINS-44924 Re: pipeline groovy script - Sort a list with custom comparator or closure not sorting /pluginManager/installed; text console log in classic view, not Blue Ocean; and because the detector has false positives (it is very complicated). Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.182995.1497544785000.15353.1577197320891%40Atlassian.JIRA.
[JIRA] (JENKINS-60213) P4CLIENT environment variable non-reentrant
Title: Message Title
Matthew Smeeth commented on JENKINS-60213
Re: P4CLIENT environment variable non-reentrant
Hi, I've written an automated test to reproduce this issue, and looking into it further. It looks to me like the P4_CLIENT variable is actually correct, and it's actually the EXECUTOR NUMBER that is wrong in your script. I can demonstrate this by putting an extra bit of debugging into the p4 plugin when running jobs. I have modified my build so that it outputs the executor number as the job is executing and this is what I get: Obtained concurrentBuildsTest/jenkinsfile from p4-brunoCred-//depot/... //jenkins-${NODE_NAME}${JOB_NAME}${EXECUTOR_NUMBER}/... Running in Durability level: MAX_SURVIVABILITY[Pipeline] Start of Pipeline[Pipeline] nodeRunning on Jenkins in /var/jenkins_home/workspace/concurrentBuildsTestProject[Pipeline] {[Pipeline] stage[Pipeline] { (testStage)[Pipeline] script[Pipeline] {[Pipeline] dirRunning in /var/jenkins_home/workspace/concurrentBuildsTestProject/test[Pipeline] {[Pipeline] checkoutExecutor no at runtime:0 Extra debugging I've added to the p4 plugin .. .. .. + concurrentBuildsTest/script.sh = WORKSPACE: /var/jenkins_home/workspace/concurrentBuildsTestProject < CORRECT P4_CLIENT: jenkins-master-concurrentBuildsTestProject-0 CORRECT EXECUTOR NUMBER: 1 < Wrong executor number =
ERROR - Bad Workspace
ERROR - Bad P4 Client .. ..
Finished: FAILURE I have run this several times and every time the job fails, the result is the same, the workspace and client are correct, and the executor number outputted by the script is incorrect. I'm theorising that this is because when builds are running concurrently, in between the sync and the running of the script, the executor number gets overridden by the other jobs, hence it ends up incorrect when the script runs. Therefore I don't think the script we're using is suitable for testing this issue. It's worth noting I am using the latest changes which contains https://github.com/jenkinsci/p4-plugin/pull/113. Which fixes an issue very similar to this, where the workspace was being set wrong. I believe this was why you were getting a different p4 client and workspace. James Bateman, when available please can you retest your original scenario using a build with https://github.com/jenkinsci/p4-plugin/pull/113 in. As I suspect this may fix your issue.
[JIRA] (JENKINS-60213) P4CLIENT environment variable non-reentrant
Title: Message Title
Matthew Smeeth edited a comment on JENKINS-60213
Re: P4CLIENT environment variable non-reentrant
Hi, I've written an automated test to reproduce this issue, Looking into it further, it looks to me like the P4_CLIENT variable is actually correct, and it's actually the EXECUTOR NUMBER that is wrong in your script. I can demonstrate this by putting an extra bit of debugging into the p4 plugin when running jobs. I have modified my build so that it outputs the executor number as the job is executing and this is what I get: {code:java} Obtained concurrentBuildsTest/jenkinsfile from p4-brunoCred-//depot/... //jenkins-${NODE_NAME} - ${JOB_NAME} - ${EXECUTOR_NUMBER}/... Running in Durability level: MAX_SURVIVABILITY[Pipeline] Start of Pipeline[Pipeline] nodeRunning on [ Jenkins |http://localhost:5003/computer/(master)/] in /var/jenkins_home/workspace/concurrentBuildsTestProject[Pipeline] {[Pipeline] stage[Pipeline] { (testStage)[Pipeline] script[Pipeline] {[Pipeline] dirRunning in /var/jenkins_home/workspace/concurrentBuildsTestProject/test[Pipeline] {[Pipeline] checkoutExecutor no at runtime:0 Extra debugging I've added to the p4 plugin .. .. .. + concurrentBuildsTest/script.sh = WORKSPACE: /var/jenkins_home/workspace/concurrentBuildsTestProject < CORRECT P4_CLIENT: jenkins-master-concurrentBuildsTestProject-0 CORRECT EXECUTOR NUMBER: 1 < Wrong executor number = * ** *** ERROR - Bad Workspace *** ERROR - Bad P4 Client .. .. Finished: FAILURE {code} I have run this several times and every time the job fails, the result is the same, the workspace and client are correct, and the executor number outputted by the script is incorrect.I'm theorising that this is because when builds are running concurrently, in between the sync and the running of the script, the executor number gets overridden by the other jobs, hence it ends up incorrect when the script runs. Therefore I don't think the script we're using is suitable for testing this issue. It's worth noting I am using the latest changes which contains [https://github.com/jenkinsci/p4-plugin/pull/113]. Which fixes an issue very similar to this, where the workspace was being set wrong. I believe this was why you were getting a different p4 client and workspace. [~jbateman], when available please can you retest your original scenario using a build with [https://github.com/jenkinsci/p4-plugin/pull/113] in. As I suspect this may fix your issue.
Add Comment
[JIRA] (JENKINS-60213) P4CLIENT environment variable non-reentrant
Title: Message Title
Matthew Smeeth edited a comment on JENKINS-60213
Re: P4CLIENT environment variable non-reentrant
Hi, I've written an automated test to reproduce this issue, and looking Looking into it further . It , it looks to me like the P4_CLIENT variable is actually correct, and it's actually the EXECUTOR NUMBER that is wrong in your script. I can demonstrate this by putting an extra bit of debugging into the p4 plugin when running jobs. I have modified my build so that it outputs the executor number as the job is executing and this is what I get: Obtained concurrentBuildsTest/jenkinsfile from p4-brunoCred-//depot/... //jenkins-${NODE_NAME}-${JOB_NAME}-${EXECUTOR_NUMBER}/...Running in Durability level: MAX_SURVIVABILITY[Pipeline] Start of Pipeline[Pipeline] nodeRunning on [Jenkins|http://localhost:5003/computer/(master)/] in /var/jenkins_home/workspace/concurrentBuildsTestProject[Pipeline] {[Pipeline] stage[Pipeline] { (testStage)[Pipeline] script[Pipeline] {[Pipeline] dirRunning in /var/jenkins_home/workspace/concurrentBuildsTestProject/test[Pipeline] {[Pipeline] checkoutExecutor no at runtime:0 Extra debugging I've added to the p4 plugin..+ concurrentBuildsTest/script.sh= WORKSPACE: /var/jenkins_home/workspace/concurrentBuildsTestProject < CORRECTP4_CLIENT: jenkins-master-concurrentBuildsTestProject-0 CORRECTEXECUTOR NUMBER: 1 < Wrong executor number= * ** * ** ERROR - Bad Workspace*** ERROR - Bad P4 ClientFinished: FAILURE I have run this several times and every time the job fails, the result is the same, the workspace and client are correct, and the executor number outputted by the script is incorrect.I'm theorising that this is because when builds are running concurrently, in between the sync and the running of the script, the executor number gets overridden by the other jobs, hence it ends up incorrect when the script runs. Therefore I don't think the script we're using is suitable for testing this issue. It's worth noting I am using the latest changes which contains [https://github.com/jenkinsci/p4-plugin/pull/113]. Which fixes an issue very similar to this, where the workspace was being set wrong. I believe this was why you were getting a different p4 client and workspace. [~jbateman], when available please can you retest your original scenario using a build with [https://github.com/jenkinsci/p4-plugin/pull/113] in. As I suspect this may fix your issue.
Add Comment
[JIRA] (JENKINS-60213) P4CLIENT environment variable non-reentrant
Title: Message Title
Matthew Smeeth edited a comment on JENKINS-60213
Re: P4CLIENT environment variable non-reentrant
Hi, I've written an automated test to reproduce this issue, Looking into it further, it looks to me like the P4_CLIENT variable is actually correct, and it's actually the EXECUTOR NUMBER that is wrong in your script. I can demonstrate this by putting an extra bit of debugging into the p4 plugin when running jobs. I have modified my build so that it outputs the executor number as the job is executing and this is what I get: {code:java}Obtained concurrentBuildsTest/jenkinsfile from p4-brunoCred-//depot/... //jenkins-${NODE_NAME}${JOB_NAME}${EXECUTOR_NUMBER}/...Running in Durability level: MAX_SURVIVABILITY[Pipeline] Start of Pipeline[Pipeline] nodeRunning on Jenkins in /var/jenkins_home/workspace/concurrentBuildsTestProject[Pipeline] {[Pipeline] stage[Pipeline] { (testStage)[Pipeline] script[Pipeline] {[Pipeline] dirRunning in /var/jenkins_home/workspace/concurrentBuildsTestProject/test[Pipeline] {[Pipeline] checkoutExecutor no at runtime:0 Extra debugging I've added to the p4 plugin .. .. .. + concurrentBuildsTest/script.sh = WORKSPACE: /var/jenkins_home/workspace/concurrentBuildsTestProject < CORRECT P4_CLIENT: jenkins-master-concurrentBuildsTestProject-0 CORRECT EXECUTOR NUMBER: 1 < Wrong executor number =ERROR - Bad WorkspaceERROR - Bad P4 Client .. ..Finished: FAILURE{code} I have run this several times and every time the job fails, the result is the same, the workspace and client are correct, and the executor number outputted by the script is incorrect.I'm theorising that this is because when builds are running concurrently, in between the sync and the running of the script, the executor number gets overridden by the other jobs, hence it ends up incorrect when the script runs. Therefore I don't think the script we're using is suitable for testing this issue. It's worth noting I am using the latest changes which contains [https://github.com/jenkinsci/p4-plugin/pull/113]. Which fixes an issue very similar to this, where the workspace was being set wrong. I believe this was why you were getting a different p4 client and workspace. [~jbateman], when available please can you retest your original scenario using a build with [https://github.com/jenkinsci/p4-plugin/pull/113] in. As I suspect this may fix your issue.
Add Comment
[JIRA] (JENKINS-60213) P4CLIENT environment variable non-reentrant
Title: Message Title
Matthew Smeeth edited a comment on JENKINS-60213
Re: P4CLIENT environment variable non-reentrant
Hi, I've written an automated test to reproduce this issue, Looking into it further, it looks to me like the P4_CLIENT variable is actually correct, and it's actually the EXECUTOR NUMBER that is wrong in your script. I can demonstrate this by putting an extra bit of debugging into the p4 plugin when running jobs. I have modified my build so that it outputs the executor number as the job is executing and this is what I get: {code:java}Obtained concurrentBuildsTest/jenkinsfile from p4-brunoCred-//depot/... //jenkins-${NODE_NAME}${JOB_NAME}${EXECUTOR_NUMBER}/... Running in Durability level: MAX_SURVIVABILITY [Pipeline] Start of Pipeline [Pipeline] nodeRunning nodeRunning on Jenkins in /var/jenkins_home/workspace/concurrentBuildsTestProject [Pipeline] { [Pipeline] stage [Pipeline] { (testStage) [Pipeline] script [Pipeline] { [Pipeline] dirRunning dirRunning in /var/jenkins_home/workspace/concurrentBuildsTestProject/test [Pipeline] { [Pipeline] checkoutExecutor checkoutExecutor no at runtime:0 Extra debugging I've added to the p4 plugin .. .. .. + concurrentBuildsTest/script.sh = WORKSPACE: /var/jenkins_home/workspace/concurrentBuildsTestProject < CORRECT P4_CLIENT: jenkins-master-concurrentBuildsTestProject-0 CORRECT EXECUTOR NUMBER: 1 < Wrong executor number =ERROR - Bad Workspace ERROR - Bad P4 Client .. ..Finished: FAILURE{code} I have run this several times and every time the job fails, the result is the same, the workspace and client are correct, and the executor number outputted by the script is incorrect.I'm theorising that this is because when builds are running concurrently, in between the sync and the running of the script, the executor number gets overridden by the other jobs, hence it ends up incorrect when the script runs. Therefore I don't think the script we're using is suitable for testing this issue. It's worth noting I am using the latest changes which contains [https://github.com/jenkinsci/p4-plugin/pull/113]. Which fixes an issue very similar to this, where the workspace was being set wrong. I believe this was why you were getting a different p4 client and workspace. [~jbateman], when available please can you retest your original scenario using a build with [https://github.com/jenkinsci/p4-plugin/pull/113] in. As I suspect this may fix your issue.
Add Comment
[JIRA] (JENKINS-60213) P4CLIENT environment variable non-reentrant
Title: Message Title
Matthew Smeeth edited a comment on JENKINS-60213
Re: P4CLIENT environment variable non-reentrant
Hi, I've written an automated test to reproduce this issue, Looking into it further, it looks to me like the P4_CLIENT variable is actually correct, and it's actually the EXECUTOR NUMBER that is wrong in your script. I can demonstrate this by putting an extra bit of debugging into the p4 plugin when running jobs. I have modified my build so that it outputs the executor number as the job is executing and this is what I get: {code:java}Obtained concurrentBuildsTest/jenkinsfile from p4-brunoCred-//depot/... //jenkins-${NODE_NAME}${JOB_NAME}${EXECUTOR_NUMBER}/...Running in Durability level: MAX_SURVIVABILITY[Pipeline] Start of Pipeline[Pipeline] nodeRunning on Jenkins in /var/jenkins_home/workspace/concurrentBuildsTestProject[Pipeline] {[Pipeline] stage[Pipeline] { (testStage)[Pipeline] script[Pipeline] {[Pipeline] dirRunning in /var/jenkins_home/workspace/concurrentBuildsTestProject/test[Pipeline] {[Pipeline] checkoutExecutor no at runtime:0 Extra debugging I've added to the p4 plugin .. .. .. + concurrentBuildsTest/script.sh = WORKSPACE: /var/jenkins_home/workspace/concurrentBuildsTestProject < CORRECT P4_CLIENT: jenkins-master-concurrentBuildsTestProject-0 CORRECT EXECUTOR NUMBER: 1 < Wrong executor number = ERROR - Bad Workspace ERROR - Bad P4 Client .. ..Finished: FAILURE{code} I have run this several times and every time the job fails, the result is the same, the workspace and client are correct, and the executor number outputted by the script is incorrect.I'm theorising that this is because when builds are running concurrently, in between the sync and the running of the script, the executor number gets overridden by the other jobs, hence it ends up incorrect when the script runs. Therefore I don't think the script we're using is suitable for testing this issue. It's worth noting I am using the latest changes which contains [https://github.com/jenkinsci/p4-plugin/pull/113]. Which fixes an issue very similar to this, where the workspace was being set wrong. I believe this was why you were getting a different p4 client and workspace. [~jbateman], when available please can you retest your original scenario using a build with [https://github.com/jenkinsci/p4-plugin/pull/113] in. As I suspect this may fix your issue.
Add Comment
[JIRA] (JENKINS-46376) Allow getting log through RunWrapper
Title: Message Title Alan Czajkowski commented on JENKINS-46376 Re: Allow getting log through RunWrapper really need a mechanism to safely access the build log inside declarative pipelines ... any ETA on this? Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.184640.1503479569000.15426.1577209680257%40Atlassian.JIRA.
[JIRA] (JENKINS-37858) Group based LDAP authentication does not work
Title: Message Title John Jeffers commented on JENKINS-37858 Re: Group based LDAP authentication does not work Any chance we can get someone to look into this? I have the same problem as others here, also using Jumpcloud. The only way I can get LDAP groups to work is if I give the user account "Enable as LDAP Bind DN" permissions. Without that, group memberships are not honored, and the logged in user does not get the permissions assigned to the group. Does anyone using other LDAP providers have this problem, or is this unique to Jumpcloud? Not really sure who I should be asking to fix this problem. Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.173992.1472656539000.15450.1577219820381%40Atlassian.JIRA.
[JIRA] (JENKINS-56175) Submodule with space in git URL won't update
Title: Message Title
Mark Waite updated an issue
Jenkins / JENKINS-56175
Submodule with space in git URL won't update
Change By:
Mark Waite
When a git submodule repository name includes a space character, the git plugin versions through at least git plugin 4.0.0 -rc ignore the submodule.Problem was found by the plugin pom 3.36 extension which includes a space character in the temporary directories created by the Jenkins test harness.For example, I defined a repository {{ssh://home.markwaite.net/\~/git/bare/bugs/without-space.git}} which includes a submodule from {{ssh://home.markwaite.net/\~/git/bare/bugs/with space.git}}. I can clone the {{without-space}} repository from the command line and can update the submodule. When I perform the same operation from a Jenkins job, the repository is cloned, but the submodule is not detected and never updates.
Add Comment
This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
--
You received this message because you are subscribed to the Google Groups "J
[JIRA] (JENKINS-58113) Remove the internal Maven mode from PCT
Title: Message Title Oleg Nenashev updated JENKINS-58113 Jenkins / JENKINS-58113 Remove the internal Maven mode from PCT Change By: Oleg Nenashev Status: In Review Resolved Resolution: Fixed Released As: PCT 0.4.0 Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.200157.1561016898000.15465.1577226720268%40Atlassian.JIRA.
[JIRA] (JENKINS-60584) Where to remove http server header version for jenkins based on Jetty?
Title: Message Title tracy cui created an issue Jenkins / JENKINS-60584 Where to remove http server header version for jenkins based on Jetty? Issue Type: Task Assignee: Unassigned Components: _unsorted Created: 2019-12-25 04:17 Priority: Major Reporter: tracy cui Set up Jenkins using K8S, and it shows the Jenkins server header is : Jetty(9.4.z-SNAPSHOT), the OS is Centos 7.5,did some investigation that the server header can be updated in Jenkins.xml , or Jetty.xml, but I can't find the jenkins.xml or jetty.xml, where to remove the server header? Add Comment
[JIRA] (JENKINS-60585) Jenkins triggers hundreds builds for one commit
Title: Message Title Aleksey Timin created an issue Jenkins / JENKINS-60585 Jenkins triggers hundreds builds for one commit Issue Type: Bug Assignee: Kirill Merkushev Components: blueocean-plugin, github-plugin Created: 2019-12-25 06:10 Environment: blue-ocean 1.21, jenkins 2.190.3, GitHub API Plugin 1.95 OS: ubuntu server 18.04.3 LTS Labels: jenkins blueocean Priority: Major Reporter: Aleksey Timin We use Jenkins + Blue Ocean to build our open-source project that hosted on GitHub. Sometimes we observe very strange behavior. When we push a commit into GitHub repo, Jenkins triggered several hundreds of the same builds for this commit. You can see it here: http://jenkins.asneg.de:8080/blue/organizations/jenkins/OpcUaWebServer/activity?branch=master Add Comment
[JIRA] (JENKINS-60585) Jenkins triggers hundreds builds for one commit
Title: Message Title Aleksey Timin updated an issue Jenkins / JENKINS-60585 Jenkins triggers hundreds builds for one commit Change By: Aleksey Timin We use Jenkins + Blue Ocean to build our open-source project projects that hosted on GitHub. Sometimes we observe very strange behavior. When we push a commit into GitHub repo, Jenkins triggered triggers several hundreds of the same builds for this commit. You can see it here: [ http://jenkins.asneg.de:8080/blue/organizations/jenkins/OpcUaWebServer/activity?branch=master ] Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.203711.1577254233000.15498.1577254320157%40Atlassian.JIRA.
[JIRA] (JENKINS-60586) build step are not shown on pipeline visualization for Parallel multi Node
Title: Message Title
avi shaaya created an issue
Jenkins / JENKINS-60586
build step are not shown on pipeline visualization for Parallel multi Node
Issue Type:
Bug
Assignee:
Unassigned
Attachments:
Screen Shot 2019-12-25 at 9.32.08.png
Components:
blueocean-plugin
Created:
2019-12-25 07:41
Environment:
Jenkins ver. 2.164.1 Blue Ocean 1.21.0
Priority:
Major
Reporter:
avi shaaya
I used the "Parallel Multiple Nodes" example from: https://jenkins.io/doc/pipeline/examples/#trigger-job-on-all-nodes. Heres my code: def labels = ['X', 'Y'] // labels for Jenkins node types we will build on def builders = [:] for (x in labels) { def label = x // Need to bind the label variable before the closure - can't do 'for (label in labels)' // Create a map to pass in to the 'parallel' step so we can fire all the builds at once builders[label] = { node(label) { stage("SCM") { echo env.STAGE_NAME } stage("Setup") { echo env.STAGE_NAME } stage("Build"){ echo env.STAGE_NAME } stage("Host unitTest") { echo env.STAGE_NAME } stage("DUT unitTest"){ echo env.STAGE_NAME } stage("QA tests") { echo env.STAGE_NAME } stage("Teardown"){ echo env.STAGE_NAME } } } } parallel builders i expected that BlueOcean will show the progress of each node (in parallel) but instead the progress is under the node name and can be viewed only when clicking the node name . ( see attached screenshot). I expected the following structure: start--XSCMSetupBuild–-Host unitTest–-DUT unitTest–QA tests–Teardown-–End |
