[JIRA] (JENKINS-57847) NPE when using Vault Plugin with older version of vault
Title: Message Title
Joshua Hoblitt commented on JENKINS-57847
Re: NPE when using Vault Plugin with older version of vault
I have also observed this with current master (2.2.1-SNAPSHOT (private-54946854-jhoblitt)) and vault 1.0.0.
java.lang.NullPointerException
at com.bettercloud.vault.api.Logical.read(Logical.java:73)
at com.datapipe.jenkins.vault.VaultAccessor.read(VaultAccessor.java:52)
at com.datapipe.jenkins.vault.VaultBuildWrapper.provideEnvironmentVariablesFromVault(VaultBuildWrapper.java:136)
at com.datapipe.jenkins.vault.VaultBuildWrapper.setUp(VaultBuildWrapper.java:89)
at org.jenkinsci.plugins.workflow.steps.CoreWrapperStep$Execution2.doStart(CoreWrapperStep.java:97)
at org.jenkinsci.plugins.workflow.steps.GeneralNonBlockingStepExecution.lambda$run$0(GeneralNonBlockingStepExecution.java:77)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Finished: FAILURE
It also looks like there is something strange with the behavior of the "Vault Token Credential" Credentials type – when "updating it" the token field is always blank (no ***}}s) as are present with the {{2.2.0 release.
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.
To view this
[JIRA] (JENKINS-55983) need mechanism to clear GitHubHookRegisterProblemMonitor errors without restart
Title: Message Title Joshua Hoblitt created an issue Jenkins / JENKINS-55983 need mechanism to clear GitHubHookRegisterProblemMonitor errors without restart Issue Type: Improvement Assignee: Kirill Merkushev Components: github-plugin Created: 2019-02-05 20:43 Environment: jenkins core 2.150.1 Priority: Minor Reporter: Joshua Hoblitt Errors managing github webhooks are recorded and displayed by GitHubHookRegisterProblemMonitor even if no job that currently exists references the listed repos (the warn may even reference to a repo that doesn't exist). There is no administrative mechanism to clear these errors short of restarting the jenkins master. This is sub-optimal as an ops team needs to either ignore these errors or keep track of which are bogus between master restarts. Add Comment
[JIRA] (JENKINS-54276) blueocean does not confirm build stop/cancel
Title: Message Title Joshua Hoblitt created an issue Jenkins / JENKINS-54276 blueocean does not confirm build stop/cancel Issue Type: Improvement Assignee: Unassigned Components: blueocean-plugin Created: 2018-10-26 17:27 Environment: blueocean 1.8.2 core 2.141 Priority: Minor Reporter: Joshua Hoblitt The classic UI uses a pop-up dialog to confirm stop/cancel/abort-ing a running build. One of my users has complained that under blueocean it is too easy to cancel another developers build with an accidental click. Add Comment
[JIRA] (JENKINS-53862) Blue Ocean spinner animation uses 25-50% CPU
Title: Message Title Joshua Hoblitt created an issue Jenkins / JENKINS-53862 Blue Ocean spinner animation uses 25-50% CPU Issue Type: Bug Assignee: Unassigned Attachments: Screenshot 2018-10-01 at 13.21.26.png, Screenshot from 2018-10-01 13-43-51.png Components: blueocean-plugin Created: 2018-10-01 20:44 Environment: Core 2.141 BO 1.8.2 Safari 12.0 on osx google-chrome Version 66.0.3359.181 (Official Build) (64-bit) on Fedora 28 Priority: Minor Reporter: Joshua Hoblitt I have had several complaints from end-users of the /activity page for a job causes high cpu usage – which is an issue when using a laptop running on battery. The issue seems to be the worst with chome using 40-50% of a CPU and closer to 25% of a core with safari. FF 62.0 seems to be much better but still 15% of a core seems excessive. The screenshots attacjed are with 2 running spinners .
[JIRA] (JENKINS-28335) Step to run Git commands w/ credentials & tool (was: GitPublisher support)
Title: Message Title
Joshua Hoblitt commented on JENKINS-28335
Re: Step to run Git commands w/ credentials & tool (was: GitPublisher support)
Its preferable to avoid writing secrets to the workspace. Although, ssh agent could theoretically be accessed from another worker by figuring out the SSH_AUTH_SOCK.
withEnv(['GIT_SSH_COMMAND=ssh -o StrictHostKeyChecking=no']) {
sshagent(credentials: ['your-github-key']) {
...
}
}
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-50947) Could not attach 'nodes/master/pipeline-timings.txt' to support bundle
Title: Message Title Joshua Hoblitt commented on JENKINS-50947 Re: Could not attach 'nodes/master/pipeline-timings.txt' to support bundle I'm see the same exception: Could not attach ''nodes/master/pipeline-timings.txt'' to support bundle java.io.IOException: dax/dax_webserv #1 did not yet start at org.jenkinsci.plugins.workflow.job.WorkflowRun$Owner.get(WorkflowRun.java:1125) at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution$PipelineTimings$1.writeTo(CpsFlowExecution.java:1881) at com.cloudbees.jenkins.support.SupportPlugin.writeBundle(SupportPlugin.java:305) at com.cloudbees.jenkins.support.SupportPlugin.writeBundle(SupportPlugin.java:275) at com.cloudbees.jenkins.support.SupportPlugin$PeriodicWorkImpl.lambda$doRun$0(SupportPlugin.java:759) at java.lang.Thread.run(Thread.java:748) 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-53359) job-dsl has deprecated concurrentBuild() on pipeline jobs
Title: Message Title Joshua Hoblitt created an issue Jenkins / JENKINS-53359 job-dsl has deprecated concurrentBuild() on pipeline jobs Issue Type: Bug Assignee: Daniel Spilker Components: job-dsl-plugin Created: 2018-08-30 22:26 Priority: Major Reporter: Joshua Hoblitt Per https://github.com/jenkinsci/job-dsl-plugin/wiki/Migration#migrating-to-170, and warnings in the console on seed jobs, concurrentBuild() is deprecated for pipeline jobs. Is this is error? concurrent builds can certainly be enabled/disabled on pipeline jobs. Add Comment
[JIRA] (JENKINS-51110) no test results visible in blueocean when following link from classic -> BO
Title: Message Title Joshua Hoblitt created an issue Jenkins / JENKINS-51110 no test results visible in blueocean when following link from classic -> BO Issue Type: Bug Assignee: Unassigned Attachments: blueocean-to-classic-to-blueocean-losses-tests-results.webm Components: blueocean-plugin Created: 2018-05-03 15:06 Environment: core 2.89.4 LTS blueocean 1.5.0 (final release) Labels: blueocean junit Priority: Minor Reporter: Joshua Hoblitt When exiting from a BO build view with junit test results (failures or all successful) to the classic UI, then following the link from the classic UI -> BO, the test results disappear. I noticed this after upgrading from BO 1.5.0-beta-2 -> 1.5.0 but I have not tested prior versions to see when this behavior started.
[JIRA] (JENKINS-46105) Docker 17.05 ARG in FROM breaks docker inspect
Title: Message Title
Joshua Hoblitt commented on JENKINS-46105
Re: Docker 17.05 ARG in FROM breaks docker inspect
This is also failing for me when the ARG has a default value. Ie., there is no --build-arg to parse.
ARG FOO=7
FROM centos:${FOO}
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-46105) Docker 17.05 ARG in FROM breaks docker inspect
Title: Message Title Joshua Hoblitt commented on JENKINS-46105 Re: Docker 17.05 ARG in FROM breaks docker inspect This seems to be a dup of JENKINS-44836? 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-50406) "Triggered Build" links broken with cloudbees-folder
Title: Message Title Joshua Hoblitt commented on JENKINS-50406 Re: "Triggered Build" links broken with cloudbees-folder +1 for the super fast fix. 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-50406) "Triggered Build" links broken with cloudbees-folder
Title: Message Title Joshua Hoblitt commented on JENKINS-50406 Re: "Triggered Build" links broken with cloudbees-folder +1 for the super fast fix. 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-50406) "Triggered Build" links broken with cloudbees-folder
Title: Message Title Joshua Hoblitt created an issue Jenkins / JENKINS-50406 "Triggered Build" links broken with cloudbees-folder Issue Type: Bug Assignee: Unassigned Attachments: Screenshot from 2018-03-26 08-24-02.png, Screenshot from 2018-03-26 08-24-12.png Components: blueocean-plugin Created: 2018-03-26 15:26 Environment: jenkins core 2.89.4 LTS blueocean 1.5.0-beta-2 Priority: Critical Reporter: Joshua Hoblitt The links to triggered builds are broken, at least when using cloudbees-folder (did not test with jobs at the "root"). It looks like the job portion of the URL path is not being escaped. Add Comment
[JIRA] (JENKINS-48868) blue ocean dashboard taking more than 50s to load.
Title: Message Title Joshua Hoblitt commented on JENKINS-48868 Re: blue ocean dashboard taking more than 50s to load. That sounds very plausible and being related to favorites would explain why my production env seems slower than test instances. No code was attached to the ticket – is jira supposed to be doing that for the blueocean repo? 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-48868) blue ocean dashboard taking more than 50s to load.
Title: Message Title Joshua Hoblitt commented on JENKINS-48868 Re: blue ocean dashboard taking more than 50s to load. What was the resolution? 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-49542) Scripts not permitted to use method java.util.Map isEmpty
Title: Message Title Joshua Hoblitt created an issue Jenkins / JENKINS-49542 Scripts not permitted to use method java.util.Map isEmpty Issue Type: Bug Assignee: Unassigned Components: workflow-cps-plugin Created: 2018-02-13 19:58 Environment: jenkins 2.89.3 (LTS) workflow-cps 2.43 Priority: Minor Reporter: Joshua Hoblitt [:].isEmpty() triggers the wrath of the sandbox. Add Comment
[JIRA] (JENKINS-43045) support for writing awscli profiles
Title: Message Title Joshua Hoblitt created an issue Jenkins / JENKINS-43045 support for writing awscli profiles Issue Type: Bug Assignee: Thorsten Hoeger Components: pipeline-aws-plugin Created: 2017/Mar/22 7:14 PM Priority: Minor Reporter: Joshua Hoblitt It would be very handy to have support for writing `awscli` profile files (eg.,`.aws/config`) for use with external programs. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
[JIRA] (JENKINS-27045) Cannot use jenkins-cli with github oauth plugin
Title: Message Title Joshua Hoblitt commented on JENKINS-27045 Re: Cannot use jenkins-cli with github oauth plugin What version of the core is needed to test this? 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-37718) Block Pipeline job while upstream or downstream projects are building
Title: Message Title
Joshua Hoblitt edited a comment on JENKINS-37718
Re: Block Pipeline job while upstream or downstream projects are building
I believe the advice was to use a pipeline job to orchestrate other jobs. E.g.{code:java}stage('foo') { retry(retries) {build job: 'bar' }}{code}
Add Comment
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
--
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-37718) Block Pipeline job while upstream or downstream projects are building
Title: Message Title
Joshua Hoblitt commented on JENKINS-37718
Re: Block Pipeline job while upstream or downstream projects are building
I believe the advice was to use a pipeline job orchestrate other jobs. E.g.
stage('foo') {
retry(retries) {
build job: 'bar'
}
}
Add Comment
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
--
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-41937) update center still reports 2.2 as latest release
Title: Message Title Joshua Hoblitt updated an issue Jenkins / JENKINS-41937 update center still reports 2.2 as latest release Change By: Joshua Hoblitt Attachment: Screenshot from 2017-02-10 10-05-29.png Attachment: Screenshot from 2017-02-10 10-05-13.png Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-41937) update center still reports 2.2 as latest release
Title: Message Title Joshua Hoblitt created an issue Jenkins / JENKINS-41937 update center still reports 2.2 as latest release Issue Type: Bug Assignee: Kohsuke Kawaguchi Components: swarm-plugin Created: 2017/Feb/10 5:04 PM Priority: Minor Reporter: Joshua Hoblitt The git repo has been tagged up to 3.3 but the wiki/updatecenter json are still listing 2.2 as the latest release. This is an annoyance as 2.2 does not work with the current lts release (2.32.2). Version > 2.2 are available in the update center archives. Add Comment
[JIRA] (JENKINS-34389) starting parallel matrix jobs with dynamic axes causes in wrong build configuration
Title: Message Title Joshua Hoblitt edited a comment on JENKINS-34389 Re: starting parallel matrix jobs with dynamic axes causes in wrong build configuration [~bboehmke] I am completely unqualified to judge thread synchronization in the jenkins core. I would recommend opening a PR as some people (at least me) often check look at open PRs for unmerged fixes. I haven't tried the patch yet but I am contemplating trying to rebase it on the current 1.18 release. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-34389) starting parallel matrix jobs with dynamic axes causes in wrong build configuration
Title: Message Title Joshua Hoblitt commented on JENKINS-34389 Re: starting parallel matrix jobs with dynamic axes causes in wrong build configuration Benjamin Böhmke I am completely unqualified to judge thread synchronization in the jenkins core. I would recommend opening a PR as some people (at least me) often check look at open PRs for unmerged fixes. I haven't tried the patch yet but I am contemplating trying to rebase it on the current 1.18 release. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-34389) starting parallel matrix jobs with dynamic axes causes in wrong build configuration
Title: Message Title Joshua Hoblitt commented on JENKINS-34389 Re: starting parallel matrix jobs with dynamic axes causes in wrong build configuration Benjamin Böhmke I couldn't find an PR for your mutex patch. Was it never submitted or is there a reason why it isn't mergable? Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-40842) swarm 2.2 SEGV w/ java-1.8.0-openjdk-1.8.0.111-0.b15.el6_8.x86_64
Title: Message Title Joshua Hoblitt commented on JENKINS-40842 Re: swarm 2.2 SEGV w/ java-1.8.0-openjdk-1.8.0.111-0.b15.el6_8.x86_64 I am continuing to see occasional slave segvs on el6 after updating java to `java-1.8.0-openjdk-1.8.0.121-0.b13.el7_3.x86_64`: # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x7f838915bee0, pid=1559, tid=0x7f8391396700 # # JRE version: OpenJDK Runtime Environment (8.0_121-b13) (build 1.8.0_121-b13) # Java VM: OpenJDK 64-Bit Server VM (25.121-b13 mixed mode linux-amd64 compressed oops) # Problematic frame: # C 0x7f838915bee0 # # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /tmp/hs_err_pid1559.log # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-41633) API tokens not supported as scan credentials
Title: Message Title Joshua Hoblitt updated an issue Jenkins / JENKINS-41633 API tokens not supported as scan credentials Change By: Joshua Hoblitt Summary: API tokens not supported as scan credential credentials Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-41633) API tokens not supported as scan credential
Title: Message Title Joshua Hoblitt created an issue Jenkins / JENKINS-41633 API tokens not supported as scan credential Issue Type: Bug Assignee: Kohsuke Kawaguchi Components: github-organization-folder-plugin Created: 2017/Feb/01 5:48 PM Environment: jenkins 2.19.4 github-organization-folder 1.5 Priority: Major Reporter: Joshua Hoblitt The drop down dialog to select github org scan credentials only lists `UsernamePasswordCredentialsImpl` credentials. While the `github` plugin also supports `StringCredentialsImpl` credentials – I found this rather confusing as I only use github API tokens. I have a preference for using API tokens with robots as it is somewhat easier to revoke access. Add Comment
[JIRA] (JENKINS-40842) swarm 2.2 SEGV w/ java-1.8.0-openjdk-1.8.0.111-0.b15.el6_8.x86_64
Title: Message Title Joshua Hoblitt updated an issue Jenkins / JENKINS-40842 swarm 2.2 SEGV w/ java-1.8.0-openjdk-1.8.0.111-0.b15.el6_8.x86_64 Change By: Joshua Hoblitt Attachment: hs_err_pid7403.log Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-40842) swarm 2.2 SEGV w/ java-1.8.0-openjdk-1.8.0.111-0.b15.el6_8.x86_64
Title: Message Title Joshua Hoblitt updated an issue Jenkins / JENKINS-40842 swarm 2.2 SEGV w/ java-1.8.0-openjdk-1.8.0.111-0.b15.el6_8.x86_64 Change By: Joshua Hoblitt Attachment: hs_err_pid7403.log Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-40842) swarm 2.2 SEGV w/ java-1.8.0-openjdk-1.8.0.111-0.b15.el6_8.x86_64
Title: Message Title Joshua Hoblitt created an issue Jenkins / JENKINS-40842 swarm 2.2 SEGV w/ java-1.8.0-openjdk-1.8.0.111-0.b15.el6_8.x86_64 Issue Type: Bug Assignee: Kohsuke Kawaguchi Attachments: hs_err_pid7403.log Components: swarm-plugin Created: 2017/Jan/05 4:29 PM Environment: CentOS release 6.8 (Final) java-1.8.0-openjdk-1.8.0.111-0.b15.el6_8.x86_64 Priority: Minor Reporter: Joshua Hoblitt I updated 2x centos 6 and 4x centos 7 swarm slaves to java 1.8.0.111-0.b15 yesterday morning. Overnight, both of the centos 6 slaves had died with a SEGV. # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x7fce95b91ee0, pid=7403, tid=0x7fce9dfe7700 # # JRE version: OpenJDK Runtime Environment (8.0_111-b15) (build 1.8.0_111-b15) # Java VM: OpenJDK 64-Bit Server VM (25.111-b15 mixed mode linux-amd64 compressed oops) # Problematic frame: # C 0x7fce95b91ee0 # # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /home/jenkins-slave/hs_err_pid7403.log # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp #
[JIRA] (JENKINS-28702) Clean up registry credentials
Title: Message Title Joshua Hoblitt commented on JENKINS-28702 Re: Clean up registry credentials I stumbled across this issue when a test job able to push without setting up registry credentials – which is rather horrifying. I understand there are concurrency concerns but could we at least have an option to force cleanup when exiting the `withRegistry` block? I only allow one docker build on a slave at a time so this would cover my present use case. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-37718) Block Pipeline job while upstream or downstream projects are building
Title: Message Title Joshua Hoblitt commented on JENKINS-37718 Re: Block Pipeline job while upstream or downstream projects are building I echo all of Volker Gimple's comments. A synchronization primitive would be really useful. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-37421) Pipeline Shared Groovy Libraries Plugin wiki page reports incorrect latest version
Title: Message Title Joshua Hoblitt created an issue Jenkins / JENKINS-37421 Pipeline Shared Groovy Libraries Plugin wiki page reports incorrect latest version Issue Type: Bug Assignee: Jesse Glick Components: workflow-plugin Created: 2016/Aug/15 6:13 PM Priority: Minor Reporter: Joshua Hoblitt https://wiki.jenkins-ci.org/display/JENKINS/Pipeline+Shared+Groovy+Libraries+Plugin reports that the latest version of workflow-cps-global-lib (what is the correct jira component for this plugin?) is 2.1. While 2.2 is the current latest release: https://updates.jenkins-ci.org/download/plugins/workflow-cps-global-lib/2.2/workflow-cps-global-lib.hpi Add Comment
[JIRA] (JENKINS-37012) Default groovy methods should be approved by default
Title: Message Title
Joshua Hoblitt commented on JENKINS-37012
Re: Default groovy methods should be approved by default
I agree that the whitelist should be more expansive or, if there is a security implication, a "safe" alternative should be provided for basic operations. The current state is that even checking for the existence of a job parameter requires admin approval.
getBinding().hasVariable("PRODUCT")
org.jenkinsci.plugins.scriptsecurity.sandbox.RejectedAccessException: Scripts not permitted to use method groovy.lang.Binding hasVariable java.lang.String
at org.jenkinsci.plugins.scriptsecurity.sandbox.whitelists.StaticWhitelist.rejectMethod(StaticWhitelist.java:176)
...
Add Comment
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
--
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-15063) support for multiple security realms with failover
Title: Message Title Joshua Hoblitt edited a comment on JENKINS-15063 Re: support for multiple security realms with failover Would it be feasible to have a special security realm plugin that functions somewhat like pam, in the sense that it could be configured to call a number of other security modules? I realize this would require modified versions of the existing security realm plugins but perhaps it would be a way forward without an ( incompatible |any) core change. 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-15063) support for multiple security realms with failover
Title: Message Title Joshua Hoblitt commented on JENKINS-15063 Re: support for multiple security realms with failover Would it be feasible to have a special security realm plugin that functions somewhat like pam, in the sense that it could be configured to call a number of other security modules? I realize this would require modified versions of the existing security realm plugins but perhaps it would be a way forward without an incompatible core change. 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] [active-directory-plugin] (JENKINS-33422) Provide a way to get back into Jenkins when active directory bind password expire
Title: Message Title Joshua Hoblitt commented on JENKINS-33422 Re: Provide a way to get back into Jenkins when active directory bind password expire See https://issues.jenkins-ci.org/browse/JENKINS-15063. Essentially, this would require an incompatible change. 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] [ec2-plugin] (JENKINS-34291) unable to configure VPC security groups
Title: Message Title Joshua Hoblitt commented on JENKINS-34291 Re: unable to configure VPC security groups It looks like I had put the VPC ID in place of the subnet ID. After removing all sg IDs, I got a useful error message. This was an ID10T problem but it would be incredibly useful to get an error message that the subnet ID is invalid when there are sg IDs specified. 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] [ec2-plugin] (JENKINS-34291) unable to configure VPC security groups
Title: Message Title Joshua Hoblitt created an issue Jenkins / JENKINS-34291 unable to configure VPC security groups Issue Type: Bug Assignee: Francis Upton Components: ec2-plugin Created: 2016/Apr/15 10:51 PM Environment: jenkins 1.651 ec2-plugin 1.31 Priority: Minor Reporter: Joshua Hoblitt I am attempting to to launch on demand instances into an existing VPC. If I set the security group to either the sg ID or the sg name, I get the below error in the logs. I tried created a new log recorder for all the classes under hudson.plugins.ec2.* but have not been able to find any more detailed debugging information. Apr 15, 2016 3:43:30 PM INFO hudson.plugins.ec2.SlaveTemplate logProvisionInfo Launching ami-3331f958 for template centos 7 Apr 15, 2016 3:43:30 PM WARNING hudson.plugins.ec2.EC2Cloud provision Exception during provisioning com.amazonaws.AmazonClientException: Security groups must all be VPC security groups to work in a VPC context at hudson.plugins.ec2.SlaveTemplate.getEc2SecurityGroups(SlaveTemplate.java:916) at hudson.plugins.ec2.SlaveTemplate.provisionOndemand(SlaveTemplate.java:476) at hudson.plugins.ec2.SlaveTemplate.provision(SlaveTemplate.java:377) at
[JIRA] [kubernetes-plugin] (JENKINS-34067) kubernetes exception from "Test Connection" button
Title: Message Title Joshua Hoblitt commented on JENKINS-34067 Re: kubernetes exception from "Test Connection" button It looks like blanking out the CA cert textbox resolves the error. 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] [kubernetes-plugin] (JENKINS-34067) kubernetes exception from "Test Connection" button
Title: Message Title Joshua Hoblitt updated an issue Jenkins / JENKINS-34067 kubernetes exception from "Test Connection" button Change By: Joshua Hoblitt Summary: kubernetes exception from "Test Connection" button 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] [kubernetes-plugin] (JENKINS-34067) exception from "Test Connection" button
Title: Message Title Joshua Hoblitt created an issue Jenkins / JENKINS-34067 exception from "Test Connection" button Issue Type: Bug Assignee: Carlos Sanchez Components: kubernetes-plugin Created: 2016/Apr/06 8:03 PM Environment: jenkins 1.651 kubernetes 0.5 Priority: Major Reporter: Joshua Hoblitt This stracetrace is displaced in the configuration dialog when attempt to test with valid credentials. Enabling/disabled tls cert validation seems to have no effect javax.servlet.ServletException: java.lang.StringIndexOutOfBoundsException: String index out of range: 1155 at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:796) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) at org.kohsuke.stapler.MetaClass$5.doDispatch(MetaClass.java:233) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:58) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:649) at org.kohsuke.stapler.Stapler.service(Stapler.java:238) ...
[JIRA] [core] (JENKINS-34035) 2.0 needs a stable/supported way to disable the Getting Started wizard
Title: Message Title Joshua Hoblitt commented on JENKINS-34035 Re: 2.0 needs a stable/supported way to disable the Getting Started wizard Keith Zantow If a concrete example would be helpful, this is what a jenkins deployment (partially driven by hiera data) using some of the experimental functionality in puppet-jenkins looks like: https://github.com/lsst-sqre/sandbox-jenkins-demo/blob/master/jenkins_demo/manifests/profile/master.pp#L5-L187 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-34035) 2.0 needs a stable/supported way to disable the Getting Started wizard
Title: Message Title
Joshua Hoblitt edited a comment on JENKINS-34035
Re: 2.0 needs a stable/supported way to disable the Getting Started wizard
[~kzantow] neither ` {{ puppet-jenkins ` }} or ` {{ chef-cookbooks/jenkins ` }} attempt to mange ` {{ config.xml ` }} directly. The main config potentially interacts with so many plugins that it becomes an all or nothing affair unless one wants to attempt to semantically understand the xstream serialization. And don't forget that plugins may also have independent config files (with somewhat difficult to predict names). I concede that it is possible to manage jenkins by copying all of the xstream dumps around as opaque blobs but this doesn't allow you to express any meaningful configuration via a CM tool. The same result could be achieved by copying around a tarball.Most of the CM integration I've looked at use some combination of the pre-canned CLI commands along with groovy scripts feed in via the CLI. I believe this has been the general preference over the REST API as an ssh public key may be user defined. However, I will confess to doing awful things in puppet-jenkins in order to be able to set the API key for a user account to a known value. While the gymnastics the CM integration maintainers are doing is working to a degree, it is painful and required requires considerable effort for every new feature.
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-34035) 2.0 needs a stable/supported way to disable the Getting Started wizard
Title: Message Title Joshua Hoblitt commented on JENKINS-34035 Re: 2.0 needs a stable/supported way to disable the Getting Started wizard Keith Zantow neither `puppet-jenkins` or `chef-cookbooks/jenkins` attempt to mange `config.xml` directly. The main config potentially interacts with so many plugins that it becomes an all or nothing affair unless one wants to attempt to semantically understand the xstream serialization. And don't forget that plugins may also have independent config files (with somewhat difficult to predict names). I concede that it is possible to manage jenkins by copying all of the xstream dumps around as opaque blobs but this doesn't allow you to express any meaningful configuration via a CM tool. The same result could be achieved by copying around a tarball. Most of the CM integration I've looked at use some combination of the pre-canned CLI commands along with groovy scripts feed in via the CLI. I believe this has been the general preference over the REST API as an ssh public key may be user defined. However, I will confess to doing awful things in puppet-jenkins in order to be able to set the API key for a user account to a known value. While the gymnastics the CM integration maintainers are doing is working to a degree, it is painful and required considerable effort for every new feature. 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-34035) 2.0 needs a stable/supported way to disable the Getting Started wizard
Title: Message Title Joshua Hoblitt commented on JENKINS-34035 Re: 2.0 needs a stable/supported way to disable the Getting Started wizard Daniel Beck That I am in favor of said PR, which is not as of this moment merged. 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-34035) 2.0 needs a stable/supported way to disable the Getting Started wizard
Title: Message Title Joshua Hoblitt commented on JENKINS-34035 Re: 2.0 needs a stable/supported way to disable the Getting Started wizard Speaking for myself, I deploy test instances of jenkins via puppet, with security configuration, several times a day. I neither need nor want "clippy" popping up at me nor do I want to be forced into screen scraping to perform an unattended deployment. Working well with Configuration Management is an absolutely critical component to a DevOps user narrative. Jenkins already does this poorly and making clippy mandatory only makes the situation worse. 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] [copyartifact-plugin] (JENKINS-34017) copyartifact dies with hudson.util.IOException2
Title: Message Title Joshua Hoblitt commented on JENKINS-34017 Re: copyartifact dies with hudson.util.IOException2 The same exception occurs under jenkins 1.656. 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] [copyartifact-plugin] (JENKINS-34017) copyartifact dies with hudson.util.IOException2
Title: Message Title Joshua Hoblitt created an issue Jenkins / JENKINS-34017 copyartifact dies with hudson.util.IOException2 Issue Type: Bug Assignee: Unassigned Components: copyartifact-plugin Created: 2016/Apr/05 3:38 AM Environment: jenkins 1.651 copyartifact 1.37 Priority: Major Reporter: Joshua Hoblitt Configurinig any job with the copyartifact-plugin causes a fatal exception when running a build. Started by user Joshua Hoblitt [EnvInject] - Loading node environment variables. Building remotely on jenkins-el6-1-febf2de4 (jenkins-el6-1 centos-6 swarm) in workspace /home/jenkins-slave/workspace/copy-test FATAL: Failed to copy /var/lib/jenkins/jobs/run-rebuild/builds/5/archive/results/manifest.txt to /home/jenkins-slave/workspace/copy-test/results/manifest.txt hudson.util.IOException2: Failed to copy /var/lib/jenkins/jobs/run-rebuild/builds/5/archive/results/manifest.txt to /home/jenkins-slave/workspace/copy-test/results/manifest.txt at hudson.plugins.copyartifact.FingerprintingCopyMethod.copyOne(FingerprintingCopyMethod.java:117) at hudson.plugins.copyartifact.FingerprintingCopyMethod.copyAll(FingerprintingCopyMethod.java:67) at
[JIRA] [core] (JENKINS-31094) Proposal: Jenkins Configuration DSL
Title: Message Title Joshua Hoblitt commented on JENKINS-31094 Re: Proposal: Jenkins Configuration DSL My $day_job uses puppet to manage Jenkins deployment, which is invaluable for being able to "test" the ci system. I am a strong "configuration management" proponent and a co-maintainer of the puppet-jenkins module. I have been working on managing jenkins' configuration state by quasi-serializing constructor parameters as JSON snippets passed in and out via the CLI jar and gave a puppetconf presentation on this effort titled Puppet vs. Jenkins. Perhaps needless to say, I have fairly well developed opinions about what makes an application easy to manage from a CM perspective. I have only briefly looked at the system-config-dsl plugin, so my comments are intended to be of a general nature rather than addressed to a specific implementation. While I can certainly see the utility of a groovy based DSL for complex configuration scenarios, I see this as more of a CM tool unto itself rather than a a good interface for puppet/chef/salt/etc. style CM engine. The fundamental concern I have is that this approach is "configuration as code" rather than "configuration as data". This makes it very difficult to introspect on and modify the configuration state in a meaningful way. One of the [perhaps poor] bits of advice I give when attempting to explain what makes a good CM integration, is to think about the module as presenting a native configuration API for the application rather than merely restoring state. This stems from the fact that most of the time, the CM end-user doesn't actually want to manage all of the state of an application. Typically, what they want to do is selectively manage state they care about while not disturbing defaults, boilerplate, or values of unknown function that may even change between application versions. It is, more(1) or less(2), possible to manage the configuration of jenkins by duplicating and resorting the xstream object dumps (1 for the moment, I am ignoring the issue of plugin management, which is its own nightmare; 2 less in that there are often minor changes between plugin versions that require opening the configuration and re-saving it and this completely breaks for encrypted values). The principle issues with the xstream dumps, from the CM point of view, is that the value of internal fields may be mangled in some way that is difficult to reproduce, are difficult for an end user to predict, are unstable (even white-space occasionally changes between core releases), and is it difficult to impossible predict which file a configuration value when end up and what the name of that file may be (eg, the dump file name for plugins), and that the semantics of no two XML documents are the same. The advantage of a configuration DSL over the xstream serialization, is that it will likely be much easier for an end-user highly familiar with the Jenkins internal APIs to reason directly in it rather than having to dump out a known state and store it away. The downside is, it isn't any easier, perhaps even harder, for a CM engine to express a management API and then dynamically generate the configuration. This means a CM interface will likely have to resort to shuffling opaque files around without any semantic understanding of the contents – that isn't an improvement over doing the same thing with xstream dumps. IMHO - the best [filesystem based] interface for a CM system is one that uses a well defined data/serialization format, allows the configuration to be split across multiple files in the now common foo.d style, and uses either extremely predictable file names (eg /etc/foo.conf), in
[JIRA] [packaging] (JENKINS-28803) error while update to version jenkins-1.617-1.1.noarch over yum upgrade
Title: Message Title Joshua Hoblitt commented on JENKINS-28803 Re: error while update to version jenkins-1.617-1.1.noarch over yum upgrade I'm seeing both the post install script and yum checksum failure. Is a patch release in the works? 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] [swarm-plugin] (JENKINS-17144) Add support for private keys for authentiation
Joshua Hoblitt commented on JENKINS-17144 Add support for private keys for authentiation I've run into the situation with GithubAuthorizationStrategy from github-oauth where the CLI must use an ssh key pair to function (-username/-password do not work it's not clear to me if this is an issue with CLI or the authorization strategy). However, swarm clients can not presently use an ssh key pair. After some thrashing around, I've discovered that swarm clients will function with the API token as the password for a user. However, the user account has to be created and the API token retrieved before clients can be configured. This is both non-orthogonal with how the CLI must authenticate and sub-optimal for configuration management. 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] [github-oauth-plugin] (JENKINS-27691) make Github OAuth Scopes configurable
Joshua Hoblitt commented on JENKINS-27691 make Github OAuth Scopes configurable Note that I opened a PR to adding this functionality on github last week: https://github.com/jenkinsci/github-oauth-plugin/pull/35 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] [github-oauth-plugin] (JENKINS-27764) unable to discover private github email addresses
Joshua Hoblitt created JENKINS-27764 unable to discover private github email addresses Issue Type: Bug Assignee: Sam Kottler Components: github-oauth-plugin Created: 06/Apr/15 7:32 PM Description: (Per discussion on this PR https://github.com/jenkinsci/github-oauth-plugin/pull/35#issuecomment-90203532) I've attempted to test the behavior of the user:email scope. I created a test user org and deleted the user from jenkins via the delete_user() method in puppet_helper.grovvy between each test (note that Jenkins also needs to be restarted to clear caching). The user:email scope appears to have no affect on being able to retrieve a user's email address. Only changing the user's github profile to have a public email address worked. I don't know if this is due to GH's scope's, org.kohsuke.github.GHUser, or something in the plugin itself. I can say that adding user:email by default doesn't make any sense at this point. Project: Jenkins Priority: Minor Reporter: Joshua Hoblitt 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] [github-oauth-plugin] (JENKINS-19668) Dont attempt to set email address property for a user upon login
Joshua Hoblitt closed JENKINS-19668 as Fixed Dont attempt to set email address property for a user upon login The referenced PR was merged on Jan 23, 2014 Change By: Joshua Hoblitt (06/Apr/15 7:19 PM) Status: Open Closed Resolution: Fixed 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] [github-oauth-plugin] (JENKINS-20845) Github Authorization Settings, users in Participant in Organization not given READ
Joshua Hoblitt commented on JENKINS-20845 Github Authorization Settings, users in Participant in Organization not given READ This should work if the `read:org` oauth scope is requested. I've opened a PR to make this configurable. See JENKINS-27691 / https://github.com/jenkinsci/github-oauth-plugin/pull/35 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] [github-oauth-plugin] (JENKINS-27688) JNLP slaves can not authenticate with GH authorization Strategy
Joshua Hoblitt created JENKINS-27688 JNLP slaves can not authenticate with GH authorization Strategy Issue Type: Bug Assignee: Sam Kottler Components: github-oauth-plugin Created: 31/Mar/15 6:53 PM Description: When the Github Commiter Authorization Strategy is enabled, there's no way from JNLP build slaves to authenticate. Eg. Attempting to connect to http://el7:8080/ fd2af378-3c43-49dc-b96f-1e39769a0ad1 Mar 28, 2015 2:17:06 PM org.apache.commons.httpclient.HttpMethodDirector authenticateHost WARNING: Required credentials not available for BASIC any realm@el7:8080 Mar 28, 2015 2:17:06 PM org.apache.commons.httpclient.HttpMethodDirector authenticateHost WARNING: Preemptive authentication requested but no default credentials available Could not obtain CSRF crumb. Response code: 404 This is essentially the same problem as JENKINS-27045, in that there's no way to retrieve or pass in an oauth token. The auth strategy needs to be able to fall back to another mechanism. Project: Jenkins Priority: Critical Reporter: Joshua Hoblitt 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] [github-oauth-plugin] (JENKINS-23324) GitHub OAuth 0.17 requires private access to all repositories
Joshua Hoblitt commented on JENKINS-23324 GitHub OAuth 0.17 requires private access to all repositories Unfortunately, I didn't turn up this issue when searching for oauth scopes before opening JENKINS-27691. I've opened a PR to make the requested scopes configurable from the UI. https://github.com/jenkinsci/github-oauth-plugin/pull/35 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] [github-oauth-plugin] (JENKINS-27691) make Github OAuth Scopes configurable
Joshua Hoblitt created JENKINS-27691 make Github OAuth Scopes configurable Issue Type: New Feature Assignee: Sam Kottler Components: github-oauth-plugin Created: 31/Mar/15 10:12 PM Description: The current default behavior is to request these scopes from GH: repo,read:org The repo scope is very broad and grants read/write permissions to public and private repos across all organizations to which the user is a member. This is a "deal breaker" for some of my end users and unnecessary since the relevant repos are all public. We need a mechanism to configure / reduce the requested scope(s). Project: Jenkins Priority: Critical Reporter: Joshua Hoblitt 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] [github-oauth-plugin] (JENKINS-27688) JNLP slaves can not authenticate with GH authorization Strategy
Joshua Hoblitt commented on JENKINS-27688 JNLP slaves can not authenticate with GH authorization Strategy Please pardon my unfamiliarity with Jenkins but I'm not following you. My build slaves are assembled using swarm and the swarm-client jar needs a username and password that can be used for http basic auth with the master. Eg. -username $JENKINS_USERNAME -password $JENKINS_PASSWORD Could you be more specific about what are you proposing as an alternative configuration? 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] [github-oauth-plugin] (JENKINS-27045) Cannot use jenkins-cli with github oauth plugin
Joshua Hoblitt commented on JENKINS-27045 Cannot use jenkins-cli with github oauth plugin I have a similar issue with --username but -i is working for me with 1.606. 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] [github-oauth-plugin] (JENKINS-27688) JNLP slaves can not authenticate with GH authorization Strategy
Joshua Hoblitt commented on JENKINS-27688 JNLP slaves can not authenticate with GH authorization Strategy I think I may have found a manual workaround but I don't think it can reasonably done with configuration management. I've managed to use the Jenkins API token as the swarm client --password after first logging in to the Jenkins master with a github user. 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.
