from:"Eric"

OK, well I have 1.4.2.  That said, I have 82 updates so I'll do as you say 
and update everything.  Hopefully this covers it.  Thanks Mark!!!

On Monday, December 4, 2023 at 2:44:29 PM UTC-7 Mark Waite wrote:

> On Monday, December 4, 2023 at 2:29:11 PM UTC-7 Eric wrote:
>
> I've started going through the plugins that have issues and pretty quickly 
> ran into the "conditional buildstep" plugin.  I can't disable this plugin 
> because I use it.  Do you have any suggestions?
>
> Thanks,
> Eric
>
>
> The conditional build step plugin was fixed in 1.4.0 
> <https://plugins.jenkins.io/conditional-buildstep/releases/#version_1.4.0> 
> for configuration form modernization.  The most recent release is 1.4.3.
>
> If you haven't updated to latest releases of the plugins, that's certainly 
> the first step.
>
> 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/8b8c479e-bae7-43a4-86d1-10798d646ca5n%40googlegroups.com.

Re: Unable to Save Project

I've started going through the plugins that have issues and pretty quickly 
ran into the "conditional buildstep" plugin.  I can't disable this plugin 
because I use it.  Do you have any suggestions?

Thanks,
Eric

On Monday, December 4, 2023 at 1:50:41 PM UTC-7 Mark Waite wrote:

> On Monday, December 4, 2023 at 1:40:26 PM UTC-7 Eric wrote:
>
> Hi All!  I have a project that I am unable to make changes to.  I can't 
> even make a comment in a field then save it down.  I can't even save it 
> down without a comment.  It throws up a screen saying "Oops!  A problem 
> occurred while processing a request."  Not sure where the physical log is, 
> it's not in /var/log/jenkins/jenkins.log.  So I go to Manage Jenkins/System 
> Log/All Jenkins Logs.  It has a big stack trace for the attempted save, 
> I'll paste it below.  Any idea what my issue is?  Thanks!
>
> Error while serving http://ipAddress:8080/job/ProjectName/configSubmit 
> java.lang.IllegalArgumentException: The frontend sent an unexpected list of 
> classes 
>
>
> That almost always means that one or more of the plugins that are active 
> on your system has not been updated for the configuration form 
> modernization that happened in Jenkins 2.277.1.
>
> You'll need to find and remove the plugins that have not been updated.  A 
> detailed guide is available at 
> https://community.jenkins.io/t/migrating-jenkins/894/5 
>
> 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/2ae14c25-cace-4bf1-a097-206a320e6a4an%40googlegroups.com.

Re: Unable to Save Project

Note that the project works fine to perform builds...

On Monday, December 4, 2023 at 1:40:26 PM UTC-7 eric@gmail.com wrote:

> Hi All!  I have a project that I am unable to make changes to.  I can't 
> even make a comment in a field then save it down.  I can't even save it 
> down without a comment.  It throws up a screen saying "Oops!  A problem 
> occurred while processing a request."  Not sure where the physical log is, 
> it's not in /var/log/jenkins/jenkins.log.  So I go to Manage Jenkins/System 
> Log/All Jenkins Logs.  It has a big stack trace for the attempted save, 
> I'll paste it below.  Any idea what my issue is?  Thanks!
>
> Error while serving http://ipAddress:8080/job/ProjectName/configSubmit 
> java.lang.IllegalArgumentException: The frontend sent an unexpected list of 
> classes 
> (["jenkins.mvn.DefaultSettingsProvider","jenkins.mvn.FilePathSettingsProvider"])
>  
> rather than an expected single class. See 
> https://www.jenkins.io/doc/developer/views/table-to-div-migration/ for 
> more information. at 
> org.kohsuke.stapler.RequestImpl$TypePair.convertJSON(RequestImpl.java:750) 
> Caused: java.lang.IllegalArgumentException: Failed to instantiate class 
> jenkins.mvn.SettingsProvider from 
> {"stapler-class":["jenkins.mvn.DefaultSettingsProvider","jenkins.mvn.FilePathSettingsProvider"],"$class":["jenkins.mvn.DefaultSettingsProvider","jenkins.mvn.FilePathSettingsProvider"]}
>  
> at 
> org.kohsuke.stapler.RequestImpl$TypePair.convertJSON(RequestImpl.java:771) 
> at org.kohsuke.stapler.RequestImpl.bindJSON(RequestImpl.java:551) at 
> org.kohsuke.stapler.RequestImpl.instantiate(RequestImpl.java:877) Caused: 
> java.lang.IllegalArgumentException: Failed to convert the settings 
> parameter of the constructor public 
> hudson.tasks.Maven(java.lang.String,java.lang.String,java.lang.String,java.lang.String,java.lang.String,boolean,jenkins.mvn.SettingsProvider,jenkins.mvn.GlobalSettingsProvider,boolean)
>  
> at org.kohsuke.stapler.RequestImpl.instantiate(RequestImpl.java:879) at 
> org.kohsuke.stapler.RequestImpl$TypePair.convertJSON(RequestImpl.java:768) 
> Caused: java.lang.IllegalArgumentException: Failed to instantiate class 
> hudson.tasks.Maven from 
> {"stapler-class":"hudson.tasks.Maven","$class":"hudson.tasks.Maven","name":"Maven-3.0","targets":"-e
>  
> clean install 
> -DskipTests=true","pom":"","properties":"","jvmOptions":"","injectBuildVariables":true,"usePrivateRepository":false,"":["0","0"],"settings":{"stapler-class":["jenkins.mvn.DefaultSettingsProvider","jenkins.mvn.FilePathSettingsProvider"],"$class":["jenkins.mvn.DefaultSettingsProvider","jenkins.mvn.FilePathSettingsProvider"]},"globalSettings":{"stapler-class":["jenkins.mvn.DefaultGlobalSettingsProvider","jenkins.mvn.FilePathGlobalSettingsProvider"],"$class":["jenkins.mvn.DefaultGlobalSettingsProvider","jenkins.mvn.FilePathGlobalSettingsProvider"]}}
>  
> at 
> org.kohsuke.stapler.RequestImpl$TypePair.convertJSON(RequestImpl.java:771) 
> at org.kohsuke.stapler.RequestImpl.bindJSON(RequestImpl.java:551) at 
> org.kohsuke.stapler.RequestImpl.bindJSON(RequestImpl.java:546) at 
> hudson.tasks.Maven$DescriptorImpl.newInstance(Maven.java:489) at 
> hudson.tasks.Maven$DescriptorImpl.newInstance(Maven.java:428) at 
> hudson.model.Descriptor.newInstancesFromHeteroList(Descriptor.java:1095) at 
> hudson.model.Descriptor.newInstancesFromHeteroList(Descriptor.java:1057) at 
> hudson.util.DescribableList.rebuildHetero(DescribableList.java:214) at 
> hudson.model.Project.submit(Project.java:233) at 
> hudson.model.Job.doConfigSubmit(Job.java:1345) at 
> hudson.model.AbstractProject.doConfigSubmit(AbstractProject.java:775) at 
> java.base/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:710)
>  
> at org.kohsuke.stapler.Function$MethodFunction.invoke(Function.java:397) 
> Caused: java.lang.reflect.InvocationTargetException at 
> org.kohsuke.stapler.Function$MethodFunction.invoke(Function.java:401) at 
> org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:409) at 
> org.kohsuke.stapler.Function.bindAndInvoke(Function.java:207) at 
> org.kohsuke.stapler.SelectionInterceptedFunction$Adapter.invoke(SelectionInterceptedFunction.java:36)
>  
> at 
> org.kohsuke.stapler.verb.HttpVerbInterceptor.invoke(HttpVerbInterceptor.java:48)
>  
> at 
> org.kohsuke.stapler.SelectionInterceptedFunction.bindAndInvoke(

Unable to Save Project

Hi All!  I have a project that I am unable to make changes to.  I can't 
even make a comment in a field then save it down.  I can't even save it 
down without a comment.  It throws up a screen saying "Oops!  A problem 
occurred while processing a request."  Not sure where the physical log is, 
it's not in /var/log/jenkins/jenkins.log.  So I go to Manage Jenkins/System 
Log/All Jenkins Logs.  It has a big stack trace for the attempted save, 
I'll paste it below.  Any idea what my issue is?  Thanks!

Error while serving http://ipAddress:8080/job/ProjectName/configSubmit 
java.lang.IllegalArgumentException: The frontend sent an unexpected list of 
classes 
(["jenkins.mvn.DefaultSettingsProvider","jenkins.mvn.FilePathSettingsProvider"])
 
rather than an expected single class. See 
https://www.jenkins.io/doc/developer/views/table-to-div-migration/ for more 
information. at 
org.kohsuke.stapler.RequestImpl$TypePair.convertJSON(RequestImpl.java:750) 
Caused: java.lang.IllegalArgumentException: Failed to instantiate class 
jenkins.mvn.SettingsProvider from 
{"stapler-class":["jenkins.mvn.DefaultSettingsProvider","jenkins.mvn.FilePathSettingsProvider"],"$class":["jenkins.mvn.DefaultSettingsProvider","jenkins.mvn.FilePathSettingsProvider"]}
 
at 
org.kohsuke.stapler.RequestImpl$TypePair.convertJSON(RequestImpl.java:771) 
at org.kohsuke.stapler.RequestImpl.bindJSON(RequestImpl.java:551) at 
org.kohsuke.stapler.RequestImpl.instantiate(RequestImpl.java:877) Caused: 
java.lang.IllegalArgumentException: Failed to convert the settings 
parameter of the constructor public 
hudson.tasks.Maven(java.lang.String,java.lang.String,java.lang.String,java.lang.String,java.lang.String,boolean,jenkins.mvn.SettingsProvider,jenkins.mvn.GlobalSettingsProvider,boolean)
 
at org.kohsuke.stapler.RequestImpl.instantiate(RequestImpl.java:879) at 
org.kohsuke.stapler.RequestImpl$TypePair.convertJSON(RequestImpl.java:768) 
Caused: java.lang.IllegalArgumentException: Failed to instantiate class 
hudson.tasks.Maven from 
{"stapler-class":"hudson.tasks.Maven","$class":"hudson.tasks.Maven","name":"Maven-3.0","targets":"-e
 
clean install 
-DskipTests=true","pom":"","properties":"","jvmOptions":"","injectBuildVariables":true,"usePrivateRepository":false,"":["0","0"],"settings":{"stapler-class":["jenkins.mvn.DefaultSettingsProvider","jenkins.mvn.FilePathSettingsProvider"],"$class":["jenkins.mvn.DefaultSettingsProvider","jenkins.mvn.FilePathSettingsProvider"]},"globalSettings":{"stapler-class":["jenkins.mvn.DefaultGlobalSettingsProvider","jenkins.mvn.FilePathGlobalSettingsProvider"],"$class":["jenkins.mvn.DefaultGlobalSettingsProvider","jenkins.mvn.FilePathGlobalSettingsProvider"]}}
 
at 
org.kohsuke.stapler.RequestImpl$TypePair.convertJSON(RequestImpl.java:771) 
at org.kohsuke.stapler.RequestImpl.bindJSON(RequestImpl.java:551) at 
org.kohsuke.stapler.RequestImpl.bindJSON(RequestImpl.java:546) at 
hudson.tasks.Maven$DescriptorImpl.newInstance(Maven.java:489) at 
hudson.tasks.Maven$DescriptorImpl.newInstance(Maven.java:428) at 
hudson.model.Descriptor.newInstancesFromHeteroList(Descriptor.java:1095) at 
hudson.model.Descriptor.newInstancesFromHeteroList(Descriptor.java:1057) at 
hudson.util.DescribableList.rebuildHetero(DescribableList.java:214) at 
hudson.model.Project.submit(Project.java:233) at 
hudson.model.Job.doConfigSubmit(Job.java:1345) at 
hudson.model.AbstractProject.doConfigSubmit(AbstractProject.java:775) at 
java.base/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:710)
 
at org.kohsuke.stapler.Function$MethodFunction.invoke(Function.java:397) 
Caused: java.lang.reflect.InvocationTargetException at 
org.kohsuke.stapler.Function$MethodFunction.invoke(Function.java:401) at 
org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:409) at 
org.kohsuke.stapler.Function.bindAndInvoke(Function.java:207) at 
org.kohsuke.stapler.SelectionInterceptedFunction$Adapter.invoke(SelectionInterceptedFunction.java:36)
 
at 
org.kohsuke.stapler.verb.HttpVerbInterceptor.invoke(HttpVerbInterceptor.java:48)
 
at 
org.kohsuke.stapler.SelectionInterceptedFunction.bindAndInvoke(SelectionInterceptedFunction.java:26)
 
at 
org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:140) 
at org.kohsuke.stapler.MetaClass$11.doDispatch(MetaClass.java:558) at 
org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:59) 
at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:770) at 
org.kohsuke.stapler.Stapler.invoke(Stapler.java:900) at 
org.kohsuke.stapler.MetaClass$4.doDispatch(MetaClass.java:289) at 
org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:59) 
at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:770) at 
org.kohsuke.stapler.Stapler.invoke(Stapler.java:900) at 
org.kohsuke.stapler.Stapler.invoke(Stapler.java:698) at 
org.kohsuke.stapler.Stapler.service(Stapler.java:248) at 
javax.servlet.http.HttpServlet.service(HttpServlet.java:590) at

Re: New build with higher priority

2023-05-26 Thread Eric Pyle

I have a colleague who does something like this by editing the
configuratio= n of a job, using the REST API. I have seen that when I
manually update the=  priority of a job in the queue and seen it take
effect immediately. Once t= he job starts running you can again edit to set
the priority back to its us= ual value. As long as there is only one
instance of the job in the queue (t= he one you want to prioritize) it
seems like this could work.

A similar idea would be to have a copy of the job with higher priority
(cou= ld be created on the fly) which would be triggered after cancelling
the reg= ular job.

Of course, if you are comfortable with Groovy, you could implement the
"ext= ernal" solution you mention in a job; maybe even as an optional build
step = in the job itself. I've done a similar thing to cancel jobs which
have been=  in the queue more than a specified time limit.

Regards,

Eric

On Fri, May 26, 2023 at 5:45 AM Fabian Cenedese  wrote:

> Hello
>
> I have a job where a new build should be able to cancel an
> already running build of the same job. The cancelling already
> works. What I have a problem with now is, when the build
> queue is so full (with other jobs) that the new build is not
> even looked at before the queue has been worked off. If I
> could give the new build a higher priority or lower the priority
> of the running build then the cancelling would jump in.
>
> I'm already using the priority sorter plugin but that only
> allows to configure a priority, not to change it, and it's also
> per job, not per build.
>
> Is there a way to achieve this in Jenkins? If not we'd have
> to resort to an external solution that would read the queued
> and running jobs and then issue a cancel on the running
> build if a new build is in the queue.
>
> Thanks
>
> bye  Fabi
>
> --
> 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/535c7b9078e6fcc7dbc9a5838eb83c6a%40indel.ch
> .
>

-- 
*Eric Pyle*

Siemens Digital Industries Software
Simulation and Test Solutions, Product Development
Lebanon, New Hampshire
eric.p...@siemens.com
http://www.sw.siemens.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/CAPrXuH3NNngJehCRgNKVECu9ZQ%3DYA0JtA7DhOU%2BNVUzSO2hvXg%40mail.gmail.com.

Re: Groovy Script

2022-12-13 Thread eric....@gmail.com

I pass them in the properties of the Builder.  That said, I just figured 
out a way to make it work.  For some reason or another, I needed on this 
server to instantiate the property.  So I set it up top as build_result 
with a default value of fail.  Then when it hits the groovy script, it sets 
it correctly.  Since it sets it correctly, I'm guessing I didn't have to 
set a default value, just instantiate it.  Either way, it's working so I'm 
good.  Thanks for trying to help!
On Tuesday, December 13, 2022 at 3:08:10 AM UTC-7 opay...@chsc.de wrote:

> How exactly do you pass the properties to ant?
>
>
> On 12 December 2022 22:16:36 CET, "eric@gmail.com"  
> wrote:
>>
>> Can someone please give me some println's I can put in there to figure 
>> out why it's not setting the build_result variable?  It doesn't make any 
>> sense to me that it works on one server but not another.  Thanks!
>>
>> On Monday, December 12, 2022 at 8:46:27 AM UTC-7 eric@gmail.com 
>> wrote:
>>
>>> That's interesting.  The println looks like it should be correct:
>>>
>>> upstream result: success
>>>
>>> Later when I try to use the variable in an ant call, it just shows the 
>>> variable instead of the value of it:
>>>
>>> -Dbuild_result=${build_result}
>>>
>>> I put it in the properties of the ant call:
>>>
>>> full.buildnumber=${full.buildnumber}
>>> build.time=${build.time}
>>> pk_build=${pk_build}
>>> build_result=${build_result}
>>>
>>> This has always worked in the past, just not since this latest upgrade 
>>> of jenkins.  I'm now on 2.375.1.
>>>
>>> On Friday, December 9, 2022 at 9:50:34 PM UTC-7 opay...@chsc.de wrote:
>>>
>>>> Hi,
>>>>
>>>> you mean upstreamResult/build_result?
>>>>
>>>> What does the println for upstreamResult say?
>>>> Which Jenkins version are you on?
>>>>
>>>> BR :)
>>>>
>>>>
>>>> On 9 December 2022 22:56:29 CET, "eric@gmail.com" <
>>>> eric@gmail.com> wrote:
>>>>>
>>>>> Hi!  Not sure what's going on but I have a groovy script that has been 
>>>>> setting the variable build_status for ages but it stopped working.  
>>>>>  Doesn't set the variable any longer.  Any ideas?  Here's the script:
>>>>>
>>>>> import hudson.model.*
>>>>>
>>>>> import jenkins.model.*
>>>>>
>>>>>   
>>>>>
>>>>> def resolver = Thread.currentThread().executable.buildVariableResolver
>>>>>
>>>>> def parent_job = resolver.resolve("upstream_job")
>>>>>
>>>>> def parent_build_number = resolver.resolve("upstream_bn")
>>>>>
>>>>>  
>>>>>
>>>>> def upstreamResult = 
>>>>> Hudson.instance.getJob("${parent_job}").getLastBuild().result
>>>>>
>>>>>  
>>>>>
>>>>> if(upstreamResult.equals(hudson.model.Result.FAILURE)) {
>>>>>
>>>>>   upstreamResult = "fail"
>>>>>
>>>>> } else {
>>>>>
>>>>>   upstreamResult = "${upstreamResult}".toLowerCase()  
>>>>>
>>>>> }
>>>>>
>>>>> println "upstream result: ${upstreamResult}"
>>>>>
>>>>>  
>>>>>
>>>>> def newParams = null
>>>>>
>>>>> def pl = new ArrayList()
>>>>>
>>>>>  
>>>>>
>>>>> pl.add(new StringParameterValue('build_result', upstreamResult))
>>>>>
>>>>>  
>>>>>
>>>>> def oldParams = build.getAction(ParametersAction.class)
>>>>>
>>>>> if(oldParams != null) {
>>>>>
>>>>>   newParams = oldParams.createUpdated(pl)
>>>>>
>>>>>   build.actions.remove(oldParams)
>>>>>
>>>>> } else {
>>>>>
>>>>>   newParams = new ParametersAction(pl)
>>>>>
>>>>> }
>>>>>
>>>>>  
>>>>>
>>>>> build.addAction(newParams)
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Eric
>>>>>
>>>>>

-- 
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/17539d32-6fd6-497e-8a0a-8f91499acb52n%40googlegroups.com.

Re: Groovy Script

2022-12-12 Thread eric....@gmail.com

Can someone please give me some println's I can put in there to figure out 
why it's not setting the build_result variable?  It doesn't make any sense 
to me that it works on one server but not another.  Thanks!

On Monday, December 12, 2022 at 8:46:27 AM UTC-7 eric@gmail.com wrote:

> That's interesting.  The println looks like it should be correct:
>
> upstream result: success
>
> Later when I try to use the variable in an ant call, it just shows the 
> variable instead of the value of it:
>
> -Dbuild_result=${build_result}
>
> I put it in the properties of the ant call:
>
> full.buildnumber=${full.buildnumber}
> build.time=${build.time}
> pk_build=${pk_build}
> build_result=${build_result}
>
> This has always worked in the past, just not since this latest upgrade of 
> jenkins.  I'm now on 2.375.1.
>
> On Friday, December 9, 2022 at 9:50:34 PM UTC-7 opay...@chsc.de wrote:
>
>> Hi,
>>
>> you mean upstreamResult/build_result?
>>
>> What does the println for upstreamResult say?
>> Which Jenkins version are you on?
>>
>> BR :)
>>
>>
>> On 9 December 2022 22:56:29 CET, "eric@gmail.com"  
>> wrote:
>>>
>>> Hi!  Not sure what's going on but I have a groovy script that has been 
>>> setting the variable build_status for ages but it stopped working.  
>>>  Doesn't set the variable any longer.  Any ideas?  Here's the script:
>>>
>>> import hudson.model.*
>>>
>>> import jenkins.model.*
>>>
>>>   
>>>
>>> def resolver = Thread.currentThread().executable.buildVariableResolver
>>>
>>> def parent_job = resolver.resolve("upstream_job")
>>>
>>> def parent_build_number = resolver.resolve("upstream_bn")
>>>
>>>  
>>>
>>> def upstreamResult = 
>>> Hudson.instance.getJob("${parent_job}").getLastBuild().result
>>>
>>>  
>>>
>>> if(upstreamResult.equals(hudson.model.Result.FAILURE)) {
>>>
>>>   upstreamResult = "fail"
>>>
>>> } else {
>>>
>>>   upstreamResult = "${upstreamResult}".toLowerCase()  
>>>
>>> }
>>>
>>> println "upstream result: ${upstreamResult}"
>>>
>>>  
>>>
>>> def newParams = null
>>>
>>> def pl = new ArrayList()
>>>
>>>  
>>>
>>> pl.add(new StringParameterValue('build_result', upstreamResult))
>>>
>>>  
>>>
>>> def oldParams = build.getAction(ParametersAction.class)
>>>
>>> if(oldParams != null) {
>>>
>>>   newParams = oldParams.createUpdated(pl)
>>>
>>>   build.actions.remove(oldParams)
>>>
>>> } else {
>>>
>>>   newParams = new ParametersAction(pl)
>>>
>>> }
>>>
>>>  
>>>
>>> build.addAction(newParams)
>>>
>>>
>>> Thanks,
>>> Eric
>>>
>>>

-- 
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/d32ec4bf-dd3f-416f-820a-c6eb8296f40fn%40googlegroups.com.

Re: Groovy Script

2022-12-12 Thread eric....@gmail.com

So I'm getting a different result on 2 different Jenkins servers.  I've 
upgraded on both.  The only difference between the 2 servers is that one is 
RHEL 7 and the other RHEL 8.  The RHEL 8 isn't working.  I have no clue why 
that is though.  It doesn't make sense that the same groovy script would 
behave differently in the 2 places.

On Monday, December 12, 2022 at 8:46:27 AM UTC-7 eric@gmail.com wrote:

> That's interesting.  The println looks like it should be correct:
>
> upstream result: success
>
> Later when I try to use the variable in an ant call, it just shows the 
> variable instead of the value of it:
>
> -Dbuild_result=${build_result}
>
> I put it in the properties of the ant call:
>
> full.buildnumber=${full.buildnumber}
> build.time=${build.time}
> pk_build=${pk_build}
> build_result=${build_result}
>
> This has always worked in the past, just not since this latest upgrade of 
> jenkins.  I'm now on 2.375.1.
>
> On Friday, December 9, 2022 at 9:50:34 PM UTC-7 opay...@chsc.de wrote:
>
>> Hi,
>>
>> you mean upstreamResult/build_result?
>>
>> What does the println for upstreamResult say?
>> Which Jenkins version are you on?
>>
>> BR :)
>>
>>
>> On 9 December 2022 22:56:29 CET, "eric@gmail.com"  
>> wrote:
>>>
>>> Hi!  Not sure what's going on but I have a groovy script that has been 
>>> setting the variable build_status for ages but it stopped working.  
>>>  Doesn't set the variable any longer.  Any ideas?  Here's the script:
>>>
>>> import hudson.model.*
>>>
>>> import jenkins.model.*
>>>
>>>   
>>>
>>> def resolver = Thread.currentThread().executable.buildVariableResolver
>>>
>>> def parent_job = resolver.resolve("upstream_job")
>>>
>>> def parent_build_number = resolver.resolve("upstream_bn")
>>>
>>>  
>>>
>>> def upstreamResult = 
>>> Hudson.instance.getJob("${parent_job}").getLastBuild().result
>>>
>>>  
>>>
>>> if(upstreamResult.equals(hudson.model.Result.FAILURE)) {
>>>
>>>   upstreamResult = "fail"
>>>
>>> } else {
>>>
>>>   upstreamResult = "${upstreamResult}".toLowerCase()  
>>>
>>> }
>>>
>>> println "upstream result: ${upstreamResult}"
>>>
>>>  
>>>
>>> def newParams = null
>>>
>>> def pl = new ArrayList()
>>>
>>>  
>>>
>>> pl.add(new StringParameterValue('build_result', upstreamResult))
>>>
>>>  
>>>
>>> def oldParams = build.getAction(ParametersAction.class)
>>>
>>> if(oldParams != null) {
>>>
>>>   newParams = oldParams.createUpdated(pl)
>>>
>>>   build.actions.remove(oldParams)
>>>
>>> } else {
>>>
>>>   newParams = new ParametersAction(pl)
>>>
>>> }
>>>
>>>  
>>>
>>> build.addAction(newParams)
>>>
>>>
>>> Thanks,
>>> Eric
>>>
>>>

-- 
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/da0cd1af-d8a9-42c6-8d85-806c3c743d51n%40googlegroups.com.

Re: Groovy Script

2022-12-12 Thread eric....@gmail.com

That's interesting.  The println looks like it should be correct:

upstream result: success

Later when I try to use the variable in an ant call, it just shows the 
variable instead of the value of it:

-Dbuild_result=${build_result}

I put it in the properties of the ant call:

full.buildnumber=${full.buildnumber}
build.time=${build.time}
pk_build=${pk_build}
build_result=${build_result}

This has always worked in the past, just not since this latest upgrade of 
jenkins.  I'm now on 2.375.1.

On Friday, December 9, 2022 at 9:50:34 PM UTC-7 opay...@chsc.de wrote:

> Hi,
>
> you mean upstreamResult/build_result?
>
> What does the println for upstreamResult say?
> Which Jenkins version are you on?
>
> BR :)
>
>
> On 9 December 2022 22:56:29 CET, "eric@gmail.com"  
> wrote:
>>
>> Hi!  Not sure what's going on but I have a groovy script that has been 
>> setting the variable build_status for ages but it stopped working.  
>>  Doesn't set the variable any longer.  Any ideas?  Here's the script:
>>
>> import hudson.model.*
>>
>> import jenkins.model.*
>>
>>   
>>
>> def resolver = Thread.currentThread().executable.buildVariableResolver
>>
>> def parent_job = resolver.resolve("upstream_job")
>>
>> def parent_build_number = resolver.resolve("upstream_bn")
>>
>>  
>>
>> def upstreamResult = 
>> Hudson.instance.getJob("${parent_job}").getLastBuild().result
>>
>>  
>>
>> if(upstreamResult.equals(hudson.model.Result.FAILURE)) {
>>
>>   upstreamResult = "fail"
>>
>> } else {
>>
>>   upstreamResult = "${upstreamResult}".toLowerCase()  
>>
>> }
>>
>> println "upstream result: ${upstreamResult}"
>>
>>  
>>
>> def newParams = null
>>
>> def pl = new ArrayList()
>>
>>  
>>
>> pl.add(new StringParameterValue('build_result', upstreamResult))
>>
>>  
>>
>> def oldParams = build.getAction(ParametersAction.class)
>>
>> if(oldParams != null) {
>>
>>   newParams = oldParams.createUpdated(pl)
>>
>>   build.actions.remove(oldParams)
>>
>> } else {
>>
>>   newParams = new ParametersAction(pl)
>>
>> }
>>
>>  
>>
>> build.addAction(newParams)
>>
>>
>> Thanks,
>> Eric
>>
>>

-- 
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/bb278fff-5dad-4b05-b695-49ffaf21d89fn%40googlegroups.com.

Groovy Script

2022-12-09 Thread eric....@gmail.com

Hi!  Not sure what's going on but I have a groovy script that has been 
setting the variable build_status for ages but it stopped working.  
 Doesn't set the variable any longer.  Any ideas?  Here's the script:

import hudson.model.*

import jenkins.model.*

  

def resolver = Thread.currentThread().executable.buildVariableResolver

def parent_job = resolver.resolve("upstream_job")

def parent_build_number = resolver.resolve("upstream_bn")

 

def upstreamResult = 
Hudson.instance.getJob("${parent_job}").getLastBuild().result

 

if(upstreamResult.equals(hudson.model.Result.FAILURE)) {

  upstreamResult = "fail"

} else {

  upstreamResult = "${upstreamResult}".toLowerCase()  

}

println "upstream result: ${upstreamResult}"

 

def newParams = null

def pl = new ArrayList()

 

pl.add(new StringParameterValue('build_result', upstreamResult))

 

def oldParams = build.getAction(ParametersAction.class)

if(oldParams != null) {

  newParams = oldParams.createUpdated(pl)

  build.actions.remove(oldParams)

} else {

  newParams = new ParametersAction(pl)

}

 

build.addAction(newParams)


Thanks,
Eric

-- 
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/696cf40d-52da-40db-b7da-0bd974551104n%40googlegroups.com.

Re: Running Jenkins as a Service in RHEL 8

2022-12-06 Thread eric....@gmail.com

Requesting this conversation to be deleted because I accidentally let a 
machine name in without scrubbing it.  Thanks!

On Monday, December 5, 2022 at 8:54:21 AM UTC-7 eric@gmail.com wrote:

> Not sure changing the home directory is the answer.  I think the true 
> answer resides in how to allow the jenkins service to run in SELINUX...
>
> On Monday, December 5, 2022 at 8:45:42 AM UTC-7 slide wrote:
>
>> Jenkins switched to systemd "recently" check this page for how to change 
>> env variables and such 
>> https://www.jenkins.io/doc/book/system-administration/systemd-services/ 
>>
>> On Mon, Dec 5, 2022 at 8:40 AM eric@gmail.com  
>> wrote:
>>
>>> Changing the JENKINS_HOME directory in that config file didn't work.  I 
>>> got the same error some it's using that link somewhere else...
>>>
>>> Thanks,
>>> Eric
>>>
>>> On Monday, December 5, 2022 at 8:09:31 AM UTC-7 eric@gmail.com 
>>> wrote:
>>>
>>>> Hi All,
>>>>
>>>> I'm running into an issue running Jenkins as a service in RHEL 8 with 
>>>> SELINUX running (I don't have a choice).  It seems since /var/lib/jenkins 
>>>> is a symbolic link to /opt/jenkins, SELINUX doesn't want to allow running 
>>>> the service from there.  Would it be acceptable to just change the value 
>>>> for JENKINS_HOME to /opt/jenkins in /etc/sysconfig/jenkins?  Thanks!
>>>>
>>>>
>>>> ]# journalctl -xe
>>>>
>>>>You can generate a 
>>>> local policy module to allow this access.
>>>>
>>>>Do
>>>>
>>>>allow this access 
>>>> for now by executing:
>>>>
>>>># ausearch -c 
>>>> '(jenkins)' --raw | audit2allow -M my-jenkins
>>>>
>>>># semodule -X 300 -i 
>>>> my-jenkins.pp
>>>>
>>>>
>>>>
>>>> Dec 02 10:45:03 nd655bd001 setroubleshoot[144816]: AnalyzeThread.run(): 
>>>> Set alarm timeout to 10
>>>>
>>>> Dec 02 10:45:03 nd655bd001 setroubleshoot[144816]: AnalyzeThread.run(): 
>>>> Cancel pending alarm
>>>>
>>>> Dec 02 10:45:07 nd655bd001 setroubleshoot[144816]: SELinux is 
>>>> preventing /usr/lib/systemd/systemd from read access on the lnk_file 
>>>> /var/lib/jenkins. For com>
>>>>
>>>> Dec 02 10:45:07 nd655bd001 setroubleshoot[144816]: SELinux is 
>>>> preventing /usr/lib/systemd/systemd from read access on the lnk_file 
>>>> /var/lib/jenkins.
>>>>
>>>>
>>>>
>>>>*  Plugin 
>>>> catchall_labels (83.8 confidence) suggests   ***
>>>>
>>>>
>>>>
>>>>If you want to allow 
>>>> systemd to have read access on the jenkins lnk_file
>>>>
>>>>Then you need to 
>>>> change the label on /var/lib/jenkins
>>>>
>>>>Do
>>>>
>>>># semanage fcontext 
>>>> -a -t FILE_TYPE '/var/lib/jenkins'
>>>>
>>>>where FILE_TYPE is 
>>>> one of the following: NetworkManager_etc_rw_t, NetworkManager_etc_t, 
>>>> NetworkManager_un>
>>>>
>>>>Then execute:
>>>>
>>>>restorecon -v 
>>>> '/var/lib/jenkins'
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>*  Plugin 
>>>> catchall (17.1 confidence) suggests   **
>>>>
>>>>

Re: Running Jenkins as a Service in RHEL 8

2022-12-05 Thread eric....@gmail.com

Not sure changing the home directory is the answer.  I think the true 
answer resides in how to allow the jenkins service to run in SELINUX...

On Monday, December 5, 2022 at 8:45:42 AM UTC-7 slide wrote:

> Jenkins switched to systemd "recently" check this page for how to change 
> env variables and such 
> https://www.jenkins.io/doc/book/system-administration/systemd-services/ 
>
> On Mon, Dec 5, 2022 at 8:40 AM eric@gmail.com  
> wrote:
>
>> Changing the JENKINS_HOME directory in that config file didn't work.  I 
>> got the same error some it's using that link somewhere else...
>>
>> Thanks,
>> Eric
>>
>> On Monday, December 5, 2022 at 8:09:31 AM UTC-7 eric@gmail.com wrote:
>>
>>> Hi All,
>>>
>>> I'm running into an issue running Jenkins as a service in RHEL 8 with 
>>> SELINUX running (I don't have a choice).  It seems since /var/lib/jenkins 
>>> is a symbolic link to /opt/jenkins, SELINUX doesn't want to allow running 
>>> the service from there.  Would it be acceptable to just change the value 
>>> for JENKINS_HOME to /opt/jenkins in /etc/sysconfig/jenkins?  Thanks!
>>>
>>>
>>> ]# journalctl -xe
>>>
>>>You can generate a 
>>> local policy module to allow this access.
>>>
>>>Do
>>>
>>>allow this access for 
>>> now by executing:
>>>
>>># ausearch -c 
>>> '(jenkins)' --raw | audit2allow -M my-jenkins
>>>
>>># semodule -X 300 -i 
>>> my-jenkins.pp
>>>
>>>
>>>
>>> Dec 02 10:45:03 nd655bd001 setroubleshoot[144816]: AnalyzeThread.run(): 
>>> Set alarm timeout to 10
>>>
>>> Dec 02 10:45:03 nd655bd001 setroubleshoot[144816]: AnalyzeThread.run(): 
>>> Cancel pending alarm
>>>
>>> Dec 02 10:45:07 nd655bd001 setroubleshoot[144816]: SELinux is preventing 
>>> /usr/lib/systemd/systemd from read access on the lnk_file /var/lib/jenkins. 
>>> For com>
>>>
>>> Dec 02 10:45:07 nd655bd001 setroubleshoot[144816]: SELinux is preventing 
>>> /usr/lib/systemd/systemd from read access on the lnk_file /var/lib/jenkins.
>>>
>>>
>>>
>>>*  Plugin 
>>> catchall_labels (83.8 confidence) suggests   ***
>>>
>>>
>>>
>>>If you want to allow 
>>> systemd to have read access on the jenkins lnk_file
>>>
>>>Then you need to 
>>> change the label on /var/lib/jenkins
>>>
>>>Do
>>>
>>># semanage fcontext 
>>> -a -t FILE_TYPE '/var/lib/jenkins'
>>>
>>>where FILE_TYPE is 
>>> one of the following: NetworkManager_etc_rw_t, NetworkManager_etc_t, 
>>> NetworkManager_un>
>>>
>>>Then execute:
>>>
>>>restorecon -v 
>>> '/var/lib/jenkins'
>>>
>>>
>>>
>>>
>>>
>>>*  Plugin 
>>> catchall (17.1 confidence) suggests   **
>>>
>>>
>>>
>>>If you believe that 
>>> systemd should be allowed read access on the jenkins lnk_file by default.
>>>
>>>Then you should 
>>> report this as a bug.
>>>
>>>You can generate a 
>>> local policy module to allow this access.
>>>
>>>Do
>>>
>>>

Re: Running Jenkins as a Service in RHEL 8

2022-12-05 Thread eric....@gmail.com

Changing the JENKINS_HOME directory in that config file didn't work.  I got 
the same error some it's using that link somewhere else...

Thanks,
Eric

On Monday, December 5, 2022 at 8:09:31 AM UTC-7 eric@gmail.com wrote:

> Hi All,
>
> I'm running into an issue running Jenkins as a service in RHEL 8 with 
> SELINUX running (I don't have a choice).  It seems since /var/lib/jenkins 
> is a symbolic link to /opt/jenkins, SELINUX doesn't want to allow running 
> the service from there.  Would it be acceptable to just change the value 
> for JENKINS_HOME to /opt/jenkins in /etc/sysconfig/jenkins?  Thanks!
>
>
> ]# journalctl -xe
>
>You can generate a 
> local policy module to allow this access.
>
>Do
>
>allow this access for 
> now by executing:
>
># ausearch -c 
> '(jenkins)' --raw | audit2allow -M my-jenkins
>
># semodule -X 300 -i 
> my-jenkins.pp
>
>
>
> Dec 02 10:45:03 nd655bd001 setroubleshoot[144816]: AnalyzeThread.run(): 
> Set alarm timeout to 10
>
> Dec 02 10:45:03 nd655bd001 setroubleshoot[144816]: AnalyzeThread.run(): 
> Cancel pending alarm
>
> Dec 02 10:45:07 nd655bd001 setroubleshoot[144816]: SELinux is preventing 
> /usr/lib/systemd/systemd from read access on the lnk_file /var/lib/jenkins. 
> For com>
>
> Dec 02 10:45:07 nd655bd001 setroubleshoot[144816]: SELinux is preventing 
> /usr/lib/systemd/systemd from read access on the lnk_file /var/lib/jenkins.
>
>
>
>*  Plugin 
> catchall_labels (83.8 confidence) suggests   ***
>
>
>
>If you want to allow 
> systemd to have read access on the jenkins lnk_file
>
>Then you need to change 
> the label on /var/lib/jenkins
>
>Do
>
># semanage fcontext -a 
> -t FILE_TYPE '/var/lib/jenkins'
>
>where FILE_TYPE is one 
> of the following: NetworkManager_etc_rw_t, NetworkManager_etc_t, 
> NetworkManager_un>
>
>Then execute:
>
>restorecon -v 
> '/var/lib/jenkins'
>
>
>
>
>
>*  Plugin catchall 
> (17.1 confidence) suggests   **
>
>
>
>If you believe that 
> systemd should be allowed read access on the jenkins lnk_file by default.
>
>Then you should report 
> this as a bug.
>
>You can generate a 
> local policy module to allow this access.
>
>Do
>
>allow this access for 
> now by executing:
>
># ausearch -c 
> '(jenkins)' --raw | audit2allow -M my-jenkins
>
># semodule -X 300 -i 
> my-jenkins.pp
>
>
>
> Dec 02 10:45:07 nd655bd001 setroubleshoot[144816]: AnalyzeThread.run(): 
> Set alarm timeout to 10
>
> Dec 02 10:45:18 nd655bd001 systemd[1]: setroubleshootd.service: Succeeded.
>
> -- Subject: Unit succeeded
>
> -- Defined-By: systemd
>
> -- Support: https://access.redhat.com/support 
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.redhat.com%2Fsupport=05%7C01%7Ceric.fetzer%40dynamo.works%7Cf073214ec53d487bba8c08dad4b081f9%7C20011f20d2a44579a5cc40c8d987672b%7C0%7C0%7C638056151829928292%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=WMisNWM7KMmRGWY7k0n4euY6NIyCo74ECMq42lMC64Q%3D=0>
>
> -- 
>
> -- The unit setroubleshootd.service has successfully entered the 'dead' 
> state.
>
> lines 5338-5376/5376 (END)
>

-- 
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/0c57cbc8-8b60-4f6b-852a-bc892b97af38n%40googlegroups.com.

Running Jenkins as a Service in RHEL 8

2022-12-05 Thread eric....@gmail.com

Hi All,

I'm running into an issue running Jenkins as a service in RHEL 8 with 
SELINUX running (I don't have a choice).  It seems since /var/lib/jenkins 
is a symbolic link to /opt/jenkins, SELINUX doesn't want to allow running 
the service from there.  Would it be acceptable to just change the value 
for JENKINS_HOME to /opt/jenkins in /etc/sysconfig/jenkins?  Thanks!


]# journalctl -xe

   You can generate a local 
policy module to allow this access.

   Do

   allow this access for 
now by executing:

   # ausearch -c 
'(jenkins)' --raw | audit2allow -M my-jenkins

   # semodule -X 300 -i 
my-jenkins.pp

   

Dec 02 10:45:03 nd655bd001 setroubleshoot[144816]: AnalyzeThread.run(): Set 
alarm timeout to 10

Dec 02 10:45:03 nd655bd001 setroubleshoot[144816]: AnalyzeThread.run(): 
Cancel pending alarm

Dec 02 10:45:07 nd655bd001 setroubleshoot[144816]: SELinux is preventing 
/usr/lib/systemd/systemd from read access on the lnk_file /var/lib/jenkins. 
For com>

Dec 02 10:45:07 nd655bd001 setroubleshoot[144816]: SELinux is preventing 
/usr/lib/systemd/systemd from read access on the lnk_file /var/lib/jenkins.

   

   *  Plugin 
catchall_labels (83.8 confidence) suggests   ***

   

   If you want to allow 
systemd to have read access on the jenkins lnk_file

   Then you need to change 
the label on /var/lib/jenkins

   Do

   # semanage fcontext -a 
-t FILE_TYPE '/var/lib/jenkins'

   where FILE_TYPE is one 
of the following: NetworkManager_etc_rw_t, NetworkManager_etc_t, 
NetworkManager_un>

   Then execute:

   restorecon -v 
'/var/lib/jenkins'

   

   

   *  Plugin catchall 
(17.1 confidence) suggests   **

   

   If you believe that 
systemd should be allowed read access on the jenkins lnk_file by default.

   Then you should report 
this as a bug.

   You can generate a local 
policy module to allow this access.

   Do

   allow this access for 
now by executing:

   # ausearch -c 
'(jenkins)' --raw | audit2allow -M my-jenkins

   # semodule -X 300 -i 
my-jenkins.pp

   

Dec 02 10:45:07 nd655bd001 setroubleshoot[144816]: AnalyzeThread.run(): Set 
alarm timeout to 10

Dec 02 10:45:18 nd655bd001 systemd[1]: setroubleshootd.service: Succeeded.

-- Subject: Unit succeeded

-- Defined-By: systemd

-- Support: https://access.redhat.com/support 


-- 

-- The unit setroubleshootd.service has successfully entered the 'dead' 
state.

lines 5338-5376/5376 (END)

-- 
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/8ce021ab-d787-4fe3-96d5-d5476a4aac75n%40googlegroups.com.

Re: Jenkins Won't start after latest ugrade

2022-09-14 Thread Eric Fetzer

Sorry Mark, used to happening onto fixes in 2 minutes.  I'll put the 11
minutes into the vid.  Thanks for all the help!

On Wed, Sep 14, 2022 at 2:35 PM Mark Waite 
wrote:

> Yet another technique, quoting from the link that I included earlier:
>
> > Make sure the default JVM is the newly installed version. If it is not,
> run systemctl edit jenkins and set either the JAVA_HOME environment
> variable or the JENKINS_JAVA_CMD environment variable
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Jenkins Users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/jenkinsci-users/00ogw3rHsCw/unsubscribe.
> To unsubscribe from this group and all its topics, 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/787a7314-9be4-42ca-9e88-5e8e4ade8a75n%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/CAByBicYMAq5xVi_rBuNYMr8ouj8FKcJ5j9zPmEdVscy-4yH3sg%40mail.gmail.com.

Re: Jenkins Won't start after latest ugrade

2022-09-14 Thread Eric Fetzer

Yep, it's correct but still won't start:

[root@nd645bd001 jenkins]# alternatives --config java

There is 1 program that provides 'java'.

  SelectionCommand
---
*+ 1   java-11-openjdk.x86_64
(/usr/lib/jvm/java-11-openjdk-11.0.16.0.8-1.el7_9.x86_64/bin/java)


Here's the error in journalctl:

-- The start-up result is done.
Sep 14 15:40:01 nd645bd001 CROND[90879]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Sep 14 15:40:01 nd645bd001 systemd[1]: Removed slice User Slice of root.
-- Subject: Unit user-0.slice has finished shutting down
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit user-0.slice has finished shutting down.
Sep 14 15:40:02 nd645bd001 goferd[1237]:
[WARNING][pulp.agent.1c5e8577-7a00-4d79-b04f-b69dc63299ac]
gofer.messaging.adapter.proton.reliability:54 - Connection amqps://
ne001rhc001.fireness.gov:5647 disconnected: Condition('amqp:resource-l
[root@nd645bd001 jenkins]#


Appears that jenkins may be expecting systemd rather than systemctl???
Just guessing...  Thanks!


On Wed, Sep 14, 2022 at 2:32 PM Mark Waite 
wrote:

>
>
> On Wednesday, September 14, 2022 at 2:26:09 PM UTC-6 Eric Fetzer wrote:
>
> Thanks for the response Mark.  I don't want to backgrade, so jenkins won't
>> run.  Can you give me a clue as to where the filepath is to java in
>> Jenkins.  Just upgrading didn't solve the problem and the vid is too slow
>> for me.  He seems to talk a lot about working in the tool.  I'm command
>> line RHEL 7.
>>
>>
> I believe that the command you want is described on the Red Hat Customer
> Portal <https://access.redhat.com/solutions/6232511>.
>
> # alternatives --config java
>
> Naturally, there are many different scenarios and complications where that
> command is the wrong choice.  For most people, the simplest choice is to
> switch the system path to Java and that is what alternatives will do.
>
> If that is not what you prefer, then you can configure a specific Java
> path through
>
> # systemctl edit jenkins
>
> The Jenkins documentation includes a guide to managing services with
> systemd
> <https://www.jenkins.io/doc/book/system-administration/systemd-services/>.
>
> Mark Waite
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Jenkins Users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/jenkinsci-users/00ogw3rHsCw/unsubscribe.
> To unsubscribe from this group and all its topics, 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/7724e4c7-62f1-4c2a-bb4e-d8f39e1f565bn%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/7724e4c7-62f1-4c2a-bb4e-d8f39e1f565bn%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/CAByBicafqc8oyUJZkzSWYjL_6QHzOh9x0E9x3XZSFQGSZwq0CA%40mail.gmail.com.

Re: Jenkins Won't start after latest ugrade

2022-09-14 Thread Eric Fetzer

Thanks for the response Mark.  I don't want to backgrade, so jenkins won't
run.  Can you give me a clue as to where the filepath is to java in
Jenkins.  Just upgrading didn't solve the problem and the vid is too slow
for me.  He seems to talk a lot about working in the tool.  I'm command
line RHEL 7.

Thanks,
Eric

On Wed, Sep 14, 2022 at 10:33 AM Mark Waite 
wrote:

> See
> https://www.jenkins.io/doc/administration/requirements/upgrade-java-guidelines/
> for instructions and a video describing the steps
>
> On Wednesday, September 14, 2022 at 10:06:19 AM UTC-6 slide wrote:
>
>> The latest weekly releases dropped support for Java 8, so you will need
>> to update to Java 11 at a minimum. You may need to look if there is a
>> separate yum package for Java 11 (e.g., if Java 8 is still the default in
>> your OS, then yum update java may not update to Java 11, it may just update
>> to the latest Java 8).
>>
>> On Wed, Sep 14, 2022 at 8:59 AM eric@gmail.com 
>> wrote:
>>
>>> Here's what I did:
>>>
>>> yum update jenkins
>>>
>>> Here's what's happening trying to get version info after upgrade.  Also
>>> won't start with systemctl start jenkins.
>>>
>>> [root@nd645bd001 ~]# /bin/jenkins -version
>>> Sep 14, 2022 10:56:24 AM executable.Main verifyJavaVersion
>>> SEVERE: Running with Java class version 52, which is older than the
>>> Minimum required version 55. See
>>> https://jenkins.io/redirect/java-support/
>>> java.lang.UnsupportedClassVersionError: 52.0
>>> at executable.Main.verifyJavaVersion(Main.java:145)
>>> at executable.Main.main(Main.java:109)
>>>
>>> Jenkins requires Java versions [17, 11] but you are running with Java
>>> 1.8 from /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.342.b07-1.el7_9.x86_64/jre
>>> java.lang.UnsupportedClassVersionError: 52.0
>>> at executable.Main.verifyJavaVersion(Main.java:145)
>>> at executable.Main.main(Main.java:109)
>>>
>>> Seems I need to upgrade java, but jenkins doesn't control java.  Please
>>> advise.  Should I just yum update java?
>>>
>>> Thanks,
>>> Eric
>>>
>>> --
>>> 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/63ddfcc2-b01e-4f44-8c6e-9ee40f923905n%40googlegroups.com
>>> <https://groups.google.com/d/msgid/jenkinsci-users/63ddfcc2-b01e-4f44-8c6e-9ee40f923905n%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>
>>
>> --
>> Website: http://earl-of-code.com
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Jenkins Users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/jenkinsci-users/00ogw3rHsCw/unsubscribe.
> To unsubscribe from this group and all its topics, 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/987308da-c629-4352-996b-a87d1b195066n%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/987308da-c629-4352-996b-a87d1b195066n%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/CAByBicYazaGR5t-e_V7Wc9MM7PTLw53Cp4sMLZRKyv5Gv_%2BDCg%40mail.gmail.com.

Jenkins Won't start after latest ugrade

2022-09-14 Thread eric....@gmail.com

Here's what I did:

yum update jenkins

Here's what's happening trying to get version info after upgrade.  Also 
won't start with systemctl start jenkins.

[root@nd645bd001 ~]# /bin/jenkins -version
Sep 14, 2022 10:56:24 AM executable.Main verifyJavaVersion
SEVERE: Running with Java class version 52, which is older than the Minimum 
required version 55. See https://jenkins.io/redirect/java-support/
java.lang.UnsupportedClassVersionError: 52.0
at executable.Main.verifyJavaVersion(Main.java:145)
at executable.Main.main(Main.java:109)

Jenkins requires Java versions [17, 11] but you are running with Java 1.8 
from /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.342.b07-1.el7_9.x86_64/jre
java.lang.UnsupportedClassVersionError: 52.0
at executable.Main.verifyJavaVersion(Main.java:145)
at executable.Main.main(Main.java:109)

Seems I need to upgrade java, but jenkins doesn't control java.  Please 
advise.  Should I just yum update java?

Thanks,
Eric

-- 
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/63ddfcc2-b01e-4f44-8c6e-9ee40f923905n%40googlegroups.com.

Re: Git Source Code Management Oddity

2022-05-23 Thread eric....@gmail.com

Also note that I AM using the "with credentials" from the plugin.

On Thursday, May 19, 2022 at 8:56:30 AM UTC-6 Mark Waite wrote:

> On Thursday, May 19, 2022 at 8:42:29 AM UTC-6 Eric Fetzer wrote:
>
>> OK, I've been having some major issues with Git source code management in 
>> Jenkins.  So I have several repositories I pull from to do builds.  I use 
>> my same credentials to pull from each.  If the pull succeeds, I push a tag 
>> at it.  I was noticing certain tags were failing saying it already existed 
>> even though it didn't exist.  Well, it didn't exist in THAT repository.  
>> But it did exist in one of the other repositories.  I tested by creating 
>> these tags in git command line and pushing them and it worked fine.  Anyone 
>> have a clue what could be happening here?  The jenkins task goes to my 
>> repository's url with my credentials selecting from the branch I tell it.  
>> It's set to clean before check out.  It does all of this fine.  It has a 
>> Git Publisher post build step to push my tag only if the checkout succeeds 
>> with the box checked to create new tag.  This works UNLESS that same tags 
>> exists in any of the projects I run this checkout task against.  Can anyone 
>> think of a reason for this odd behavior?  Thanks!!!
>
>
> I don't know if the git publisher in the git plugin is able to handle 
> checkout from multiple repositories.  It may not be that sophisticated.
>
> You may need to switch to use the "with credentials" feature that was 
> added in Google Summer of Code 2021 to allow you to perform the push of the 
> tag yourself rather than using the git publisher.  Docs on the "with 
> credentials" feature are available at 
> https://plugins.jenkins.io/git/#plugin-content-credential-binding 
> (Pipeline) and https://plugins.jenkins.io/git/#plugin-content-git-bindings 
> (freestyle) 
>
> 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/3978fa1d-ca63-44f3-9966-123ce7fc7ccbn%40googlegroups.com.

Re: Git Source Code Management Oddity

2022-05-23 Thread eric....@gmail.com

It handles checkout from multiple repositories and pushes tags to each.  
The only issue is that it seems to see tags in other repositories when it 
should only see the tags in the repository in question.  If the tag exists 
in ANY of the repositories I build for, this will be the error:

using credential e9cc840b-9e32-416c-94e7-7b23c1afbd5e 
 > git tag -l 2.3.0.1.1 
# timeout=10 ERROR: Step ‘Git Publisher’ failed: Tag 2.3.0.1.1 already 
exists and Create Tag is specified, so failing.

Any clue how I would trouble shoot such a thing?

Thanks,
Eric

On Thursday, May 19, 2022 at 8:56:30 AM UTC-6 Mark Waite wrote:

> On Thursday, May 19, 2022 at 8:42:29 AM UTC-6 Eric Fetzer wrote:
>
>> OK, I've been having some major issues with Git source code management in 
>> Jenkins.  So I have several repositories I pull from to do builds.  I use 
>> my same credentials to pull from each.  If the pull succeeds, I push a tag 
>> at it.  I was noticing certain tags were failing saying it already existed 
>> even though it didn't exist.  Well, it didn't exist in THAT repository.  
>> But it did exist in one of the other repositories.  I tested by creating 
>> these tags in git command line and pushing them and it worked fine.  Anyone 
>> have a clue what could be happening here?  The jenkins task goes to my 
>> repository's url with my credentials selecting from the branch I tell it.  
>> It's set to clean before check out.  It does all of this fine.  It has a 
>> Git Publisher post build step to push my tag only if the checkout succeeds 
>> with the box checked to create new tag.  This works UNLESS that same tags 
>> exists in any of the projects I run this checkout task against.  Can anyone 
>> think of a reason for this odd behavior?  Thanks!!!
>
>
> I don't know if the git publisher in the git plugin is able to handle 
> checkout from multiple repositories.  It may not be that sophisticated.
>
> You may need to switch to use the "with credentials" feature that was 
> added in Google Summer of Code 2021 to allow you to perform the push of the 
> tag yourself rather than using the git publisher.  Docs on the "with 
> credentials" feature are available at 
> https://plugins.jenkins.io/git/#plugin-content-credential-binding 
> (Pipeline) and https://plugins.jenkins.io/git/#plugin-content-git-bindings 
> (freestyle) 
>
> 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/7623d7a2-3618-4f9f-aeaf-65179b601cd5n%40googlegroups.com.

Git Source Code Management Oddity

2022-05-19 Thread eric....@gmail.com

OK, I've been having some major issues with Git source code management in 
Jenkins.  So I have several repositories I pull from to do builds.  I use 
my same credentials to pull from each.  If the pull succeeds, I push a tag 
at it.  I was noticing certain tags were failing saying it already existed 
even though it didn't exist.  Well, it didn't exist in THAT repository.  
But it did exist in one of the other repositories.  I tested by creating 
these tags in git command line and pushing them and it worked fine.  Anyone 
have a clue what could be happening here?  The jenkins task goes to my 
repository's url with my credentials selecting from the branch I tell it.  
It's set to clean before check out.  It does all of this fine.  It has a 
Git Publisher post build step to push my tag only if the checkout succeeds 
with the box checked to create new tag.  This works UNLESS that same tags 
exists in any of the projects I run this checkout task against.  Can anyone 
think of a reason for this odd behavior?  Thanks!!!

-- 
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/f0fcd019-bb4a-4126-96a1-8f912c6e7adan%40googlegroups.com.

Re: Unable to Launch Node

2022-04-21 Thread eric....@gmail.com

SSH Build Agent is 1.31.2.  Trilead-api is 1.0.13.  It only happens once 
the server gets reboot.  It'll be chugging along for a few weeks fine, then 
as soon as the server gets reboot after the latest OS patches have been 
applied, I'll have to delete the remoting.jar file again.  A bit 
frustrating.

On Wednesday, March 30, 2022 at 4:07:35 PM UTC-6 kuisat...@gmail.com wrote:

> I do not really have too much data to know what exactly is going on, which 
> version of the SSH build Agents and the trilead-api plugins are you using? 
> Are you using the latest versions? Do the issue happen only in that agent? 
> Which SSH server do you use and what version? Do you have any kind of 
> transfer limit on that agent? my theory is that the sftp read operation 
> fail because something cut it.
>
> El miércoles, 30 de marzo de 2022 a las 21:50:52 UTC+2, eric@gmail.com 
> escribió:
>
>> Just did it again on me.  Deleting the file again to fix it but would be 
>> great if I could fix it.  Any advise?
>>
>> On Friday, March 18, 2022 at 11:17:56 AM UTC-6 kuisat...@gmail.com wrote:
>>
>>> The SSH Build Agents plugin make an sftp or scp (if one fail try the 
>>> other) with the user configured in the Jenkins Agent to copy a file in the 
>>> "Remote root directory" folder configured in the Agent config, nothing 
>>> special, if the user configured in the Agent can make scp/sftp to copy a 
>>> file in that folder it should not fail. 
>>>
>>> The point where the Agent fails to copy the file is interesting, it 
>>> checks the value of the read bytes and fails if is <0 or >32768, I will 
>>> bet the value is `-1` and it is related to read the remoting.jar from the 
>>> Agent to check the md5, for some reason is returning an EOF
>>>
>>>
>>> https://github.com/jenkinsci/trilead-ssh2/blob/master/src/com/trilead/ssh2/SFTPv3Client.java#L1231
>>>
>>> https://github.com/jenkinsci/ssh-slaves-plugin/blob/main/src/main/java/hudson/plugins/sshslaves/SSHLauncher.java#L706
>>> El viernes, 18 de marzo de 2022 a las 16:10:56 UTC+1, eric@gmail.com 
>>> escribió:
>>>
>>>> Hmmm, I deleted the remoting.jar file and was able to restart Jenkins 
>>>> and the node came up.  Wonder if this is going to happen every we patch 
>>>> and 
>>>> boot this machine?
>>>>
>>>> On Friday, March 18, 2022 at 8:43:55 AM UTC-6 eric@gmail.com wrote:
>>>>
>>>>> Hi!  I have a node that is unable to launch.  On the log it shows:
>>>>>
>>>>> [03/18/22 09:39:01] [SSH] Copying latest remoting.jar... 
>>>>> java.io.IOException: Could not copy remoting.jar into 
>>>>> '/home/myuser/checkout' on agent at 
>>>>> hudson.plugins.sshslaves.SSHLauncher.copyAgentJar(SSHLauncher.java:715) 
>>>>> at 
>>>>> hudson.plugins.sshslaves.SSHLauncher.access$300(SSHLauncher.java:112) at 
>>>>> hudson.plugins.sshslaves.SSHLauncher$1.call(SSHLauncher.java:455) at 
>>>>> hudson.plugins.sshslaves.SSHLauncher$1.call(SSHLauncher.java:422) at 
>>>>> java.util.concurrent.FutureTask.run(FutureTask.java:266) at 
>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>>>>>  
>>>>> at 
>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>>>>>  
>>>>> at java.lang.Thread.run(Thread.java:750) Caused by: 
>>>>> java.lang.IllegalArgumentException: invalid len argument at 
>>>>> com.trilead.ssh2.SFTPv3Client.read(SFTPv3Client.java:1232) at 
>>>>> com.trilead.ssh2.jenkins.SFTPClient$SFTPInputStream.read(SFTPClient.java:172)
>>>>>  
>>>>> at 
>>>>> com.google.common.io.ByteStreams.toByteArrayInternal(ByteStreams.java:184)
>>>>>  
>>>>> at com.google.common.io.ByteStreams.toByteArray(ByteStreams.java:224) at 
>>>>> hudson.plugins.sshslaves.SSHLauncher.readInputStreamIntoByteArrayAndClose(SSHLauncher.java:773)
>>>>>  
>>>>> at 
>>>>> hudson.plugins.sshslaves.SSHLauncher.copyAgentJar(SSHLauncher.java:684) 
>>>>> ... 7 more
>>>>>
>>>>> I've set my perms on the checkout dir to 777, so it's not that it 
>>>>> doesn't have permission to write over the current remoting.jar that lives 
>>>>> there. Anyone have any clues or further trouble shooting advise? 
>>>>> Running Jenkins 2.232.1 on RHEL 7.9.
>>>>>
>>>>> Thanks - Eric 
>>>>>
>>>>

-- 
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/47eafb75-de8e-4b98-86fb-fffbf058fff0n%40googlegroups.com.

Re: How to know when plugins were installed

2022-04-15 Thread eric....@gmail.com

If you're in Unix, Go to $JENKINS_HOME/plugins:

ls -ltr *.hpi *.jpi 

The most recently installed will be at the bottom and you'll see the date.

On Friday, April 15, 2022 at 10:59:10 AM UTC-6 jf.la...@gmail.com wrote:

> Hello,
>
> The Jenkins Plugin Manager gives us a long list of about 100 installed 
> plugins on our system.
> Yet I'm sure that we've not installed more than a dozen beyond the default 
> ones suggested in the beginning.
> Most of the plugins listed are probably just dependencies of the initial 
> ones, or of the ones we explicitly installed.
>
> To prepare a disaster recovery plan, I need to list exactly what plugins 
> we installed.
> We've recorded some of then, but unfortunately not all. How to find the 
> others?
>
> Is there a way to list just the plugins requested, NOT the dependencies 
> installed automatically?
>
> Is there a way to list the plugins installations by date?
> (This would allow us to recognize which one we installed in each burst of 
> installations!)
>
> Jean-François
>

-- 
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/a81a77f2-3948-46ca-89f8-cb01c2791a75n%40googlegroups.com.

Re: Jenkins Scripting Console

2022-04-15 Thread eric....@gmail.com

Well my bad, it works fine.  I was thinking the plugins were disabled if 
they were subdued in color.  No, that just means they can't be disabled.  I 
didn't have any disabled.  I disabled subversion and it shows Disabled.  
Maybe this will help someone down the road, though, who wants to do the 
same.

On Friday, April 15, 2022 at 10:19:10 AM UTC-6 eric@gmail.com wrote:

> Hi all!  I'm trying to display a few simple things from the console for 
> our security team.  I'm getting the correct answers for all except whether 
> the plugin is enabled or not.  They are all returning enabled for me.  Can 
> someone tell me what I'm doing wrong in my groovy code?
>
> Jenkins.instance.pluginManager.plugins.each{
>   plugin -> 
>   boolean active = ( plugin.isActive() )
>   String enabled = ( active == true ? "Enabled" : "Disabled"  )
>   println ("${plugin.getDisplayName()} (${plugin.getShortName()}): 
> ${plugin.getVersion()} ${enabled}")
> }
>
> Thanks,
> Eric
>

-- 
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/4ede952c-7702-405c-b97f-c4db34cb24f4n%40googlegroups.com.

Jenkins Scripting Console

2022-04-15 Thread eric....@gmail.com

Hi all!  I'm trying to display a few simple things from the console for our 
security team.  I'm getting the correct answers for all except whether the 
plugin is enabled or not.  They are all returning enabled for me.  Can 
someone tell me what I'm doing wrong in my groovy code?

Jenkins.instance.pluginManager.plugins.each{
  plugin -> 
  boolean active = ( plugin.isActive() )
  String enabled = ( active == true ? "Enabled" : "Disabled"  )
  println ("${plugin.getDisplayName()} (${plugin.getShortName()}): 
${plugin.getVersion()} ${enabled}")
}

Thanks,
Eric

-- 
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/a60f5a9d-138f-4a43-b508-fd81a096da34n%40googlegroups.com.

Re: Unable to Launch Node

2022-03-30 Thread eric....@gmail.com

Just did it again on me.  Deleting the file again to fix it but would be 
great if I could fix it.  Any advise?

On Friday, March 18, 2022 at 11:17:56 AM UTC-6 kuisat...@gmail.com wrote:

> The SSH Build Agents plugin make an sftp or scp (if one fail try the 
> other) with the user configured in the Jenkins Agent to copy a file in the 
> "Remote root directory" folder configured in the Agent config, nothing 
> special, if the user configured in the Agent can make scp/sftp to copy a 
> file in that folder it should not fail. 
>
> The point where the Agent fails to copy the file is interesting, it checks 
> the value of the read bytes and fails if is <0 or >32768, I will bet the 
> value is `-1` and it is related to read the remoting.jar from the Agent to 
> check the md5, for some reason is returning an EOF
>
>
> https://github.com/jenkinsci/trilead-ssh2/blob/master/src/com/trilead/ssh2/SFTPv3Client.java#L1231
>
> https://github.com/jenkinsci/ssh-slaves-plugin/blob/main/src/main/java/hudson/plugins/sshslaves/SSHLauncher.java#L706
> El viernes, 18 de marzo de 2022 a las 16:10:56 UTC+1, eric@gmail.com 
> escribió:
>
>> Hmmm, I deleted the remoting.jar file and was able to restart Jenkins and 
>> the node came up.  Wonder if this is going to happen every we patch and 
>> boot this machine?
>>
>> On Friday, March 18, 2022 at 8:43:55 AM UTC-6 eric@gmail.com wrote:
>>
>>> Hi!  I have a node that is unable to launch.  On the log it shows:
>>>
>>> [03/18/22 09:39:01] [SSH] Copying latest remoting.jar... 
>>> java.io.IOException: Could not copy remoting.jar into 
>>> '/home/myuser/checkout' on agent at 
>>> hudson.plugins.sshslaves.SSHLauncher.copyAgentJar(SSHLauncher.java:715) at 
>>> hudson.plugins.sshslaves.SSHLauncher.access$300(SSHLauncher.java:112) at 
>>> hudson.plugins.sshslaves.SSHLauncher$1.call(SSHLauncher.java:455) at 
>>> hudson.plugins.sshslaves.SSHLauncher$1.call(SSHLauncher.java:422) at 
>>> java.util.concurrent.FutureTask.run(FutureTask.java:266) at 
>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>>>  
>>> at 
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>>>  
>>> at java.lang.Thread.run(Thread.java:750) Caused by: 
>>> java.lang.IllegalArgumentException: invalid len argument at 
>>> com.trilead.ssh2.SFTPv3Client.read(SFTPv3Client.java:1232) at 
>>> com.trilead.ssh2.jenkins.SFTPClient$SFTPInputStream.read(SFTPClient.java:172)
>>>  
>>> at 
>>> com.google.common.io.ByteStreams.toByteArrayInternal(ByteStreams.java:184) 
>>> at com.google.common.io.ByteStreams.toByteArray(ByteStreams.java:224) at 
>>> hudson.plugins.sshslaves.SSHLauncher.readInputStreamIntoByteArrayAndClose(SSHLauncher.java:773)
>>>  
>>> at hudson.plugins.sshslaves.SSHLauncher.copyAgentJar(SSHLauncher.java:684) 
>>> ... 7 more
>>>
>>> I've set my perms on the checkout dir to 777, so it's not that it 
>>> doesn't have permission to write over the current remoting.jar that lives 
>>> there. Anyone have any clues or further trouble shooting advise? 
>>> Running Jenkins 2.232.1 on RHEL 7.9.
>>>
>>> Thanks - Eric 
>>>
>>

-- 
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/b182927d-e91d-4353-834a-6ed573288a1bn%40googlegroups.com.

Re: Unable to Launch Node

2022-03-18 Thread eric....@gmail.com

Hmmm, I deleted the remoting.jar file and was able to restart Jenkins and 
the node came up.  Wonder if this is going to happen every we patch and 
boot this machine?

On Friday, March 18, 2022 at 8:43:55 AM UTC-6 eric@gmail.com wrote:

> Hi!  I have a node that is unable to launch.  On the log it shows:
>
> [03/18/22 09:39:01] [SSH] Copying latest remoting.jar... 
> java.io.IOException: Could not copy remoting.jar into 
> '/home/myuser/checkout' on agent at 
> hudson.plugins.sshslaves.SSHLauncher.copyAgentJar(SSHLauncher.java:715) at 
> hudson.plugins.sshslaves.SSHLauncher.access$300(SSHLauncher.java:112) at 
> hudson.plugins.sshslaves.SSHLauncher$1.call(SSHLauncher.java:455) at 
> hudson.plugins.sshslaves.SSHLauncher$1.call(SSHLauncher.java:422) at 
> java.util.concurrent.FutureTask.run(FutureTask.java:266) at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>  
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>  
> at java.lang.Thread.run(Thread.java:750) Caused by: 
> java.lang.IllegalArgumentException: invalid len argument at 
> com.trilead.ssh2.SFTPv3Client.read(SFTPv3Client.java:1232) at 
> com.trilead.ssh2.jenkins.SFTPClient$SFTPInputStream.read(SFTPClient.java:172) 
> at 
> com.google.common.io.ByteStreams.toByteArrayInternal(ByteStreams.java:184) 
> at com.google.common.io.ByteStreams.toByteArray(ByteStreams.java:224) at 
> hudson.plugins.sshslaves.SSHLauncher.readInputStreamIntoByteArrayAndClose(SSHLauncher.java:773)
>  
> at hudson.plugins.sshslaves.SSHLauncher.copyAgentJar(SSHLauncher.java:684) 
> ... 7 more
>
> I've set my perms on the checkout dir to 777, so it's not that it doesn't 
> have permission to write over the current remoting.jar that lives there. 
> Anyone have any clues or further trouble shooting advise? 
> Running Jenkins 2.232.1 on RHEL 7.9.
>
> Thanks - Eric 
>

-- 
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/134d8093-61e0-45af-9ccd-1d0c855cd327n%40googlegroups.com.

Unable to Launch Node

2022-03-18 Thread eric....@gmail.com

Hi!  I have a node that is unable to launch.  On the log it shows:

[03/18/22 09:39:01] [SSH] Copying latest remoting.jar... 
java.io.IOException: Could not copy remoting.jar into 
'/home/myuser/checkout' on agent at 
hudson.plugins.sshslaves.SSHLauncher.copyAgentJar(SSHLauncher.java:715) at 
hudson.plugins.sshslaves.SSHLauncher.access$300(SSHLauncher.java:112) at 
hudson.plugins.sshslaves.SSHLauncher$1.call(SSHLauncher.java:455) at 
hudson.plugins.sshslaves.SSHLauncher$1.call(SSHLauncher.java:422) at 
java.util.concurrent.FutureTask.run(FutureTask.java:266) at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 
at java.lang.Thread.run(Thread.java:750) Caused by: 
java.lang.IllegalArgumentException: invalid len argument at 
com.trilead.ssh2.SFTPv3Client.read(SFTPv3Client.java:1232) at 
com.trilead.ssh2.jenkins.SFTPClient$SFTPInputStream.read(SFTPClient.java:172) 
at 
com.google.common.io.ByteStreams.toByteArrayInternal(ByteStreams.java:184) 
at com.google.common.io.ByteStreams.toByteArray(ByteStreams.java:224) at 
hudson.plugins.sshslaves.SSHLauncher.readInputStreamIntoByteArrayAndClose(SSHLauncher.java:773)
 
at hudson.plugins.sshslaves.SSHLauncher.copyAgentJar(SSHLauncher.java:684) 
... 7 more

I've set my perms on the checkout dir to 777, so it's not that it doesn't 
have permission to write over the current remoting.jar that lives there. 
Anyone have any clues or further trouble shooting advise? 
Running Jenkins 2.232.1 on RHEL 7.9.

Thanks - Eric 

-- 
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/61a1558f-20c7-4dad-b45e-783b375163efn%40googlegroups.com.

Re: Log4j CVE-2021-44228

2021-12-17 Thread eric....@gmail.com

OK, so this isn't going so hot.  There is no .m2/settings.xml file.  There 
are settings.xml for each of the Maven versions under 
~/tools/hudson.tasks.Maven_MavenInstallation/Maven-X.X/conf.  This has the 
"localRepository" node but it's commented out.  Should I set the value 
"/var/lib/jenkins/.m2/repositories/${env.JOB_NAME}/repository" 
in there for each version? Alternative would be to create a settings.xml 
file in the .m2 directory. Sounds like it goes to that one first regardless 
of version... The concept seems simplest. Chron job or just clear the repo 
at the end of the build?

Thanks,
Eric

On Friday, December 17, 2021 at 4:12:50 AM UTC-7 bma...@gmail.com wrote:

> Yeah you can definitely wipe out this whole tree.
>
> I wrote an eternity ago about this:
>
>  
> https://batmat.net/2009/10/09/hudson-how-to-set-a-private-maven-repository-by-job-and-easily-be-able-to-delete-them/
>
> Some of it is a bit old but the principles remain true today: you _should_ 
> even do it on a regular basis. Ideally after and before each job (the 
> modern way to do this kinda automatically is to use things like containers 
> that will by definition start fresh [if some shared maven repository isn't 
> mounted, don't do this]).
>
> Cheers
>
> Le jeu. 16 déc. 2021 à 23:01, eric@gmail.com  a 
> écrit :
>
>> Thanks a ton, great cud to chew on!  Now I think I know the culprit and 
>> it's been deprecated.  Guessing I can just delete that log4j directory and 
>> be done with it.
>>
>> On Thursday, December 16, 2021 at 1:12:28 PM UTC-7 nhoj.p...@gmail.com 
>> wrote:
>>
>>> I would exclude /opt/jenkins/.m2/repository from any scans, as already 
>>> mentioned that is the local maven cache.
>>> Also if you don't maintain that, it will grow and grow.
>>> Personally I update build jobs so they each have their own maven cache 
>>> using -Dmaven.repo.local=mvn-repo then delete that after your job 
>>> completes. You might need to tweak some of your process if they depending 
>>> upon one job installing and another job consuming. But the problem with 
>>> that is if you do builds pre branch they could conflict if using the same 
>>> version number.
>>>
>>> Or, delete /opt/jenkins/.m2/repository/org/apache/logging/log4j/ and 
>>> rebuild all your projects. As maven will download it again if it still 
>>> needs it. If a pre 2.15.0/2.16.0 version appears, then it means one of your 
>>> jobs still has an older version as a dependency.
>>>
>>>
>>>
>>> On Thu, 16 Dec 2021 at 18:59, Baptiste Mathus  wrote:
>>>
>>>> That's unrelated to Jenkins per se. This directory is the maven cache, 
>>>> also called 'local repository'.
>>>>
>>>> My theory is that you have a job or more that uses maven with default 
>>>> values. I suspect you even run these on the controller itself...
>>>>
>>>> Some of your job(s) build(s) a software of yours that depends on a 
>>>> vulnerable version of log4j.
>>>>
>>>>
>>>>
>>>>
>>>> Le jeu. 16 déc. 2021 à 19:15, eric@gmail.com  
>>>> a écrit :
>>>>
>>>>> Hi all.  Getting popped by our security team for an old version of 
>>>>> log4j.  I've checked and we don't have any of the plugins installed 
>>>>> identified by the following issue:
>>>>>
>>>>> https://issues.jenkins.io/browse/JENKINS-67353
>>>>>
>>>>> Here's the info from the scan:
>>>>>
>>>>> Plugin Output: 
>>>>>   Path  : 
>>>>> /opt/jenkins/.m2/repository/org/apache/logging/log4j/log4j-core/2.14.1/log4j-core-2.14.1.pom.sha1
>>>>>   Installed version : 2.14.1
>>>>>   Fixed version : 2.15.0
>>>>>
>>>>> Anyone have a clue on how I go about upgrading this?
>>>>>
>>>>> Thanks,
>>>>> Eric
>>>>>
>>>>> -- 
>>>>> 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/0e0194bf-3090-43e1-92d2-be3789365ae5n%40googlegroups.com
>>>>>  
>>>>> <https://groups.google.com/d/msgid/jenki

Re: Log4j CVE-2021-44228

2021-12-17 Thread eric....@gmail.com

Thanks, deleted it for short term solution and looking into the "Even 
Better" solution at your link.  Much appreciated!

On Friday, December 17, 2021 at 4:12:50 AM UTC-7 bma...@gmail.com wrote:

> Yeah you can definitely wipe out this whole tree.
>
> I wrote an eternity ago about this:
>
>  
> https://batmat.net/2009/10/09/hudson-how-to-set-a-private-maven-repository-by-job-and-easily-be-able-to-delete-them/
>
> Some of it is a bit old but the principles remain true today: you _should_ 
> even do it on a regular basis. Ideally after and before each job (the 
> modern way to do this kinda automatically is to use things like containers 
> that will by definition start fresh [if some shared maven repository isn't 
> mounted, don't do this]).
>
> Cheers
>
> Le jeu. 16 déc. 2021 à 23:01, eric@gmail.com  a 
> écrit :
>
>> Thanks a ton, great cud to chew on!  Now I think I know the culprit and 
>> it's been deprecated.  Guessing I can just delete that log4j directory and 
>> be done with it.
>>
>> On Thursday, December 16, 2021 at 1:12:28 PM UTC-7 nhoj.p...@gmail.com 
>> wrote:
>>
>>> I would exclude /opt/jenkins/.m2/repository from any scans, as already 
>>> mentioned that is the local maven cache.
>>> Also if you don't maintain that, it will grow and grow.
>>> Personally I update build jobs so they each have their own maven cache 
>>> using -Dmaven.repo.local=mvn-repo then delete that after your job 
>>> completes. You might need to tweak some of your process if they depending 
>>> upon one job installing and another job consuming. But the problem with 
>>> that is if you do builds pre branch they could conflict if using the same 
>>> version number.
>>>
>>> Or, delete /opt/jenkins/.m2/repository/org/apache/logging/log4j/ and 
>>> rebuild all your projects. As maven will download it again if it still 
>>> needs it. If a pre 2.15.0/2.16.0 version appears, then it means one of your 
>>> jobs still has an older version as a dependency.
>>>
>>>
>>>
>>> On Thu, 16 Dec 2021 at 18:59, Baptiste Mathus  wrote:
>>>
>>>> That's unrelated to Jenkins per se. This directory is the maven cache, 
>>>> also called 'local repository'.
>>>>
>>>> My theory is that you have a job or more that uses maven with default 
>>>> values. I suspect you even run these on the controller itself...
>>>>
>>>> Some of your job(s) build(s) a software of yours that depends on a 
>>>> vulnerable version of log4j.
>>>>
>>>>
>>>>
>>>>
>>>> Le jeu. 16 déc. 2021 à 19:15, eric@gmail.com  
>>>> a écrit :
>>>>
>>>>> Hi all.  Getting popped by our security team for an old version of 
>>>>> log4j.  I've checked and we don't have any of the plugins installed 
>>>>> identified by the following issue:
>>>>>
>>>>> https://issues.jenkins.io/browse/JENKINS-67353
>>>>>
>>>>> Here's the info from the scan:
>>>>>
>>>>> Plugin Output: 
>>>>>   Path  : 
>>>>> /opt/jenkins/.m2/repository/org/apache/logging/log4j/log4j-core/2.14.1/log4j-core-2.14.1.pom.sha1
>>>>>   Installed version : 2.14.1
>>>>>   Fixed version : 2.15.0
>>>>>
>>>>> Anyone have a clue on how I go about upgrading this?
>>>>>
>>>>> Thanks,
>>>>> Eric
>>>>>
>>>>> -- 
>>>>> 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/0e0194bf-3090-43e1-92d2-be3789365ae5n%40googlegroups.com
>>>>>  
>>>>> <https://groups.google.com/d/msgid/jenkinsci-users/0e0194bf-3090-43e1-92d2-be3789365ae5n%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-use...@googlegroups.com.
>>>>
>>> To vie

Re: Log4j CVE-2021-44228

2021-12-16 Thread eric....@gmail.com

Thanks a ton, great cud to chew on!  Now I think I know the culprit and 
it's been deprecated.  Guessing I can just delete that log4j directory and 
be done with it.

On Thursday, December 16, 2021 at 1:12:28 PM UTC-7 nhoj.p...@gmail.com 
wrote:

> I would exclude /opt/jenkins/.m2/repository from any scans, as already 
> mentioned that is the local maven cache.
> Also if you don't maintain that, it will grow and grow.
> Personally I update build jobs so they each have their own maven cache 
> using -Dmaven.repo.local=mvn-repo then delete that after your job 
> completes. You might need to tweak some of your process if they depending 
> upon one job installing and another job consuming. But the problem with 
> that is if you do builds pre branch they could conflict if using the same 
> version number.
>
> Or, delete /opt/jenkins/.m2/repository/org/apache/logging/log4j/ and 
> rebuild all your projects. As maven will download it again if it still 
> needs it. If a pre 2.15.0/2.16.0 version appears, then it means one of your 
> jobs still has an older version as a dependency.
>
>
>
> On Thu, 16 Dec 2021 at 18:59, Baptiste Mathus  wrote:
>
>> That's unrelated to Jenkins per se. This directory is the maven cache, 
>> also called 'local repository'.
>>
>> My theory is that you have a job or more that uses maven with default 
>> values. I suspect you even run these on the controller itself...
>>
>> Some of your job(s) build(s) a software of yours that depends on a 
>> vulnerable version of log4j.
>>
>>
>>
>>
>> Le jeu. 16 déc. 2021 à 19:15, eric@gmail.com  a 
>> écrit :
>>
>>> Hi all.  Getting popped by our security team for an old version of 
>>> log4j.  I've checked and we don't have any of the plugins installed 
>>> identified by the following issue:
>>>
>>> https://issues.jenkins.io/browse/JENKINS-67353
>>>
>>> Here's the info from the scan:
>>>
>>> Plugin Output: 
>>>   Path  : 
>>> /opt/jenkins/.m2/repository/org/apache/logging/log4j/log4j-core/2.14.1/log4j-core-2.14.1.pom.sha1
>>>   Installed version : 2.14.1
>>>   Fixed version : 2.15.0
>>>
>>> Anyone have a clue on how I go about upgrading this?
>>>
>>> Thanks,
>>> Eric
>>>
>>> -- 
>>> 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/0e0194bf-3090-43e1-92d2-be3789365ae5n%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/jenkinsci-users/0e0194bf-3090-43e1-92d2-be3789365ae5n%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-use...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-users/CANWgJS7PpCx6a9J__vv7G-oYC0ssUbZbW%2Ba8_bWsS0_Na-6dyw%40mail.gmail.com
>>  
>> <https://groups.google.com/d/msgid/jenkinsci-users/CANWgJS7PpCx6a9J__vv7G-oYC0ssUbZbW%2Ba8_bWsS0_Na-6dyw%40mail.gmail.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/6147a143-256b-4f71-9b42-081744fc6bb8n%40googlegroups.com.

Re: Log4j CVE-2021-44228

2021-12-16 Thread eric....@gmail.com

Hmmm, found this page:

https://www.jenkins.io/blog/2021/12/10/log4j2-rce-CVE-2021-44228/

So I ran the script in the script console and got the error indicating that 
log4j is not included in any installed and enabled plugin.  Anyone have a 
clue?

Thanks,
Eric

On Thursday, December 16, 2021 at 11:15:25 AM UTC-7 eric@gmail.com 
wrote:

> Hi all.  Getting popped by our security team for an old version of log4j.  
> I've checked and we don't have any of the plugins installed identified by 
> the following issue:
>
> https://issues.jenkins.io/browse/JENKINS-67353
>
> Here's the info from the scan:
>
> Plugin Output: 
>   Path  : 
> /opt/jenkins/.m2/repository/org/apache/logging/log4j/log4j-core/2.14.1/log4j-core-2.14.1.pom.sha1
>   Installed version : 2.14.1
>   Fixed version : 2.15.0
>
> Anyone have a clue on how I go about upgrading this?
>
> Thanks,
> Eric
>

-- 
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/c7c21022-d446-451f-939c-adb4eb4eebden%40googlegroups.com.

Log4j CVE-2021-44228

2021-12-16 Thread eric....@gmail.com

Hi all.  Getting popped by our security team for an old version of log4j.  
I've checked and we don't have any of the plugins installed identified by 
the following issue:

https://issues.jenkins.io/browse/JENKINS-67353

Here's the info from the scan:

Plugin Output: 
  Path  : 
/opt/jenkins/.m2/repository/org/apache/logging/log4j/log4j-core/2.14.1/log4j-core-2.14.1.pom.sha1
  Installed version : 2.14.1
  Fixed version : 2.15.0

Anyone have a clue on how I go about upgrading this?

Thanks,
Eric

-- 
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/0e0194bf-3090-43e1-92d2-be3789365ae5n%40googlegroups.com.

GitHub Plugin Checkout Specific Folder

2021-06-25 Thread eric....@gmail.com

Hi!  In a nutshell, I'm cloning for builds, not doing any polling or such.  
I clear my workspace then check out my repository.  I'd like to do the same 
but just grab a specific folder.  I'm guessing this would be done in my 
branch specifier.  As it stands now, for this particular checkout 
operation, it's always going to be the master branch, so that's all I'm 
passing for this attribute is master.  Is there a way to change that to say 
master/FolderName to just get that specific folder?  If so, what's the 
format to do so?  Thanks!

-- 
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/ed896779-670d-46d1-8fb1-a2ddbf6f2ae3n%40googlegroups.com.

Is it possible to update a variable in a dynamically created stage?

2021-06-21 Thread 'Eric Boehm' via Jenkins Users

I am having a problem updating a variable based on the result of a shell
script when I create stages dynamically. I think that this is because the
dynamically created stage is a closure and its view of the variable is as
of the time of the closure.

Is there a way to solve this problem?

Here's the sample Jenkinsfile if the stages are run sequentially and not
created dynamically.
It behaves as expected.

node {
label 'master'
def needsBuild = []
myexit = 0
myscript = """
echo "Desired exit $myexit"
exit $myexit
"""
stage("Status $myexit") {
status = sh script: myscript, returnStatus: true
if (status) {
echo "Changes needed"
needsBuild.add(myexit)
}
}
myexit = 1
myscript = """
echo "Desired exit $myexit"
exit $myexit
"""
stage("Status $myexit") {
status = sh script: myscript, returnStatus: true
if (status) {
echo "Changes needed"
needsBuild.add(myexit)
}
}
}

This Jenkinsfile has a traceback when it tries 'needsBuild.add(myexit)

  def createStage(mystatus) {
def myexit = mystatus
def myscript = """
echo "Desired exit $myexit"
exit $myexit
"""
return {
stage("job $myexit") {
status = sh script: myscript, returnStatus: true
if (status) {
echo "Changes needed"
needsBuild.add(myexit)
}
}
}
}
node {
label 'master'
def needsBuild = []
def stages = [:]
for (index in [0, 1]) {
stages["Exit value $index"] = createStage(index)
}
parallel stages
}


Here's the traceback:


+ exit 1[Pipeline] echo
<https://bca-bld-013.lvn.broadcom.net:9443/view/all/job/dynamic_stage/9/console#>Changes
needed[Pipeline] }[Pipeline] // stage[Pipeline] }[Pipeline] //
node[Pipeline] End of Pipelinegroovy.lang.MissingPropertyException: No
such property: needsBuild for class: groovy.lang.Binding
at groovy.lang.Binding.getVariable(Binding.java:63)
    at 
org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onGetProperty(SandboxInterceptor.java:271)


Any suggestions or guidance on what I am missing would be appreciated.

--
Eric Boehm

-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.

-- 
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/CACL45fj-JkhhiU87WEhHnaEgcBm2Ca0%3Dn4uq8JrGhA5PnKe-Yg%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Jenkins 2.277.1 Issue?

2021-04-23 Thread eric....@gmail.com

Thanks xJom, finally put in the time, figured out the necessary upgrades 
and did it.  Worked like a charm!!!

On Tuesday, April 6, 2021 at 6:54:31 AM UTC-6 xJom wrote:

> So, the https://github.com/jenkinsci/plugin-installation-manager-tool 
> really saved my day. I went through the plugins directory and checked 
> against the compatibility list, and upgraded all of the plugins with the 
> Plugin Installation Manager Tool. And finally we are up-and-running again!
>
> fredag 2 april 2021 kl. 14:37:53 UTC+2 skrev xJom:
>
>> I have the same problem on one of my instances, but I also have the 
>> problem that I cannot go back to previous version, because it destroys the 
>> other instances. I think there is a compatibility issue for plugins, and if 
>> you could go back, then update all your plugins according to the 
>> compatility matrix here. 
>> https://github.com/jenkinsci/jep/blob/master/jep/227/compatibility.adoc
>> For me, I think I need to try to upgrade the plugins manually...
>>
>> måndag 22 mars 2021 kl. 16:15:15 UTC+1 skrev eric@gmail.com:
>>
>>> Hi!  Last week we took 2.277.1 when patching.  I didn't see any issues 
>>> until this morning when I tried to log on and got 403 No valid crumb was 
>>> included in the request.  I restarted the server a few times trying to fix 
>>> it but never could get logged in.  I did some research and found a thread 
>>> telling me to make a global security setting change to proxy compatibility 
>>> (even though I'm not proxied), but couldn't get to global security to try 
>>> that.  So I backed it out to 2.263.4, where we were before.  It's working 
>>> again, but I'm guessing the same thing will happen next time we apply 
>>> patches.  Is there a change with 277 that will make me have to change some 
>>> setting or another?  Thanks!
>>
>>

-- 
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/4f26ed8c-a839-4ca4-8732-04b0157bf2a0n%40googlegroups.com.

Re: Git Plugin Checkout From Branch With Tag

2021-04-16 Thread Eric Fetzer

That's excellent news Dirk!  That means the process I want to follow will
work perfectly.  Since I tag as I checkout from a branch, my tag will apply
to that entire branch at that point in time.  That way, when I later check
out by tag, I will have that branch at that point in time.  In the past,
we've used the same labels on different branches, though.  But since github
tags aren't a respecter of branches, I'll have to just use a different
naming schema in dev branches vs. the prod branch.  So for dev, I might
have 1.0.0.1.1, 1.0.0.1.2, 1.0.0.1.3, and then when that gets merged to the
master, I'd build 1.0.0.1.  Does this strategy make sense?  Thanks!  Eric

On Fri, Apr 16, 2021 at 12:10 AM 'Dirk Heinrichs' via Jenkins Users <
jenkinsci-users@googlegroups.com> wrote:

> Am Donnerstag, den 15.04.2021, 08:47 -0600 schrieb Eric Fetzer:
>
> So here's what blows my mind about a tag.  If I go to the tag in GitHub
> Enterprise, it has a .zip and .tar.gz associated with it.  If I unpack that
> file, it has the entire contents of the repository in it.  That seems like
> a view label to me.  But yet all of the documentation talks about the tag
> as a change set.  I don't get it!
>
>
> GitHub, GitLab, , and all those sites are *NOT* Git.
> They are collaboration platforms that *use* Git for source code
> management and offer some additional tooling around it. One such offer is
> to allow the user to download a ZIP or Tar archive of a particular state of
> a repository (i.o.w.: a snapshot, w/o the history), which can be identified
> by a Git tag, but also by a changeset identifier (for example:
> https://github.com/saltstack/salt/archive/d240e450f449f16ef176a9cb563b9f0447687a6e.zip).
> These are usually created on the fly when someone requests the download.
>
> Speaking of Git tags (or branches): They're all the same, a reference to a
> specific changeset. The only difference is that branch refs are a moving
> target (they always reference the latest changeset of a particular branch
> of development), while tags are not.
>
> HTH...
>
> Dirk
>
> --
>
> *Dirk Heinrichs*
> Senior Systems Engineer, Delivery Pipeline
> OpenText ™ Discovery | Recommind
> *Phone*: +49 2226 15966 18
> *Email*: dhein...@opentext.com
> *Website*: www.recommind.de
> Recommind GmbH, Von-Liebig-Straße 1, 53359 Rheinbach
> Vertretungsberechtigte Geschäftsführer Gordon Davies, Madhu Ranganathan,
> Christian Waida, Registergericht Amtsgericht Bonn, Registernummer HRB 10646
> This e-mail may contain confidential and/or privileged information. If you
> are not the intended recipient (or have received this e-mail in error)
> please notify the sender immediately and destroy this e-mail. Any
> unauthorized copying, disclosure or distribution of the material in this
> e-mail is strictly forbidden
> Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
> Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
> irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
> vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte
> Weitergabe dieser Mail sind nicht gestattet.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Jenkins Users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/jenkinsci-users/UGyBIx3pX9s/unsubscribe.
> To unsubscribe from this group and all its topics, 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/eed9236d95231f0893d0e6a90bc399e28ade9564.camel%40opentext.com
> <https://groups.google.com/d/msgid/jenkinsci-users/eed9236d95231f0893d0e6a90bc399e28ade9564.camel%40opentext.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/CAByBicaGN2J3H0z-a5ckFBACGr3L_CSQcb6cV1iXu9qBd11EvQ%40mail.gmail.com.

Re: Git Plugin Checkout From Branch With Tag

Thanks Mark!

On Thu, Apr 15, 2021 at 9:22 AM Mark Waite 
wrote:

> Not taken as whining, just that any attempt I made to explain would be
> riddled with inadequacies and misuse of terminology.  The definitive
> documentation has more reviewers and more people that try to assure it is
> correct, complete, and consistent.
>
> On Thu, Apr 15, 2021 at 9:19 AM Eric Fetzer  wrote:
>
>> Thanks Mark!  I'll quit whining and displaying my total git inadequacy,
>> lol...
>>
>> On Thu, Apr 15, 2021 at 9:14 AM Mark Waite 
>> wrote:
>>
>>>
>>>
>>> On Thu, Apr 15, 2021 at 7:38 AM Eric Fetzer 
>>> wrote:
>>>
>>>> So when you turn a tag into a release, does it then act more like a
>>>> label, or is it still just a set of changed files?
>>>>
>>>>
>>> Refer to https://git-scm.com/book/en/v2/Git-Basics-Tagging for more
>>> details on the meaning and use of git tags.
>>>
>>>
>>>
>>>> On Wed, Apr 14, 2021 at 12:48 PM Mark Waite 
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, Apr 14, 2021 at 12:16 PM eric.fetzer 
>>>>> wrote:
>>>>>
>>>>>> Thamks Mark!  So how would I go about checking out a branch based on
>>>>>> a point in time (a label in most systems)?  Is there a way to snap a 
>>>>>> label
>>>>>> and then check out based on that label or are we resigned to only deal in
>>>>>> tip revisions?
>>>>>>
>>>>>>
>>>>> You can checkout a point in time by checking out a specific SHA-1 hash
>>>>> that is the most recent commit before that point in time.  See
>>>>> https://stackoverflow.com/questions/6990484/how-to-checkout-in-git-by-date
>>>>> .
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> Sent from my T-Mobile 4G LTE Device
>>>>>>
>>>>>>
>>>>>>  Original message 
>>>>>> From: Mark Waite 
>>>>>> Date: 4/14/21 1:44 PM (GMT-05:00)
>>>>>> To: Jenkins Users 
>>>>>> Subject: Re: Git Plugin Checkout From Branch With Tag
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Apr 14, 2021 at 10:22 AM Eric Fetzer 
>>>>>> wrote:
>>>>>>
>>>>>>> Well if I don't tell it what branch to get, how will it get the
>>>>>>> right branch?  Sorry, Github is a paradigm shift for me.  I've been 
>>>>>>> using
>>>>>>> StarTeam for 20 years and github for just a few weeks now...
>>>>>>>
>>>>>>>
>>>>>> No problem.  Been through that paradigm shift.  Took a long time
>>>>>> before the key git concepts finally registered.
>>>>>>
>>>>>> A git tag represents a specific commit.  A checkout of a tag does not
>>>>>> need a branch.  In your case, you're asking for a branch and a tag.  The
>>>>>> git plugin decided to give you the branch instead of the tag.  If you 
>>>>>> only
>>>>>> ask for a tag, it will checkout the commit at that tag.
>>>>>>
>>>>>> Mark Waite
>>>>>>
>>>>>>
>>>>>>> On Wed, Apr 14, 2021 at 10:13 AM Mark Waite <
>>>>>>> mark.earl.wa...@gmail.com> wrote:
>>>>>>>
>>>>>>>> Don't use a branch parameter.  Place the tag name in the "Branches
>>>>>>>> to build" field.  Compare my screen shots and your screen shots.  You 
>>>>>>>> have
>>>>>>>> more things in your job definition than I have in mine.  Those extra 
>>>>>>>> things
>>>>>>>> are causing the behavior you're seeing
>>>>>>>>
>>>>>>>> On Wed, Apr 14, 2021 at 8:32 AM Eric Fetzer 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> So I've tried to incorporate what you've said, Mark, but it still
>>>>>>>>> just clones the tip revision (9.9.9.10 in this case).  Here are my 
>>>>>>>>> tags:
>>>>>>>>>
>>>>>>>>> git show-ref --tags -d
>>>>>>>&g

Re: Git Plugin Checkout From Branch With Tag

Thanks Mark!  I'll quit whining and displaying my total git inadequacy,
lol...

On Thu, Apr 15, 2021 at 9:14 AM Mark Waite 
wrote:

>
>
> On Thu, Apr 15, 2021 at 7:38 AM Eric Fetzer  wrote:
>
>> So when you turn a tag into a release, does it then act more like a
>> label, or is it still just a set of changed files?
>>
>>
> Refer to https://git-scm.com/book/en/v2/Git-Basics-Tagging for more
> details on the meaning and use of git tags.
>
>
>
>> On Wed, Apr 14, 2021 at 12:48 PM Mark Waite 
>> wrote:
>>
>>>
>>>
>>> On Wed, Apr 14, 2021 at 12:16 PM eric.fetzer 
>>> wrote:
>>>
>>>> Thamks Mark!  So how would I go about checking out a branch based on a
>>>> point in time (a label in most systems)?  Is there a way to snap a label
>>>> and then check out based on that label or are we resigned to only deal in
>>>> tip revisions?
>>>>
>>>>
>>> You can checkout a point in time by checking out a specific SHA-1 hash
>>> that is the most recent commit before that point in time.  See
>>> https://stackoverflow.com/questions/6990484/how-to-checkout-in-git-by-date
>>> .
>>>
>>>
>>>>
>>>>
>>>> Sent from my T-Mobile 4G LTE Device
>>>>
>>>>
>>>>  Original message 
>>>> From: Mark Waite 
>>>> Date: 4/14/21 1:44 PM (GMT-05:00)
>>>> To: Jenkins Users 
>>>> Subject: Re: Git Plugin Checkout From Branch With Tag
>>>>
>>>>
>>>>
>>>> On Wed, Apr 14, 2021 at 10:22 AM Eric Fetzer 
>>>> wrote:
>>>>
>>>>> Well if I don't tell it what branch to get, how will it get the right
>>>>> branch?  Sorry, Github is a paradigm shift for me.  I've been using
>>>>> StarTeam for 20 years and github for just a few weeks now...
>>>>>
>>>>>
>>>> No problem.  Been through that paradigm shift.  Took a long time before
>>>> the key git concepts finally registered.
>>>>
>>>> A git tag represents a specific commit.  A checkout of a tag does not
>>>> need a branch.  In your case, you're asking for a branch and a tag.  The
>>>> git plugin decided to give you the branch instead of the tag.  If you only
>>>> ask for a tag, it will checkout the commit at that tag.
>>>>
>>>> Mark Waite
>>>>
>>>>
>>>>> On Wed, Apr 14, 2021 at 10:13 AM Mark Waite 
>>>>> wrote:
>>>>>
>>>>>> Don't use a branch parameter.  Place the tag name in the "Branches to
>>>>>> build" field.  Compare my screen shots and your screen shots.  You have
>>>>>> more things in your job definition than I have in mine.  Those extra 
>>>>>> things
>>>>>> are causing the behavior you're seeing
>>>>>>
>>>>>> On Wed, Apr 14, 2021 at 8:32 AM Eric Fetzer 
>>>>>> wrote:
>>>>>>
>>>>>>> So I've tried to incorporate what you've said, Mark, but it still
>>>>>>> just clones the tip revision (9.9.9.10 in this case).  Here are my tags:
>>>>>>>
>>>>>>> git show-ref --tags -d
>>>>>>> 4efbdb878c77557d050abbd228fc377adb9419b0 refs/tags/1.0.0.1
>>>>>>> 799eda70c5f052a6f8e757b044b3b60f704a705a refs/tags/1.0.0.1^{}
>>>>>>> c516e3681d2675d4e407b3c26ddfc7da0404c898 refs/tags/1.0.0.2
>>>>>>> 40bf9dd858780d79facfb789921f53d673c08dc9 refs/tags/1.0.0.2^{}
>>>>>>> 9083515085949bfad75f028194226f5a9b1e5ecf refs/tags/9.9.9.10
>>>>>>> 49b0f2cfbf93f36acf6b2124d589a64940eecf18 refs/tags/9.9.9.10^{}
>>>>>>> 019b3f3c634b9071c43f570a62c1191be05c0f4e refs/tags/9.9.9.9
>>>>>>> b2f49473794ad74af0e5943f9292e57e05938fbe refs/tags/9.9.9.9^{}
>>>>>>>
>>>>>>> I'm trying to get 9.9.9.9.  Here is my setup:
>>>>>>>
>>>>>>> [image: image.png]
>>>>>>>
>>>>>>> [image: image.png]
>>>>>>>
>>>>>>> It is honoring the branch specifier for branch, but not for tag.
>>>>>>> I've tried it with just ${tag_name} as well as with tags/${tag_name} as
>>>>>>> well as refs/tags/${tag_name}.  What am i doing wrong?  Thanks!!!
>>>>>>>

Re: Git Plugin Checkout From Branch With Tag

So here's what blows my mind about a tag.  If I go to the tag in GitHub
Enterprise, it has a .zip and .tar.gz associated with it.  If I unpack that
file, it has the entire contents of the repository in it.  That seems like
a view label to me.  But yet all of the documentation talks about the tag
as a change set.  I don't get it!

On Wed, Apr 14, 2021 at 12:48 PM Mark Waite 
wrote:

>
>
> On Wed, Apr 14, 2021 at 12:16 PM eric.fetzer 
> wrote:
>
>> Thamks Mark!  So how would I go about checking out a branch based on a
>> point in time (a label in most systems)?  Is there a way to snap a label
>> and then check out based on that label or are we resigned to only deal in
>> tip revisions?
>>
>>
> You can checkout a point in time by checking out a specific SHA-1 hash
> that is the most recent commit before that point in time.  See
> https://stackoverflow.com/questions/6990484/how-to-checkout-in-git-by-date
> .
>
>
>>
>>
>> Sent from my T-Mobile 4G LTE Device
>>
>>
>>  Original message 
>> From: Mark Waite 
>> Date: 4/14/21 1:44 PM (GMT-05:00)
>> To: Jenkins Users 
>> Subject: Re: Git Plugin Checkout From Branch With Tag
>>
>>
>>
>> On Wed, Apr 14, 2021 at 10:22 AM Eric Fetzer 
>> wrote:
>>
>>> Well if I don't tell it what branch to get, how will it get the right
>>> branch?  Sorry, Github is a paradigm shift for me.  I've been using
>>> StarTeam for 20 years and github for just a few weeks now...
>>>
>>>
>> No problem.  Been through that paradigm shift.  Took a long time before
>> the key git concepts finally registered.
>>
>> A git tag represents a specific commit.  A checkout of a tag does not
>> need a branch.  In your case, you're asking for a branch and a tag.  The
>> git plugin decided to give you the branch instead of the tag.  If you only
>> ask for a tag, it will checkout the commit at that tag.
>>
>> Mark Waite
>>
>>
>>> On Wed, Apr 14, 2021 at 10:13 AM Mark Waite 
>>> wrote:
>>>
>>>> Don't use a branch parameter.  Place the tag name in the "Branches to
>>>> build" field.  Compare my screen shots and your screen shots.  You have
>>>> more things in your job definition than I have in mine.  Those extra things
>>>> are causing the behavior you're seeing
>>>>
>>>> On Wed, Apr 14, 2021 at 8:32 AM Eric Fetzer 
>>>> wrote:
>>>>
>>>>> So I've tried to incorporate what you've said, Mark, but it still just
>>>>> clones the tip revision (9.9.9.10 in this case).  Here are my tags:
>>>>>
>>>>> git show-ref --tags -d
>>>>> 4efbdb878c77557d050abbd228fc377adb9419b0 refs/tags/1.0.0.1
>>>>> 799eda70c5f052a6f8e757b044b3b60f704a705a refs/tags/1.0.0.1^{}
>>>>> c516e3681d2675d4e407b3c26ddfc7da0404c898 refs/tags/1.0.0.2
>>>>> 40bf9dd858780d79facfb789921f53d673c08dc9 refs/tags/1.0.0.2^{}
>>>>> 9083515085949bfad75f028194226f5a9b1e5ecf refs/tags/9.9.9.10
>>>>> 49b0f2cfbf93f36acf6b2124d589a64940eecf18 refs/tags/9.9.9.10^{}
>>>>> 019b3f3c634b9071c43f570a62c1191be05c0f4e refs/tags/9.9.9.9
>>>>> b2f49473794ad74af0e5943f9292e57e05938fbe refs/tags/9.9.9.9^{}
>>>>>
>>>>> I'm trying to get 9.9.9.9.  Here is my setup:
>>>>>
>>>>> [image: image.png]
>>>>>
>>>>> [image: image.png]
>>>>>
>>>>> It is honoring the branch specifier for branch, but not for tag.  I've
>>>>> tried it with just ${tag_name} as well as with tags/${tag_name} as well as
>>>>> refs/tags/${tag_name}.  What am i doing wrong?  Thanks!!!
>>>>>
>>>>> On Wed, Apr 14, 2021 at 8:06 AM Eric Fetzer 
>>>>> wrote:
>>>>>
>>>>>> Thanks for the detailed description Mark!  Only one thing confuses
>>>>>> me, I don't see you specifying the branch to build anywhere in there.  
>>>>>> Can
>>>>>> you explain that to me because I have to specify the branch as well as 
>>>>>> the
>>>>>> tag?
>>>>>>
>>>>>> On Tue, Apr 13, 2021 at 7:42 PM Mark Waite 
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Apr 13, 2021 at 5:57 PM eric.fetzer 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I am SO sorry

Re: Git Plugin Checkout From Branch With Tag

So when you turn a tag into a release, does it then act more like a label,
or is it still just a set of changed files?

On Wed, Apr 14, 2021 at 12:48 PM Mark Waite 
wrote:

>
>
> On Wed, Apr 14, 2021 at 12:16 PM eric.fetzer 
> wrote:
>
>> Thamks Mark!  So how would I go about checking out a branch based on a
>> point in time (a label in most systems)?  Is there a way to snap a label
>> and then check out based on that label or are we resigned to only deal in
>> tip revisions?
>>
>>
> You can checkout a point in time by checking out a specific SHA-1 hash
> that is the most recent commit before that point in time.  See
> https://stackoverflow.com/questions/6990484/how-to-checkout-in-git-by-date
> .
>
>
>>
>>
>> Sent from my T-Mobile 4G LTE Device
>>
>>
>>  Original message 
>> From: Mark Waite 
>> Date: 4/14/21 1:44 PM (GMT-05:00)
>> To: Jenkins Users 
>> Subject: Re: Git Plugin Checkout From Branch With Tag
>>
>>
>>
>> On Wed, Apr 14, 2021 at 10:22 AM Eric Fetzer 
>> wrote:
>>
>>> Well if I don't tell it what branch to get, how will it get the right
>>> branch?  Sorry, Github is a paradigm shift for me.  I've been using
>>> StarTeam for 20 years and github for just a few weeks now...
>>>
>>>
>> No problem.  Been through that paradigm shift.  Took a long time before
>> the key git concepts finally registered.
>>
>> A git tag represents a specific commit.  A checkout of a tag does not
>> need a branch.  In your case, you're asking for a branch and a tag.  The
>> git plugin decided to give you the branch instead of the tag.  If you only
>> ask for a tag, it will checkout the commit at that tag.
>>
>> Mark Waite
>>
>>
>>> On Wed, Apr 14, 2021 at 10:13 AM Mark Waite 
>>> wrote:
>>>
>>>> Don't use a branch parameter.  Place the tag name in the "Branches to
>>>> build" field.  Compare my screen shots and your screen shots.  You have
>>>> more things in your job definition than I have in mine.  Those extra things
>>>> are causing the behavior you're seeing
>>>>
>>>> On Wed, Apr 14, 2021 at 8:32 AM Eric Fetzer 
>>>> wrote:
>>>>
>>>>> So I've tried to incorporate what you've said, Mark, but it still just
>>>>> clones the tip revision (9.9.9.10 in this case).  Here are my tags:
>>>>>
>>>>> git show-ref --tags -d
>>>>> 4efbdb878c77557d050abbd228fc377adb9419b0 refs/tags/1.0.0.1
>>>>> 799eda70c5f052a6f8e757b044b3b60f704a705a refs/tags/1.0.0.1^{}
>>>>> c516e3681d2675d4e407b3c26ddfc7da0404c898 refs/tags/1.0.0.2
>>>>> 40bf9dd858780d79facfb789921f53d673c08dc9 refs/tags/1.0.0.2^{}
>>>>> 9083515085949bfad75f028194226f5a9b1e5ecf refs/tags/9.9.9.10
>>>>> 49b0f2cfbf93f36acf6b2124d589a64940eecf18 refs/tags/9.9.9.10^{}
>>>>> 019b3f3c634b9071c43f570a62c1191be05c0f4e refs/tags/9.9.9.9
>>>>> b2f49473794ad74af0e5943f9292e57e05938fbe refs/tags/9.9.9.9^{}
>>>>>
>>>>> I'm trying to get 9.9.9.9.  Here is my setup:
>>>>>
>>>>> [image: image.png]
>>>>>
>>>>> [image: image.png]
>>>>>
>>>>> It is honoring the branch specifier for branch, but not for tag.  I've
>>>>> tried it with just ${tag_name} as well as with tags/${tag_name} as well as
>>>>> refs/tags/${tag_name}.  What am i doing wrong?  Thanks!!!
>>>>>
>>>>> On Wed, Apr 14, 2021 at 8:06 AM Eric Fetzer 
>>>>> wrote:
>>>>>
>>>>>> Thanks for the detailed description Mark!  Only one thing confuses
>>>>>> me, I don't see you specifying the branch to build anywhere in there.  
>>>>>> Can
>>>>>> you explain that to me because I have to specify the branch as well as 
>>>>>> the
>>>>>> tag?
>>>>>>
>>>>>> On Tue, Apr 13, 2021 at 7:42 PM Mark Waite 
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Apr 13, 2021 at 5:57 PM eric.fetzer 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I am SO sorry Mark, I confused this Jenkins thread with a totally
>>>>>>>> unrelated support ticket.  I'm not using pipeline, just the git plug 
>>>>>>>> in in
>>>&g

Re: Git Plugin Checkout From Branch With Tag

2021-04-13 Thread Eric Fetzer

Tried a bunch more stuff using Git Parameters:

https://plugins.jenkins.io/git-parameter/

Again, I can checkout from the branch, but not using the tag.  I set a git
parameter for branch and then put it in the branch specifier and that
worked.  I added another for tag, then put that in the same branch
specifier after a space and got an error.  If I put it in an additional
branch specifier, it seems to have gotten ignored.  Just got the tip
revision from that branch.

On Tue, Apr 13, 2021 at 12:57 PM eric@gmail.com 
wrote:

> OK, I think I've tried everything in this OLD conversation, but none of
> them work.  I have no issues checking out from a branch using branch
> specifier.  I've tried adding on to the specifier:  ${my_branch}
> tags/${my_tag}.  Have also added another branch and used this sort of thing
> (as well as every other way they said to do it in that thread).  Every way
> seems to just get the tip revision of all the files in that branch.  Does
> anyone have guidance of how to get this done?  Thanks!  Eric
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Jenkins Users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/jenkinsci-users/UGyBIx3pX9s/unsubscribe.
> To unsubscribe from this group and all its topics, 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/c045a834-8d68-46fe-8b72-860e89416209n%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/c045a834-8d68-46fe-8b72-860e89416209n%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/CAByBica3dvXErnbX2hT-6hSmFHiANVe1517yShpFehNto0ub4w%40mail.gmail.com.

Git Plugin Checkout From Branch With Tag

2021-04-13 Thread eric....@gmail.com

OK, I think I've tried everything in this OLD conversation, but none of 
them work.  I have no issues checking out from a branch using branch 
specifier.  I've tried adding on to the specifier:  ${my_branch} 
tags/${my_tag}.  Have also added another branch and used this sort of thing 
(as well as every other way they said to do it in that thread).  Every way 
seems to just get the tip revision of all the files in that branch.  Does 
anyone have guidance of how to get this done?  Thanks!  Eric

-- 
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/c045a834-8d68-46fe-8b72-860e89416209n%40googlegroups.com.

Re: Node no longer working

2021-04-12 Thread eric....@gmail.com

OK, further proof that I'm fried this week.  I needed to put the key in for 
the jenkins user, not the  user.  The jenkins user public key is 
in the authorized_hosts file for  so that he can authenticate as 
that user.  This is fixed...

On Monday, April 12, 2021 at 10:36:46 AM UTC-6 eric@gmail.com wrote:

> So I had a node up to run as a user other than Jenkins.  It stopped 
> working and I have no idea why.  My trouble-shooting ability has just 
> reached its limit.  Anyone have any ideas for me to try?  Here are my steps 
> to set it up (the RSA Key seems to be what is failing):
>
>
>1. Go to Credentials / System (shows up under Credentials) / Global 
>credentials
>2. Click Add Credentials 
>3. Kind:  SSH Username with private key 
>4. ID:  RSAKey
>Description:  RSA Key
>Username:  
>Private Key:  Select Enter directly and paste it in from results of 
>cat ~/.ssh/id_rsa (RSA should have been created without passphrase, but if 
>you created a passphrase, enter it in the Passphrase text box)
>
>5. Go to Manage Jenkins / Manage Nodes and Clouds / New Node 
>6. Name:  Node
>Description: Run as 
># of executors: 1
>Remote root directory: /home/
>Labels: Checkout
>Usage: Only build jobs with label expressions matching this node
>Launch method: Launch agents via SSH
>Host: localhost
>Credentials:  (username RSA Key)
>Host Key Verification Strategy: Non verifying Verification Strategy
>Availability: Keep this agent online as much as possible
>
> So, when I try to start the node, I get:
>
>
>
> [04/12/21 11:34:47] [SSH] Opening SSH connection to localhost:22. 
> [04/12/21 11:34:47] [SSH] WARNING: SSH Host Keys are not being verified. 
> Man-in-the-middle attacks may be possible against this connection. ERROR: 
> Server rejected the 1 private key(s) for  
> (credentialId:RSAKey/method:publickey)
> [04/12/21 11:34:47] [SSH] Authentication failed. Authentication failed. 
> [04/12/21 11:34:47] Launch failed - cleaning up connection 
> [04/12/21 11:34:47] [SSH] Connection closed.
>
> Thanks much!
> Eric
>

-- 
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/0a42daa4-1072-4995-a698-33ea0968fbc4n%40googlegroups.com.

Re: Node no longer working

2021-04-12 Thread eric....@gmail.com

Note that I have no problem ssh'ing from the jenkins user to the  
user passwordless.  The jenkins user key is in the authorized_keys file of 
the  user.  Really kind of blown away why this all of a sudden 
stopped working.  It was working fine...

On Monday, April 12, 2021 at 10:36:46 AM UTC-6 eric@gmail.com wrote:

> So I had a node up to run as a user other than Jenkins.  It stopped 
> working and I have no idea why.  My trouble-shooting ability has just 
> reached its limit.  Anyone have any ideas for me to try?  Here are my steps 
> to set it up (the RSA Key seems to be what is failing):
>
>
>1. Go to Credentials / System (shows up under Credentials) / Global 
>credentials
>2. Click Add Credentials 
>3. Kind:  SSH Username with private key 
>4. ID:  RSAKey
>Description:  RSA Key
>Username:  
>Private Key:  Select Enter directly and paste it in from results of 
>cat ~/.ssh/id_rsa (RSA should have been created without passphrase, but if 
>you created a passphrase, enter it in the Passphrase text box)
>
>5. Go to Manage Jenkins / Manage Nodes and Clouds / New Node 
>6. Name:  Node
>Description: Run as 
># of executors: 1
>Remote root directory: /home/
>Labels: Checkout
>Usage: Only build jobs with label expressions matching this node
>Launch method: Launch agents via SSH
>Host: localhost
>Credentials:  (username RSA Key)
>Host Key Verification Strategy: Non verifying Verification Strategy
>Availability: Keep this agent online as much as possible
>
> So, when I try to start the node, I get:
>
>
>
> [04/12/21 11:34:47] [SSH] Opening SSH connection to localhost:22. 
> [04/12/21 11:34:47] [SSH] WARNING: SSH Host Keys are not being verified. 
> Man-in-the-middle attacks may be possible against this connection. ERROR: 
> Server rejected the 1 private key(s) for  
> (credentialId:RSAKey/method:publickey)
> [04/12/21 11:34:47] [SSH] Authentication failed. Authentication failed. 
> [04/12/21 11:34:47] Launch failed - cleaning up connection 
> [04/12/21 11:34:47] [SSH] Connection closed.
>
> Thanks much!
> Eric
>

-- 
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/fd08eb85-0b55-427d-bc65-bd3ec57b4811n%40googlegroups.com.

Node no longer working

2021-04-12 Thread eric....@gmail.com

So I had a node up to run as a user other than Jenkins. It stopped working
and I have no idea why. My trouble-shooting ability has just reached its
limit. Anyone have any ideas for me to try? Here are my steps to set it
up (the RSA Key seems to be what is failing):

1. Go to Credentials / System (shows up under Credentials) / Global
credentials
2. Click Add Credentials
3. Kind: SSH Username with private key
4. ID: RSAKey
Description: RSA Key
Username:
Private Key: Select Enter directly and paste it in from results of cat
~/.ssh/id_rsa (RSA should have been created without passphrase, but if you
created a passphrase, enter it in the Passphrase text box)

5. Go to Manage Jenkins / Manage Nodes and Clouds / New Node
6. Name: Node
Description: Run as
# of executors: 1
Remote root directory: /home/
Labels: Checkout
Usage: Only build jobs with label expressions matching this node
Launch method: Launch agents via SSH
Host: localhost
Credentials: (username RSA Key)
Host Key Verification Strategy: Non verifying Verification Strategy
Availability: Keep this agent online as much as possible

So, when I try to start the node, I get:

[04/12/21 11:34:47] [SSH] Opening SSH connection to localhost:22.
[04/12/21 11:34:47] [SSH] WARNING: SSH Host Keys are not being verified.
Man-in-the-middle attacks may be possible against this connection. ERROR:
Server rejected the 1 private key(s) for
(credentialId:RSAKey/method:publickey)
[04/12/21 11:34:47] [SSH] Authentication failed. Authentication failed.
[04/12/21 11:34:47] Launch failed - cleaning up connection
[04/12/21 11:34:47] [SSH] Connection closed.

Thanks much!
Eric

--
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/1b82bf53-b379-4342-9df8-45e904df6a1bn%40googlegroups.com.

Re: GitHub Clone to Different Local Directory

2021-03-31 Thread Eric Fetzer

Hi Dirk, sorry I didn't respond earlier, but I did try these things.  They
just didn't work.  Questioning whether I didn't run into a firewall rule.
Even though they allow us to add an SSH Key in GitHub, that doesn't mean
they've opened port 22 on the server.  When I try to ssh g...@github.com, it
ends up "Connection timed out".  I would kind of expect a refusal if the
firewall were slapping it down, but not sure.  I've also turned
strictHostKeyChecking off and that also produced failure from the cloning.
This is a gov repository so I'm guessing that it is, indeed, a firewall
rule.  Thanks for all the help!  Guess I should be thankful that 443 is
open to me...

On Wed, Mar 31, 2021 at 12:10 AM 'Dirk Heinrichs' via Jenkins Users <
jenkinsci-users@googlegroups.com> wrote:

> Am Montag, den 29.03.2021, 12:26 -0700 schrieb eric@gmail.com:
>
> The only thing I can guess is that ssh is getting a question when he
> attempts to connect wanting to be added to the known_hosts file.  Wondering
> if maybe there's a way to establish this if this is indeed the issue?
>
>
> Yes, of course it does, and yes, there is (see my other two replies from
> yesterday). SSH verifies that it indeed connects to the correct *remote*
> host (github.com in this case), by comparing the *HOST* key of the remote
> host it has stored in the *local* user's (or machine's) *known_hosts*
> file. On the first connection, it asks the user to confirm the remote host
> key (unless the user has certain options set in her *~/.ssh/config* to
> either skip the verification completely or accept new keys w/o asking). And
> this is what's happening here.
>
> So, to get out of this, you need to login to your Jenkins machine once (as
> the user running Jenkins), run "ssh g...@github.com" and confirm the host
> key. Or add "StrictHostKeyChecking no" or, if your SSH is recent enough,
> "StrictHostKeyChecking accept-new" to that user's ~/.ssh/config (or
> machine's /etc/ssh/ssh_config).
>
> HTH...
>
> Dirk
>
> --
>
> *Dirk Heinrichs*
> Senior Systems Engineer, Delivery Pipeline
> OpenText ™ Discovery | Recommind
> *Phone*: +49 2226 15966 18
> *Email*: dhein...@opentext.com
> *Website*: www.recommind.de
> Recommind GmbH, Von-Liebig-Straße 1, 53359 Rheinbach
> Vertretungsberechtigte Geschäftsführer Gordon Davies, Madhu Ranganathan,
> Christian Waida, Registergericht Amtsgericht Bonn, Registernummer HRB 10646
> This e-mail may contain confidential and/or privileged information. If you
> are not the intended recipient (or have received this e-mail in error)
> please notify the sender immediately and destroy this e-mail. Any
> unauthorized copying, disclosure or distribution of the material in this
> e-mail is strictly forbidden
> Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
> Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
> irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
> vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte
> Weitergabe dieser Mail sind nicht gestattet.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Jenkins Users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/jenkinsci-users/Ob42FqU-0UY/unsubscribe.
> To unsubscribe from this group and all its topics, 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/d8bd7d209c38e258fa083e78f484d2529a9b4cab.camel%40opentext.com
> <https://groups.google.com/d/msgid/jenkinsci-users/d8bd7d209c38e258fa083e78f484d2529a9b4cab.camel%40opentext.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/CAByBicZijnZo%2BsKteoUCzoTwJ_%3DxFv0Yt7mppbEbkFCa9BR_zQ%40mail.gmail.com.

Re: GitHub Clone to Different Local Directory

On second thought, I don't think this ever worked at all.  I had attempted
to add a line to the known_hosts file yesterday, that was probably what I
saw and thought it worked but transposed.  The transposition was me.  I'm
giving up on the rsa thing, going back to my clunky way to do it.  Thanks
for trying!

On Tue, Mar 30, 2021 at 11:56 AM Eric Fetzer  wrote:

> Holy cow, this is NOT my day.  So I did it once and it appeared to work.
> I vi'd the known_hosts file and it was at the bottom but it looked like it
> was transposed wrong (instead of a.b.c.d, it had b.a.c.d).  So I deleted
> that line and redid the entry.  It no longer adds to my known_hosts file
> even though it throws no error.  I'm totally lost as to what is happening
> here...
>
> On Tue, Mar 30, 2021 at 11:26 AM Jérôme Godbout 
> wrote:
>
>> Do not check if the first command succeed, it remove previous entry if
>> any. If none was present the command will fail.
>>
>>
>>
>> Do the following:
>>
>>
>>
>> String domain = “github.com”;
>>
>> sh("ssh-keygen -R ${domain} -f \".ssh/known_hosts\"", returnStatus: true);
>>
>> sh("ssh-keyscan -t rsa ${domain} >> \".ssh/known_hosts\"")
>>
>> Now that should do it, you do not really care if the remove hit something
>> or not, just make sure you do not have an old invalid entry.
>>
>>
>>
>> *Jérôme Godbout, B. Ing.*
>>
>>
>> Software / Firmware Team Lead
>> *O:* (418) 682-3636 ext.: 114
>>
>> *C:* (581) 777-0050
>> godbo...@dimonoff.com
>>
>> [image: signature_1235056834] <https://www.dimonoff.com/>
>>
>> *dimonoff.com* <https://www.dimonoff.com/>
>>
>> 1015 Avenue Wilfrid-Pelletier,
>>
>> Québec, QC G1W 0C4, 4e étage
>>
>>
>>
>>
>>
>> *From: *jenkinsci-users@googlegroups.com <
>> jenkinsci-users@googlegroups.com> on behalf of Eric Fetzer <
>> eric.fet...@gmail.com>
>> *Date: *Tuesday, March 30, 2021 at 1:18 PM
>> *To: *jenkinsci-users@googlegroups.com 
>> *Subject: *Re: GitHub Clone to Different Local Directory
>>
>> For this one I get "Host 'myDomain' not found in .ssh/known_hosts".  Not
>> sure what I should be using for domain.  Seems it should be github.com
>> in the example, so if my connection is 
>> g...@mygitproject.mydomain.com:/my/project,
>> I would put "myGitProject.mydomain.com" in there.  Is that correct?
>>
>>
>>
>> On Tue, Mar 30, 2021 at 9:44 AM Jérôme Godbout 
>> wrote:
>>
>> Oups my bad, in my hurry I forgot to change the right exe, I keep those
>> into variable and I badly refilled them here:
>>
>>
>>
>> sh("ssh-keygen -R ${domain} -f \".ssh/known_hosts\"")
>>
>> sh("ssh-keyscan -t rsa ${domain} >> \".ssh/known_hosts\"")
>>
>> The first one removes any old entry, the second one adds the record to
>> the file.
>>
>>
>>
>> *Jérôme Godbout, B. Ing.*
>>
>>
>> Software / Firmware Team Lead
>> *O:* (418) 682-3636 ext.: 114
>>
>> *C:* (581) 777-0050
>> godbo...@dimonoff.com
>>
>> [image: signature_796898478] <https://www.dimonoff.com/>
>>
>> *dimonoff.com* <https://www.dimonoff.com/>
>>
>> 1015 Avenue Wilfrid-Pelletier,
>>
>> Québec, QC G1W 0C4, 4e étage
>>
>>
>>
>>
>>
>> *From: *jenkinsci-users@googlegroups.com <
>> jenkinsci-users@googlegroups.com> on behalf of Eric Fetzer <
>> eric.fet...@gmail.com>
>> *Date: *Tuesday, March 30, 2021 at 10:15 AM
>> *To: *jenkinsci-users@googlegroups.com 
>> *Subject: *Re: GitHub Clone to Different Local Directory
>>
>> So the url is git@a.b.c.d and I tried to use your first command with
>> a.b.c.d for domain and got "bad remote forwarding specification".  I tried
>> it with b.c.d and c.d as well resulting in the same error.  Any ideas?
>> Thanks!
>>
>>
>>
>> On Mon, Mar 29, 2021 at 2:06 PM Jérôme Godbout 
>> wrote:
>>
>> I do add the domain and hsot to my known host file before to avoid that
>> nasty confirm:
>>
>>
>>
>> sh("ssh -R ${domain} -f \".ssh/known_hosts\"")
>>
>> sh("ssh -t rsa ${domain} >> \".ssh/known_hosts\"")
>>
>>
>>
>> that should do the trick and avoid that prompt when later used. Use the
>> domain of the repos url domain.
>>
>>
>>
>>

Re: GitHub Clone to Different Local Directory

Holy cow, this is NOT my day.  So I did it once and it appeared to work.  I
vi'd the known_hosts file and it was at the bottom but it looked like it
was transposed wrong (instead of a.b.c.d, it had b.a.c.d).  So I deleted
that line and redid the entry.  It no longer adds to my known_hosts file
even though it throws no error.  I'm totally lost as to what is happening
here...

On Tue, Mar 30, 2021 at 11:26 AM Jérôme Godbout  wrote:

> Do not check if the first command succeed, it remove previous entry if
> any. If none was present the command will fail.
>
>
>
> Do the following:
>
>
>
> String domain = “github.com”;
>
> sh("ssh-keygen -R ${domain} -f \".ssh/known_hosts\"", returnStatus: true);
>
> sh("ssh-keyscan -t rsa ${domain} >> \".ssh/known_hosts\"")
>
> Now that should do it, you do not really care if the remove hit something
> or not, just make sure you do not have an old invalid entry.
>
>
>
> *Jérôme Godbout, B. Ing.*
>
>
> Software / Firmware Team Lead
> *O:* (418) 682-3636 ext.: 114
>
> *C:* (581) 777-0050
> godbo...@dimonoff.com
>
> [image: signature_1235056834] <https://www.dimonoff.com/>
>
> *dimonoff.com* <https://www.dimonoff.com/>
>
> 1015 Avenue Wilfrid-Pelletier,
>
> Québec, QC G1W 0C4, 4e étage
>
>
>
>
>
> *From: *jenkinsci-users@googlegroups.com 
> on behalf of Eric Fetzer 
> *Date: *Tuesday, March 30, 2021 at 1:18 PM
> *To: *jenkinsci-users@googlegroups.com 
> *Subject: *Re: GitHub Clone to Different Local Directory
>
> For this one I get "Host 'myDomain' not found in .ssh/known_hosts".  Not
> sure what I should be using for domain.  Seems it should be github.com in
> the example, so if my connection is 
> g...@mygitproject.mydomain.com:/my/project,
> I would put "myGitProject.mydomain.com" in there.  Is that correct?
>
>
>
> On Tue, Mar 30, 2021 at 9:44 AM Jérôme Godbout  wrote:
>
> Oups my bad, in my hurry I forgot to change the right exe, I keep those
> into variable and I badly refilled them here:
>
>
>
> sh("ssh-keygen -R ${domain} -f \".ssh/known_hosts\"")
>
> sh("ssh-keyscan -t rsa ${domain} >> \".ssh/known_hosts\"")
>
> The first one removes any old entry, the second one adds the record to the
> file.
>
>
>
> *Jérôme Godbout, B. Ing.*
>
>
> Software / Firmware Team Lead
> *O:* (418) 682-3636 ext.: 114
>
> *C:* (581) 777-0050
> godbo...@dimonoff.com
>
> [image: signature_796898478] <https://www.dimonoff.com/>
>
> *dimonoff.com* <https://www.dimonoff.com/>
>
> 1015 Avenue Wilfrid-Pelletier,
>
> Québec, QC G1W 0C4, 4e étage
>
>
>
>
>
> *From: *jenkinsci-users@googlegroups.com 
> on behalf of Eric Fetzer 
> *Date: *Tuesday, March 30, 2021 at 10:15 AM
> *To: *jenkinsci-users@googlegroups.com 
> *Subject: *Re: GitHub Clone to Different Local Directory
>
> So the url is git@a.b.c.d and I tried to use your first command with
> a.b.c.d for domain and got "bad remote forwarding specification".  I tried
> it with b.c.d and c.d as well resulting in the same error.  Any ideas?
> Thanks!
>
>
>
> On Mon, Mar 29, 2021 at 2:06 PM Jérôme Godbout  wrote:
>
> I do add the domain and hsot to my known host file before to avoid that
> nasty confirm:
>
>
>
> sh("ssh -R ${domain} -f \".ssh/known_hosts\"")
>
> sh("ssh -t rsa ${domain} >> \".ssh/known_hosts\"")
>
>
>
> that should do the trick and avoid that prompt when later used. Use the
> domain of the repos url domain.
>
>
>
> *Jérôme Godbout, B. Ing.*
>
>
> Software / Firmware Team Lead
> *O:* (418) 682-3636 ext.: 114
>
> *C:* (581) 777-0050
> godbo...@dimonoff.com
>
> [image: signature_168530195] <https://www.dimonoff.com/>
>
> *dimonoff.com* <https://www.dimonoff.com/>
>
> 1015 Avenue Wilfrid-Pelletier,
>
> Québec, QC G1W 0C4, 4e étage
>
>
>
>
>
> *From: *jenkinsci-users@googlegroups.com 
> on behalf of eric@gmail.com 
> *Date: *Monday, March 29, 2021 at 3:27 PM
> *To: *Jenkins Users 
> *Subject: *Re: GitHub Clone to Different Local Directory
>
> The only thing I can guess is that ssh is getting a question when he
> attempts to connect wanting to be added to the known_hosts file.  Wondering
> if maybe there's a way to establish this if this is indeed the issue?
>
> On Monday, March 29, 2021 at 12:07:01 PM UTC-6 eric@gmail.com wrote:
>
> Thanks Mark!  I believe I'm one step closer but it's still not working.
> I'm now getting:
>
>
>
> Caused by: hudson.plugins.gi

Re: GitHub Clone to Different Local Directory

For this one I get "Host 'myDomain' not found in .ssh/known_hosts".  Not
sure what I should be using for domain.  Seems it should be github.com in
the example, so if my connection is g...@mygitproject.mydomain.com:/my/project,
I would put "myGitProject.mydomain.com" in there.  Is that correct?

On Tue, Mar 30, 2021 at 9:44 AM Jérôme Godbout  wrote:

> Oups my bad, in my hurry I forgot to change the right exe, I keep those
> into variable and I badly refilled them here:
>
>
>
> sh("ssh-keygen -R ${domain} -f \".ssh/known_hosts\"")
>
> sh("ssh-keyscan -t rsa ${domain} >> \".ssh/known_hosts\"")
>
> The first one removes any old entry, the second one adds the record to the
> file.
>
>
>
> *Jérôme Godbout, B. Ing.*
>
>
> Software / Firmware Team Lead
> *O:* (418) 682-3636 ext.: 114
>
> *C:* (581) 777-0050
> godbo...@dimonoff.com
>
> [image: signature_796898478] <https://www.dimonoff.com/>
>
> *dimonoff.com* <https://www.dimonoff.com/>
>
> 1015 Avenue Wilfrid-Pelletier,
>
> Québec, QC G1W 0C4, 4e étage
>
>
>
>
>
> *From: *jenkinsci-users@googlegroups.com 
> on behalf of Eric Fetzer 
> *Date: *Tuesday, March 30, 2021 at 10:15 AM
> *To: *jenkinsci-users@googlegroups.com 
> *Subject: *Re: GitHub Clone to Different Local Directory
>
> So the url is git@a.b.c.d and I tried to use your first command with
> a.b.c.d for domain and got "bad remote forwarding specification".  I tried
> it with b.c.d and c.d as well resulting in the same error.  Any ideas?
> Thanks!
>
>
>
> On Mon, Mar 29, 2021 at 2:06 PM Jérôme Godbout  wrote:
>
> I do add the domain and hsot to my known host file before to avoid that
> nasty confirm:
>
>
>
> sh("ssh -R ${domain} -f \".ssh/known_hosts\"")
>
> sh("ssh -t rsa ${domain} >> \".ssh/known_hosts\"")
>
>
>
> that should do the trick and avoid that prompt when later used. Use the
> domain of the repos url domain.
>
>
>
> *Jérôme Godbout, B. Ing.*
>
>
> Software / Firmware Team Lead
> *O:* (418) 682-3636 ext.: 114
>
> *C:* (581) 777-0050
> godbo...@dimonoff.com
>
> [image: signature_168530195] <https://www.dimonoff.com/>
>
> *dimonoff.com* <https://www.dimonoff.com/>
>
> 1015 Avenue Wilfrid-Pelletier,
>
> Québec, QC G1W 0C4, 4e étage
>
>
>
>
>
> *From: *jenkinsci-users@googlegroups.com 
> on behalf of eric....@gmail.com 
> *Date: *Monday, March 29, 2021 at 3:27 PM
> *To: *Jenkins Users 
> *Subject: *Re: GitHub Clone to Different Local Directory
>
> The only thing I can guess is that ssh is getting a question when he
> attempts to connect wanting to be added to the known_hosts file.  Wondering
> if maybe there's a way to establish this if this is indeed the issue?
>
> On Monday, March 29, 2021 at 12:07:01 PM UTC-6 eric@gmail.com wrote:
>
> Thanks Mark!  I believe I'm one step closer but it's still not working.
> I'm now getting:
>
>
>
> Caused by: hudson.plugins.git.GitException: Command "git fetch --tags
> --progress git@myURLRepo:myUser/myProject.git
> +refs/heads/*:refs/remotes/origin/*" returned status code 128: stdout:
> stderr: ssh: connect to host myURLRepo port 22: Connection timed out fatal:
> Could not read from remote repository. Please make sure you have the
> correct access rights and the repository exists.
>
>
>
>
>
>
>
> On Monday, March 29, 2021 at 11:23:28 AM UTC-6 Mark Waite wrote:
>
> You can't use ssh authentication with an https repository URL.  When using
> ssh authentication, you need to use an ssh repository URL.  When using
> username / password or username / token, you must use an HTTPS (or HTTP)
> URL.
>
>
>
> Mark Waite
>
>
>
> On Mon, Mar 29, 2021 at 10:38 AM Eric Fetzer  wrote:
>
> Hmmm, thought that was going to work but it didn't.  I followed
> everything to a T at:
> https://mohitgoyal.co/2017/02/27/configuring-ssh-authentication-between-github-and-jenkins/
>
> The output shows:
>
> Building on master in workspace /var/lib/jenkins/workspace/Git-Checkout
>
> using credential JenkinsSSHKey
>
>  > git rev-parse --is-inside-work-tree # timeout=10
>
> Fetching changes from the remote Git repository
>
>  > git config remote.origin.url https://m 
> <https://code.fs.usda.gov/ericfetzer/iNAP.git>yGitRepo.git # timeout=10
>
> Cleaning workspace
>
>  > git rev-parse --verify HEAD # timeout=10
>
> No valid HEAD. Skipping the resetting
>
>  > git clean -fdx # timeout=10
>
> Fetching upstrea

Re: GitHub Clone to Different Local Directory

So the url is git@a.b.c.d and I tried to use your first command with
a.b.c.d for domain and got "bad remote forwarding specification".  I tried
it with b.c.d and c.d as well resulting in the same error.  Any ideas?
Thanks!

On Mon, Mar 29, 2021 at 2:06 PM Jérôme Godbout  wrote:

> I do add the domain and hsot to my known host file before to avoid that
> nasty confirm:
>
>
>
> sh("ssh -R ${domain} -f \".ssh/known_hosts\"")
>
> sh("ssh -t rsa ${domain} >> \".ssh/known_hosts\"")
>
>
>
> that should do the trick and avoid that prompt when later used. Use the
> domain of the repos url domain.
>
>
>
> *Jérôme Godbout, B. Ing.*
>
>
> Software / Firmware Team Lead
> *O:* (418) 682-3636 ext.: 114
>
> *C:* (581) 777-0050
> godbo...@dimonoff.com
>
> [image: signature_168530195] <https://www.dimonoff.com/>
>
> *dimonoff.com* <https://www.dimonoff.com/>
>
> 1015 Avenue Wilfrid-Pelletier,
>
> Québec, QC G1W 0C4, 4e étage
>
>
>
>
>
> *From: *jenkinsci-users@googlegroups.com 
> on behalf of eric@gmail.com 
> *Date: *Monday, March 29, 2021 at 3:27 PM
> *To: *Jenkins Users 
> *Subject: *Re: GitHub Clone to Different Local Directory
>
> The only thing I can guess is that ssh is getting a question when he
> attempts to connect wanting to be added to the known_hosts file.  Wondering
> if maybe there's a way to establish this if this is indeed the issue?
>
> On Monday, March 29, 2021 at 12:07:01 PM UTC-6 eric@gmail.com wrote:
>
> Thanks Mark!  I believe I'm one step closer but it's still not working.
> I'm now getting:
>
>
>
> Caused by: hudson.plugins.git.GitException: Command "git fetch --tags
> --progress git@myURLRepo:myUser/myProject.git
> +refs/heads/*:refs/remotes/origin/*" returned status code 128: stdout:
> stderr: ssh: connect to host myURLRepo port 22: Connection timed out fatal:
> Could not read from remote repository. Please make sure you have the
> correct access rights and the repository exists.
>
>
>
>
>
>
>
> On Monday, March 29, 2021 at 11:23:28 AM UTC-6 Mark Waite wrote:
>
> You can't use ssh authentication with an https repository URL.  When using
> ssh authentication, you need to use an ssh repository URL.  When using
> username / password or username / token, you must use an HTTPS (or HTTP)
> URL.
>
>
>
> Mark Waite
>
>
>
> On Mon, Mar 29, 2021 at 10:38 AM Eric Fetzer  wrote:
>
> Hmmm, thought that was going to work but it didn't.  I followed
> everything to a T at:
> https://mohitgoyal.co/2017/02/27/configuring-ssh-authentication-between-github-and-jenkins/
>
> The output shows:
>
>
> Building on master in workspace /var/lib/jenkins/workspace/Git-Checkout
>
> using credential JenkinsSSHKey
>
>  > git rev-parse --is-inside-work-tree # timeout=10
>
> Fetching changes from the remote Git repository
>
>  > git config remote.origin.url https://m 
> <https://code.fs.usda.gov/ericfetzer/iNAP.git>yGitRepo.git # timeout=10
>
> Cleaning workspace
>
>  > git rev-parse --verify HEAD # timeout=10
>
> No valid HEAD. Skipping the resetting
>
>  > git clean -fdx # timeout=10
>
> Fetching upstream changes from https://m 
> <https://code.fs.usda.gov/ericfetzer/iNAP.git>yGitRepo.git
>
>  > git --version # timeout=10
>
> using GIT_SSH to set credentials
>
>
>
> So I see it's using the creds.  Then when it tries to do the fetch, it
> says:
>
>
>
>  > git fetch --tags --progress https://m 
> <https://code.fs.usda.gov/ericfetzer/iNAP.git>yGitRepo.git 
> +refs/heads/*:refs/remotes/origin/* # timeout=10
>
> ERROR: Error fetching remote repo 'origin'
>
> hudson.plugins.git.GitException: Failed to fetch from https://m 
> <https://code.fs.usda.gov/ericfetzer/iNAP.git>yGitRepo.git
>
>  at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:909)
>
>  at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1131)
>
>  at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1167)
>
>  at hudson.scm.SCM.checkout(SCM.java:505)
>
>  at hudson.model.AbstractProject.checkout(AbstractProject.java:1206)
>
>  at 
> hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:637)
>
>  at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
>
>  at 
> hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:509)
>
>  at hudson.model.Run.execute(Run.java:1907)
>
>  at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
>
>  at hudson.model.ResourceController.ex

Re: GitHub Clone to Different Local Directory

2021-03-29 Thread eric....@gmail.com

The only thing I can guess is that ssh is getting a question when he 
attempts to connect wanting to be added to the known_hosts file.  Wondering 
if maybe there's a way to establish this if this is indeed the issue?

On Monday, March 29, 2021 at 12:07:01 PM UTC-6 eric@gmail.com wrote:

> Thanks Mark!  I believe I'm one step closer but it's still not working.  
> I'm now getting:
>
> Caused by: hudson.plugins.git.GitException: Command "git fetch --tags 
> --progress git@myURLRepo:myUser/myProject.git 
> +refs/heads/*:refs/remotes/origin/*" returned status code 128: stdout: 
> stderr: ssh: connect to host myURLRepo port 22: Connection timed out fatal: 
> Could not read from remote repository. Please make sure you have the 
> correct access rights and the repository exists.
>
>
>
> On Monday, March 29, 2021 at 11:23:28 AM UTC-6 Mark Waite wrote:
>
>> You can't use ssh authentication with an https repository URL.  When 
>> using ssh authentication, you need to use an ssh repository URL.  When 
>> using username / password or username / token, you must use an HTTPS (or 
>> HTTP) URL.
>>
>> Mark Waite
>>
>> On Mon, Mar 29, 2021 at 10:38 AM Eric Fetzer  wrote:
>>
>>> Hmmm, thought that was going to work but it didn't.  I followed 
>>> everything to a T at:  
>>> https://mohitgoyal.co/2017/02/27/configuring-ssh-authentication-between-github-and-jenkins/
>>> The output shows:
>>>
>>> Building on master in workspace /var/lib/jenkins/workspace/Git-Checkout
>>> using credential JenkinsSSHKey
>>>  > git rev-parse --is-inside-work-tree # timeout=10
>>> Fetching changes from the remote Git repository
>>>  > git config remote.origin.url https://m 
>>> <https://code.fs.usda.gov/ericfetzer/iNAP.git>yGitRepo.git # timeout=10
>>> Cleaning workspace
>>>  > git rev-parse --verify HEAD # timeout=10
>>> No valid HEAD. Skipping the resetting
>>>  > git clean -fdx # timeout=10
>>> Fetching upstream changes from https://m 
>>> <https://code.fs.usda.gov/ericfetzer/iNAP.git>yGitRepo.git
>>>  > git --version # timeout=10
>>> using GIT_SSH to set credentials 
>>>
>>>
>>> So I see it's using the creds.  Then when it tries to do the fetch, it 
>>> says:
>>>
>>>  > git fetch --tags --progress https://m 
>>> <https://code.fs.usda.gov/ericfetzer/iNAP.git>yGitRepo.git 
>>> +refs/heads/*:refs/remotes/origin/* # timeout=10
>>> ERROR: Error fetching remote repo 'origin'
>>> hudson.plugins.git.GitException: Failed to fetch from https://m 
>>> <https://code.fs.usda.gov/ericfetzer/iNAP.git>yGitRepo.git
>>> at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:909)
>>> at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1131)
>>> at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1167)
>>> at hudson.scm.SCM.checkout(SCM.java:505)
>>> at hudson.model.AbstractProject.checkout(AbstractProject.java:1206)
>>> at 
>>> hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:637)
>>> at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
>>> at 
>>> hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:509)
>>> at hudson.model.Run.execute(Run.java:1907)
>>> at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
>>> at hudson.model.ResourceController.execute(ResourceController.java:97)
>>> at hudson.model.Executor.run(Executor.java:429)
>>> Caused by: hudson.plugins.git.GitException: Command "git fetch --tags 
>>> --progress https://m 
>>> <https://code.fs.usda.gov/ericfetzer/iNAP.git>yGitRepo.git 
>>> +refs/heads/*:refs/remotes/origin/*" returned status code 128:
>>> stdout: 
>>> stderr: remote: Password authentication is not available for Git operations.
>>> remote: You must use a personal access token or SSH key.
>>>
>>>
>>>
>>> On Mon, Mar 29, 2021 at 8:09 AM Eric Fetzer  wrote:
>>>
>>>> O, duh, I get it now.  I create the key with the jenkins user and 
>>>> add id_rsa.pub to the GitHub account for access.  I was somehow thinking I 
>>>> would need a key on the GitHub side.  Feeling kind of foolish now, lol.  
>>>> Thanks Dirk!
>>>>
>>>> On Mon, Mar 29, 2021 at 7:52 AM 'Dirk Heinrichs' via Jenkins Users <
>>>> jenkins...@googlegroups.com> wrote:
>>>>
>>>>&

Re: GitHub Clone to Different Local Directory

2021-03-29 Thread eric....@gmail.com

Thanks Mark!  I believe I'm one step closer but it's still not working.  
I'm now getting:

Caused by: hudson.plugins.git.GitException: Command "git fetch --tags 
--progress git@myURLRepo:myUser/myProject.git 
+refs/heads/*:refs/remotes/origin/*" returned status code 128: stdout: 
stderr: ssh: connect to host myURLRepo port 22: Connection timed out fatal: 
Could not read from remote repository. Please make sure you have the 
correct access rights and the repository exists.



On Monday, March 29, 2021 at 11:23:28 AM UTC-6 Mark Waite wrote:

> You can't use ssh authentication with an https repository URL.  When using 
> ssh authentication, you need to use an ssh repository URL.  When using 
> username / password or username / token, you must use an HTTPS (or HTTP) 
> URL.
>
> Mark Waite
>
> On Mon, Mar 29, 2021 at 10:38 AM Eric Fetzer  wrote:
>
>> Hmmm, thought that was going to work but it didn't.  I followed 
>> everything to a T at:  
>> https://mohitgoyal.co/2017/02/27/configuring-ssh-authentication-between-github-and-jenkins/
>> The output shows:
>>
>> Building on master in workspace /var/lib/jenkins/workspace/Git-Checkout
>> using credential JenkinsSSHKey
>>  > git rev-parse --is-inside-work-tree # timeout=10
>> Fetching changes from the remote Git repository
>>  > git config remote.origin.url https://m 
>> <https://code.fs.usda.gov/ericfetzer/iNAP.git>yGitRepo.git # timeout=10
>> Cleaning workspace
>>  > git rev-parse --verify HEAD # timeout=10
>> No valid HEAD. Skipping the resetting
>>  > git clean -fdx # timeout=10
>> Fetching upstream changes from https://m 
>> <https://code.fs.usda.gov/ericfetzer/iNAP.git>yGitRepo.git
>>  > git --version # timeout=10
>> using GIT_SSH to set credentials 
>>
>>
>> So I see it's using the creds.  Then when it tries to do the fetch, it 
>> says:
>>
>>  > git fetch --tags --progress https://m 
>> <https://code.fs.usda.gov/ericfetzer/iNAP.git>yGitRepo.git 
>> +refs/heads/*:refs/remotes/origin/* # timeout=10
>> ERROR: Error fetching remote repo 'origin'
>> hudson.plugins.git.GitException: Failed to fetch from https://m 
>> <https://code.fs.usda.gov/ericfetzer/iNAP.git>yGitRepo.git
>>  at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:909)
>>  at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1131)
>>  at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1167)
>>  at hudson.scm.SCM.checkout(SCM.java:505)
>>  at hudson.model.AbstractProject.checkout(AbstractProject.java:1206)
>>  at 
>> hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:637)
>>  at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
>>  at 
>> hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:509)
>>  at hudson.model.Run.execute(Run.java:1907)
>>  at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
>>  at hudson.model.ResourceController.execute(ResourceController.java:97)
>>  at hudson.model.Executor.run(Executor.java:429)
>> Caused by: hudson.plugins.git.GitException: Command "git fetch --tags 
>> --progress https://m 
>> <https://code.fs.usda.gov/ericfetzer/iNAP.git>yGitRepo.git 
>> +refs/heads/*:refs/remotes/origin/*" returned status code 128:
>> stdout: 
>> stderr: remote: Password authentication is not available for Git operations.
>> remote: You must use a personal access token or SSH key.
>>
>>
>>
>> On Mon, Mar 29, 2021 at 8:09 AM Eric Fetzer  wrote:
>>
>>> O, duh, I get it now.  I create the key with the jenkins user and 
>>> add id_rsa.pub to the GitHub account for access.  I was somehow thinking I 
>>> would need a key on the GitHub side.  Feeling kind of foolish now, lol.  
>>> Thanks Dirk!
>>>
>>> On Mon, Mar 29, 2021 at 7:52 AM 'Dirk Heinrichs' via Jenkins Users <
>>> jenkins...@googlegroups.com> wrote:
>>>
>>>> Am Montag, den 29.03.2021, 07:44 -0600 schrieb Eric Fetzer:
>>>>
>>>> Thanks for your reply Dirk!  I'm a unix guy and that would have been my 
>>>> first choice, however I don't have access to the GitHub OS, only my 
>>>> particular repositories.
>>>>
>>>>
>>>> I don't understand. Nobody has this kind of access. But everybody can 
>>>> add SSH keys to their GH account (using the web UI).
>>>>
>>>> Bye...
>>>>
>>>> Dirk
>>>>
>>>> -- 
>>>>
>>&

Re: GitHub Clone to Different Local Directory

Hmmm, thought that was going to work but it didn't.  I followed
everything to a T at:
https://mohitgoyal.co/2017/02/27/configuring-ssh-authentication-between-github-and-jenkins/
The output shows:

Building on master in workspace /var/lib/jenkins/workspace/Git-Checkout
using credential JenkinsSSHKey
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url https://m
<https://code.fs.usda.gov/ericfetzer/iNAP.git>yGitRepo.git #
timeout=10
Cleaning workspace
 > git rev-parse --verify HEAD # timeout=10
No valid HEAD. Skipping the resetting
 > git clean -fdx # timeout=10
Fetching upstream changes from https://m
<https://code.fs.usda.gov/ericfetzer/iNAP.git>yGitRepo.git
 > git --version # timeout=10
using GIT_SSH to set credentials


So I see it's using the creds.  Then when it tries to do the fetch, it says:

 > git fetch --tags --progress https://m
<https://code.fs.usda.gov/ericfetzer/iNAP.git>yGitRepo.git
+refs/heads/*:refs/remotes/origin/* # timeout=10
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from https://m
<https://code.fs.usda.gov/ericfetzer/iNAP.git>yGitRepo.git
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:909)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1131)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1167)
at hudson.scm.SCM.checkout(SCM.java:505)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1206)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:637)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:509)
at hudson.model.Run.execute(Run.java:1907)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:429)
Caused by: hudson.plugins.git.GitException: Command "git fetch --tags
--progress https://m
<https://code.fs.usda.gov/ericfetzer/iNAP.git>yGitRepo.git
+refs/heads/*:refs/remotes/origin/*" returned status code 128:
stdout:
stderr: remote: Password authentication is not available for Git operations.
remote: You must use a personal access token or SSH key.



On Mon, Mar 29, 2021 at 8:09 AM Eric Fetzer  wrote:

> O, duh, I get it now.  I create the key with the jenkins user and add
> id_rsa.pub to the GitHub account for access.  I was somehow thinking I
> would need a key on the GitHub side.  Feeling kind of foolish now, lol.
> Thanks Dirk!
>
> On Mon, Mar 29, 2021 at 7:52 AM 'Dirk Heinrichs' via Jenkins Users <
> jenkinsci-users@googlegroups.com> wrote:
>
>> Am Montag, den 29.03.2021, 07:44 -0600 schrieb Eric Fetzer:
>>
>> Thanks for your reply Dirk!  I'm a unix guy and that would have been my
>> first choice, however I don't have access to the GitHub OS, only my
>> particular repositories.
>>
>>
>> I don't understand. Nobody has this kind of access. But everybody can add
>> SSH keys to their GH account (using the web UI).
>>
>> Bye...
>>
>> Dirk
>>
>> --
>>
>> *Dirk Heinrichs*
>> Senior Systems Engineer, Delivery Pipeline
>> OpenText ™ Discovery | Recommind
>> *Phone*: +49 2226 15966 18
>> *Email*: dhein...@opentext.com
>> *Website*: www.recommind.de
>> Recommind GmbH, Von-Liebig-Straße 1, 53359 Rheinbach
>> Vertretungsberechtigte Geschäftsführer Gordon Davies, Madhu Ranganathan,
>> Christian Waida, Registergericht Amtsgericht Bonn, Registernummer HRB 10646
>> This e-mail may contain confidential and/or privileged information. If
>> you are not the intended recipient (or have received this e-mail in error)
>> please notify the sender immediately and destroy this e-mail. Any
>> unauthorized copying, disclosure or distribution of the material in this
>> e-mail is strictly forbidden
>> Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
>> Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
>> irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
>> vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte
>> Weitergabe dieser Mail sind nicht gestattet.
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Jenkins Users" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/jenkinsci-users/Ob42FqU-0UY/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, send an email t

Re: GitHub Clone to Different Local Directory

O, duh, I get it now.  I create the key with the jenkins user and add
id_rsa.pub to the GitHub account for access.  I was somehow thinking I
would need a key on the GitHub side.  Feeling kind of foolish now, lol.
Thanks Dirk!

On Mon, Mar 29, 2021 at 7:52 AM 'Dirk Heinrichs' via Jenkins Users <
jenkinsci-users@googlegroups.com> wrote:

> Am Montag, den 29.03.2021, 07:44 -0600 schrieb Eric Fetzer:
>
> Thanks for your reply Dirk!  I'm a unix guy and that would have been my
> first choice, however I don't have access to the GitHub OS, only my
> particular repositories.
>
>
> I don't understand. Nobody has this kind of access. But everybody can add
> SSH keys to their GH account (using the web UI).
>
> Bye...
>
> Dirk
>
> --
>
> *Dirk Heinrichs*
> Senior Systems Engineer, Delivery Pipeline
> OpenText ™ Discovery | Recommind
> *Phone*: +49 2226 15966 18
> *Email*: dhein...@opentext.com
> *Website*: www.recommind.de
> Recommind GmbH, Von-Liebig-Straße 1, 53359 Rheinbach
> Vertretungsberechtigte Geschäftsführer Gordon Davies, Madhu Ranganathan,
> Christian Waida, Registergericht Amtsgericht Bonn, Registernummer HRB 10646
> This e-mail may contain confidential and/or privileged information. If you
> are not the intended recipient (or have received this e-mail in error)
> please notify the sender immediately and destroy this e-mail. Any
> unauthorized copying, disclosure or distribution of the material in this
> e-mail is strictly forbidden
> Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
> Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
> irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
> vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte
> Weitergabe dieser Mail sind nicht gestattet.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Jenkins Users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/jenkinsci-users/Ob42FqU-0UY/unsubscribe.
> To unsubscribe from this group and all its topics, 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/7363fbe30406b54bee9b6671dc9754cbf78081c7.camel%40opentext.com
> <https://groups.google.com/d/msgid/jenkinsci-users/7363fbe30406b54bee9b6671dc9754cbf78081c7.camel%40opentext.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/CAByBicYr9i_qnSwUPmqMHR5Q-NOd4hpN455dyAZNXLRHJzEGYw%40mail.gmail.com.

Re: GitHub Clone to Different Local Directory

Thanks for your reply Dirk!  I'm a unix guy and that would have been my
first choice, however I don't have access to the GitHub OS, only my
particular repositories.

On Mon, Mar 29, 2021 at 7:40 AM 'Dirk Heinrichs' via Jenkins Users <
jenkinsci-users@googlegroups.com> wrote:

> Am Montag, den 29.03.2021, 07:22 -0600 schrieb Eric Fetzer:
>
> It was a bit painful, but at least it gets it done.  What I've implemented
> is passing the workspace to the checkout, checking out as my user to my
> user workspace (home directory), moving the files checked out to the
> jenkins workspace, using sudo to chown the folder and files to be owned by
> the jenkins user.  It's very crude but it works.  I'm going to take a look
> at Mark's option above, but at least I found something that will work...
>
>
> We've been doing GitHub checkouts from Jenkins for quite some time (until
> we moved the other way round, to a self-hosted GitLab), and didn't have any
> problems. However, we used SSH keys, which can be added to Jenkins
> Credentials and then used by the plain Git plugin in any Freestyle or
> Pipeline job.
>
> HTH...
>
> Dirk
>
> --
>
> *Dirk Heinrichs*
> Senior Systems Engineer, Delivery Pipeline
> OpenText ™ Discovery | Recommind
> *Phone*: +49 2226 15966 18
> *Email*: dhein...@opentext.com
> *Website*: www.recommind.de
> Recommind GmbH, Von-Liebig-Straße 1, 53359 Rheinbach
> Vertretungsberechtigte Geschäftsführer Gordon Davies, Madhu Ranganathan,
> Christian Waida, Registergericht Amtsgericht Bonn, Registernummer HRB 10646
> This e-mail may contain confidential and/or privileged information. If you
> are not the intended recipient (or have received this e-mail in error)
> please notify the sender immediately and destroy this e-mail. Any
> unauthorized copying, disclosure or distribution of the material in this
> e-mail is strictly forbidden
> Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
> Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
> irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
> vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte
> Weitergabe dieser Mail sind nicht gestattet.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Jenkins Users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/jenkinsci-users/Ob42FqU-0UY/unsubscribe.
> To unsubscribe from this group and all its topics, 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/1f5a073cd7dd8172fff194b00193e4b52f6b2772.camel%40opentext.com
> <https://groups.google.com/d/msgid/jenkinsci-users/1f5a073cd7dd8172fff194b00193e4b52f6b2772.camel%40opentext.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/CAByBicbPEtLAfdTx6ta6UKRyxKotYYhH1Xo1-r3DmR_A__X0pQ%40mail.gmail.com.

Re: GitHub Clone to Different Local Directory

Where I got the info to make this work, Bjorn, is from the thread that your
thread referenced:

https://stackoverflow.com/questions/56809684/git-clone-in-jenkins-with-personal-access-token-idles-forever/61104603#61104603

It was a bit painful, but at least it gets it done.  What I've implemented
is passing the workspace to the checkout, checking out as my user to my
user workspace (home directory), moving the files checked out to the
jenkins workspace, using sudo to chown the folder and files to be owned by
the jenkins user.  It's very crude but it works.  I'm going to take a look
at Mark's option above, but at least I found something that will work...

On Mon, Mar 29, 2021 at 7:14 AM eric@gmail.com 
wrote:

> Yes Bjorn, that's the thread I used to figure out how to use the access
> token.  Unfortunately, the jenkins plugin isn't smart enough to pass a
> username, it uses the username it runs as.  So my master node is running as
> the user "jenkins" so it tries to authenticate to GitHub Enterprise as
> jenkins: run as my user, which thankfully, is the same username as I have in GitHub
> Enterprise.  Smoke and mirrors...
>
> On Monday, March 29, 2021 at 3:26:47 AM UTC-6 ice...@googlemail.com wrote:
>
>> Did you try to use credentials in jenkins to store the token  instead of
>> fiddling  with token on the machine?
>> See e.g.
>> https://stackoverflow.com/questions/61105368/how-to-use-github-personal-access-token-in-jenkins
>>
>>
>> Then you could do everything in one job instead of  doing some copy-magic
>> (which would  horribly break once you start to use more nodes).
>>
>> Björn
>> eric@gmail.com schrieb am Samstag, 27. März 2021 um 04:05:44 UTC+1:
>>
>>> Thanks Mark, I'll check it out.  Has to beat the hokey workaround I
>>> worked up.  :)
>>>
>>>
>>>
>>> Sent from my T-Mobile 4G LTE Device
>>>
>>>
>>>  Original message 
>>> From: Mark Waite 
>>> Date: 3/26/21 10:49 PM (GMT-05:00)
>>> To: Jenkins Users 
>>> Subject: Re: GitHub Clone to Different Local Directory
>>>
>>> Good point.  How about the external workspace plugin from GSoC 2016?
>>> https://plugins.jenkins.io/external-workspace-manager/
>>>
>>> On Fri, Mar 26, 2021 at 8:00 PM eric.fetzer  wrote:
>>>
>>>> Thanks for the response Mark..  I'm using freestyle.  Doesn't checkout
>>>> to a subdirectory only take relative paths?
>>>>
>>>>
>>>>
>>>> Sent from my T-Mobile 4G LTE Device
>>>>
>>>>
>>>>  Original message 
>>>> From: Mark Waite 
>>>> Date: 3/26/21 6:44 PM (GMT-05:00)
>>>> To: Jenkins Users 
>>>> Subject: Re: GitHub Clone to Different Local Directory
>>>>
>>>> If you're using pipeline, change to that directory with the
>>>> dir('/users/username/projectname') { } wrapper around the checkout step;
>>>>
>>>> If you're using a freestyle job, use the git plugin extension 'checkout
>>>> to a subdirectory'
>>>> <https://plugins.jenkins.io/git/#checkout-to-a-sub-directory>
>>>>
>>>> On Fri, Mar 26, 2021 at 10:54 AM eric@gmail.com 
>>>> wrote:
>>>>
>>>>> OK, so this is kind of complex so hang with me.  We're moving from
>>>>> StarTeam to Github and I'm trying to reproduce what I'm doing in StarTeam
>>>>> with Github.  StarTeam was easy because I owned the repository machine as
>>>>> well as administrated the tool.  With Github, we're hosted.  So I'm admin
>>>>> on the project but can't create an RSA Token on the machine for easy
>>>>> access.  So I had to play around to make a personal access token work.  In
>>>>> order to make that access token work, I had to run the checkout job on a
>>>>> different node so that it was running as a user that lived in Github as
>>>>> well (access token's namesake).  So when this job gets called from the
>>>>> jenkins job, I want it to clone to the calling job's workspace
>>>>> (/opt/jenkins/workspace/).  Well since in order to
>>>>> authenticate, it lives in it's own shell, the workspace for this guy, and
>>>>> where it wants to clone to, is /home//.  All that
>>>>> for my question:  how can I specify what folder to checkout to?  I tried 
>>>>> to
>>>>> use "checkout to specific local branch" but it fails saying "is not a 
>>>>> valid
&g

Re: GitHub Clone to Different Local Directory

2021-03-29 Thread eric....@gmail.com

Yes Bjorn, that's the thread I used to figure out how to use the access 
token.  Unfortunately, the jenkins plugin isn't smart enough to pass a 
username, it uses the username it runs as.  So my master node is running as 
the user "jenkins" so it tries to authenticate to GitHub Enterprise as 
jenkins: Did you try to use credentials in jenkins to store the token  instead of  
> fiddling  with token on the machine?
> See e.g. 
> https://stackoverflow.com/questions/61105368/how-to-use-github-personal-access-token-in-jenkins
>
>
> Then you could do everything in one job instead of  doing some copy-magic 
> (which would  horribly break once you start to use more nodes).
>
> Björn
> eric@gmail.com schrieb am Samstag, 27. März 2021 um 04:05:44 UTC+1:
>
>> Thanks Mark, I'll check it out.  Has to beat the hokey workaround I 
>> worked up.  :)
>>
>>
>>
>> Sent from my T-Mobile 4G LTE Device
>>
>>
>>  Original message 
>> From: Mark Waite  
>> Date: 3/26/21 10:49 PM (GMT-05:00) 
>> To: Jenkins Users  
>> Subject: Re: GitHub Clone to Different Local Directory 
>>
>> Good point.  How about the external workspace plugin from GSoC 2016?  
>> https://plugins.jenkins.io/external-workspace-manager/
>>
>> On Fri, Mar 26, 2021 at 8:00 PM eric.fetzer  wrote:
>>
>>> Thanks for the response Mark..  I'm using freestyle.  Doesn't checkout 
>>> to a subdirectory only take relative paths?
>>>
>>>
>>>
>>> Sent from my T-Mobile 4G LTE Device
>>>
>>>
>>>  Original message 
>>> From: Mark Waite  
>>> Date: 3/26/21 6:44 PM (GMT-05:00) 
>>> To: Jenkins Users  
>>> Subject: Re: GitHub Clone to Different Local Directory 
>>>
>>> If you're using pipeline, change to that directory with the 
>>> dir('/users/username/projectname') { } wrapper around the checkout step;
>>>
>>> If you're using a freestyle job, use the git plugin extension 'checkout 
>>> to a subdirectory' 
>>> <https://plugins.jenkins.io/git/#checkout-to-a-sub-directory>
>>>
>>> On Fri, Mar 26, 2021 at 10:54 AM eric@gmail.com  
>>> wrote:
>>>
>>>> OK, so this is kind of complex so hang with me.  We're moving from 
>>>> StarTeam to Github and I'm trying to reproduce what I'm doing in StarTeam 
>>>> with Github.  StarTeam was easy because I owned the repository machine as 
>>>> well as administrated the tool.  With Github, we're hosted.  So I'm admin 
>>>> on the project but can't create an RSA Token on the machine for easy 
>>>> access.  So I had to play around to make a personal access token work.  In 
>>>> order to make that access token work, I had to run the checkout job on a 
>>>> different node so that it was running as a user that lived in Github as 
>>>> well (access token's namesake).  So when this job gets called from the 
>>>> jenkins job, I want it to clone to the calling job's workspace 
>>>> (/opt/jenkins/workspace/).  Well since in order to 
>>>> authenticate, it lives in it's own shell, the workspace for this guy, and 
>>>> where it wants to clone to, is /home//.  All that 
>>>> for my question:  how can I specify what folder to checkout to?  I tried 
>>>> to 
>>>> use "checkout to specific local branch" but it fails saying "is not a 
>>>> valid 
>>>> branch name".  Well, yeah, branch is referring to branch not folder, lol.  
>>>> In StarTeam this is easy, you just specify working folder.  Any help?  
>>>> Thanks! 
>>>>
>>>> -- 
>>>> 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/128374b8-63d5-4b8c-86bb-5f214f5e68d2n%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/jenkinsci-users/128374b8-63d5-4b8c-86bb-5f214f5e68d2n%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>> -- 
>>> You received this message because you are subscribed to a topic in the 
>>> Google Groups "Jenkins Users" group.
>>> To unsubscribe from this topic, visit 
>>> https://groups.google.c

GitHub Clone to Different Local Directory

2021-03-26 Thread eric....@gmail.com

OK, so this is kind of complex so hang with me. We're moving from StarTeam
to Github and I'm trying to reproduce what I'm doing in StarTeam with
Github. StarTeam was easy because I owned the repository machine as well
as administrated the tool. With Github, we're hosted. So I'm admin on the
project but can't create an RSA Token on the machine for easy access. So I
had to play around to make a personal access token work. In order to make
that access token work, I had to run the checkout job on a different node
so that it was running as a user that lived in Github as well (access
token's namesake). So when this job gets called from the jenkins job, I
want it to clone to the calling job's workspace
(/opt/jenkins/workspace/). Well since in order to
authenticate, it lives in it's own shell, the workspace for this guy, and
where it wants to clone to, is /home//. All that
for my question: how can I specify what folder to checkout to? I tried to
use "checkout to specific local branch" but it fails saying "is not a valid
branch name". Well, yeah, branch is referring to branch not folder, lol.
In StarTeam this is easy, you just specify working folder. Any help?
Thanks!

--
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/128374b8-63d5-4b8c-86bb-5f214f5e68d2n%40googlegroups.com.

Jenkins 2.277.1 Issue?

2021-03-22 Thread eric....@gmail.com

Hi!  Last week we took 2.277.1 when patching.  I didn't see any issues 
until this morning when I tried to log on and got 403 No valid crumb was 
included in the request.  I restarted the server a few times trying to fix 
it but never could get logged in.  I did some research and found a thread 
telling me to make a global security setting change to proxy compatibility 
(even though I'm not proxied), but couldn't get to global security to try 
that.  So I backed it out to 2.263.4, where we were before.  It's working 
again, but I'm guessing the same thing will happen next time we apply 
patches.  Is there a change with 277 that will make me have to change some 
setting or another?  Thanks!

-- 
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/442af655-e31b-42ef-a083-519e1d5c1c20n%40googlegroups.com.

Re: How can i execute shell scripts from Jenkins ?

2021-03-05 Thread Eric Pyle

Typically such problems are because the shell script is tested under a
different user account than the one used by Jenkins. This may result in
commands not being found due to different $PATH settings or permission
errors because of different user permissions. It's hard to be more
specific without knowing more about the errors you are seeing.

Eric

On 3/5/2021 12:03 PM, Gil Jensen wrote:
can you tell me why Jenkins would get a different result from the
shell scripts alone?

On Wednesday, March 18, 2020 at 12:25:34 PM UTC-4 Siddhesh Malpani wrote:

Mohan,

Yes of course you can do that. Simply ad the shell script file
name in the 'Execute Shell' step as explained by Derek. Remember
that you've give the path of your file relative to your workspace
directory. Suppose your worskapce dir is 'build-dev' and the shell
script 'patch.sh' is located in a dir 'scripts' under the
workspace. Then you'll have to give it's path as:

./scripts/patch.sh

And you're good to go.

Cheers,
Siddhesh

--
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
<mailto:jenkinsci-users+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-users/c6d9f1a7-ac7a-4e88-9267-ee8ec1386223n%40googlegroups.com
<https://groups.google.com/d/msgid/jenkinsci-users/c6d9f1a7-ac7a-4e88-9267-ee8ec1386223n%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/ddb470f6-4eac-0cbe-2909-117690147526%40cd-adapco.com.

Re: Security Vulnerability on my Jenkins Server

2021-02-10 Thread Eric Fetzer

Thanks, guess we'll have to wait.  It's not based on what we do, it's just
a security scan software.  It's not like anyone can get to it anyway, it's
inside the wall, but it is what it is.  This one will have to become a
POAM.  Do you have any clue when the fix is coming up?  Again, THANKS for
all your help!

On Wed, Feb 10, 2021 at 1:25 PM kuisathaverat 
wrote:

> I’ve re read your first message, you as for “Jenkins CLI over SSH”, there
> you cannot do anything until we replace the ssh-module. The module will
> support those MACs and is not posible to disable them. However, I doubt
> that the Jenkins CLI use those MACs , and you can always use HTTPS.
>
> El El mié, 10 feb 2021 a las 18:28, Eric Fetzer 
> escribió:
>
>> My MACs line says:
>>
>> MACs hmac-ripemd160,hmac-sha2-256,hmac-sha2-512,
>> hmac-ripemd...@openssh.com
>>
>> I believe this is hardened, isn't it?
>>
>> Thanks,
>> Eric
>>
>> On Wed, Feb 10, 2021 at 9:40 AM kuisathaverat 
>> wrote:
>>
>>> hmac-* are Message authentication code algorithms (MACs), so you have to
>>> configure your Message authentication code algorithms (MACs) supported, for
>>> example
>>>
>>> MACs hmac-sha2-256,hmac-sha2-512
>>>
>>> see
>>> https://www.ssh.com/ssh/sshd_config/#common-configuration-changes-for-the-enterprise
>>>
>>> El mié, 10 feb 2021 a las 17:24, Eric Fetzer ()
>>> escribió:
>>>
>>>> Hmmm, I already hardened by that link:
>>>> https://www.ssh.com/ssh/sshd_config
>>>>
>>>> My /etc/ssh/sshd_config has:
>>>>
>>>> Ciphers aes128-ctr,aes192-ctr,aes256-ctr
>>>>
>>>> This is still showing up on my security scan though.  Am I missing
>>>> something?
>>>>
>>>> Thanks,
>>>> Eric
>>>>
>>>> On Tue, Feb 9, 2021 at 12:23 PM kuisathaverat 
>>>> wrote:
>>>>
>>>>> There is work in progress to bump the version of the library and
>>>>> convert the sshd-module in a plugin to resolve this kind of issues 
>>>>> quickly.
>>>>> For the moment you can configure your sshd servers on the Agents side to 
>>>>> do
>>>>> not allow weak ciphers, see https://www.ssh.com/ssh/sshd_config.
>>>>>
>>>>> https://github.com/jenkinsci/sshd-module/pull/37
>>>>> https://github.com/jenkinsci/sshd-module/pull/38
>>>>>
>>>>>
>>>>> El mar, 9 feb 2021 a las 17:19, eric@gmail.com (<
>>>>> eric.fet...@gmail.com>) escribió:
>>>>>
>>>>>> I'm sorry, I just saw the last comment on here and, once again, this
>>>>>> showed up on our vulnerability report.  I don't get exactly what I need 
>>>>>> to
>>>>>> do in order to fix this.  Can someone lay it out for me please?  Thanks -
>>>>>> Eric
>>>>>>
>>>>>> On Wednesday, August 26, 2020 at 12:39:40 PM UTC-6
>>>>>> kuisat...@gmail.com wrote:
>>>>>>
>>>>>>> I was wrong you cannot configure the ciphers for the ssh server on
>>>>>>> the Java security files. The SSH server on Jenkins uses the
>>>>>>> https://github.com/apache/mina-sshd , IIRC the Jenkins
>>>>>>> implementation of the ssh server not read the sshd_config files so it is
>>>>>>> not posible to configure the ssh server. Apache mina has deprecated and
>>>>>>> disable those algorithms on 2.6.0
>>>>>>> https://issues.apache.org/jira/browse/SSHD-1004, the sshd-module
>>>>>>> and CLI are using 1.7.0
>>>>>>> https://github.com/jenkinsci/sshd-module/blob/master/pom.xml#L42
>>>>>>>  and
>>>>>>> https://github.com/jenkinsci/jenkins/blob/master/cli/pom.xml#L77 So
>>>>>>> I guess both should bump the dependency to remove support for weak
>>>>>>> algorithms
>>>>>>>
>>>>>>>
>>>>>>> El miércoles, 26 de agosto de 2020 a las 16:06:22 UTC+2,
>>>>>>> eric@gmail.com escribió:
>>>>>>>
>>>>>>>> I think I found the solution to this:
>>>>>>>>
>>>>>>>>
>>>>>>>> https://www.thegeekdiary.com/how-to-disable-md5-based-hmac-algorithms-for-ssh/
>>>>>>>>
>>>>>&g

Re: Security Vulnerability on my Jenkins Server

2021-02-10 Thread Eric Fetzer

My MACs line says:

MACs hmac-ripemd160,hmac-sha2-256,hmac-sha2-512,hmac-ripemd...@openssh.com

I believe this is hardened, isn't it?

Thanks,
Eric

On Wed, Feb 10, 2021 at 9:40 AM kuisathaverat 
wrote:

> hmac-* are Message authentication code algorithms (MACs), so you have to
> configure your Message authentication code algorithms (MACs) supported, for
> example
>
> MACs hmac-sha2-256,hmac-sha2-512
>
> see
> https://www.ssh.com/ssh/sshd_config/#common-configuration-changes-for-the-enterprise
>
> El mié, 10 feb 2021 a las 17:24, Eric Fetzer ()
> escribió:
>
>> Hmmm, I already hardened by that link:
>> https://www.ssh.com/ssh/sshd_config
>>
>> My /etc/ssh/sshd_config has:
>>
>> Ciphers aes128-ctr,aes192-ctr,aes256-ctr
>>
>> This is still showing up on my security scan though.  Am I missing
>> something?
>>
>> Thanks,
>> Eric
>>
>> On Tue, Feb 9, 2021 at 12:23 PM kuisathaverat 
>> wrote:
>>
>>> There is work in progress to bump the version of the library and convert
>>> the sshd-module in a plugin to resolve this kind of issues quickly. For the
>>> moment you can configure your sshd servers on the Agents side to do not
>>> allow weak ciphers, see https://www.ssh.com/ssh/sshd_config.
>>>
>>> https://github.com/jenkinsci/sshd-module/pull/37
>>> https://github.com/jenkinsci/sshd-module/pull/38
>>>
>>>
>>> El mar, 9 feb 2021 a las 17:19, eric@gmail.com (<
>>> eric.fet...@gmail.com>) escribió:
>>>
>>>> I'm sorry, I just saw the last comment on here and, once again, this
>>>> showed up on our vulnerability report.  I don't get exactly what I need to
>>>> do in order to fix this.  Can someone lay it out for me please?  Thanks -
>>>> Eric
>>>>
>>>> On Wednesday, August 26, 2020 at 12:39:40 PM UTC-6 kuisat...@gmail.com
>>>> wrote:
>>>>
>>>>> I was wrong you cannot configure the ciphers for the ssh server on the
>>>>> Java security files. The SSH server on Jenkins uses the
>>>>> https://github.com/apache/mina-sshd , IIRC the Jenkins implementation
>>>>> of the ssh server not read the sshd_config files so it is not posible to
>>>>> configure the ssh server. Apache mina has deprecated and disable those
>>>>> algorithms on 2.6.0 https://issues.apache.org/jira/browse/SSHD-1004,
>>>>> the sshd-module and CLI are using 1.7.0
>>>>> https://github.com/jenkinsci/sshd-module/blob/master/pom.xml#L42 and
>>>>> https://github.com/jenkinsci/jenkins/blob/master/cli/pom.xml#L77 So I
>>>>> guess both should bump the dependency to remove support for weak 
>>>>> algorithms
>>>>>
>>>>>
>>>>> El miércoles, 26 de agosto de 2020 a las 16:06:22 UTC+2,
>>>>> eric@gmail.com escribió:
>>>>>
>>>>>> I think I found the solution to this:
>>>>>>
>>>>>>
>>>>>> https://www.thegeekdiary.com/how-to-disable-md5-based-hmac-algorithms-for-ssh/
>>>>>>
>>>>>>
>>>>>> On Tuesday, August 25, 2020 at 1:59:49 PM UTC-6 eric@gmail.com
>>>>>> wrote:
>>>>>>
>>>>>>> I'm confused.  It doesn't look like the ciphers the vulnerability is
>>>>>>> citing are allowed in the java.security file on this system.  We're 
>>>>>>> getting
>>>>>>> flagged for:
>>>>>>>
>>>>>>>  hmac-md5
>>>>>>>   hmac-md5-96
>>>>>>>   hmac-sha1-96
>>>>>>>
>>>>>>> Settings are:
>>>>>>>
>>>>>>> jdk.tls.disabledAlgorithms=SSLv3, RC4, DES, MD5withRSA, DH keySize <
>>>>>>> 1024, \
>>>>>>> EC keySize < 224, 3DES_EDE_CBC, anon, NULL
>>>>>>>
>>>>>>> Am I missing this, not a java security expert by any means...
>>>>>>> Thanks!
>>>>>>> On Monday, August 24, 2020 at 11:09:43 AM UTC-6 kuisat...@gmail.com
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Yes, configuring the ciphers accepted by your JDK edit the
>>>>>>>> file lib\security\java.security (the path will vary based on your Java
>>>>>>>> version)
>>>>>>>>
>>>>>>>> El lunes, 24 de agos

Re: Security Vulnerability on my Jenkins Server

2021-02-10 Thread Eric Fetzer

Hmmm, I already hardened by that link:  https://www.ssh.com/ssh/sshd_config

My /etc/ssh/sshd_config has:

Ciphers aes128-ctr,aes192-ctr,aes256-ctr

This is still showing up on my security scan though.  Am I missing
something?

Thanks,
Eric

On Tue, Feb 9, 2021 at 12:23 PM kuisathaverat 
wrote:

> There is work in progress to bump the version of the library and convert
> the sshd-module in a plugin to resolve this kind of issues quickly. For the
> moment you can configure your sshd servers on the Agents side to do not
> allow weak ciphers, see https://www.ssh.com/ssh/sshd_config.
>
> https://github.com/jenkinsci/sshd-module/pull/37
> https://github.com/jenkinsci/sshd-module/pull/38
>
>
> El mar, 9 feb 2021 a las 17:19, eric@gmail.com ()
> escribió:
>
>> I'm sorry, I just saw the last comment on here and, once again, this
>> showed up on our vulnerability report.  I don't get exactly what I need to
>> do in order to fix this.  Can someone lay it out for me please?  Thanks -
>> Eric
>>
>> On Wednesday, August 26, 2020 at 12:39:40 PM UTC-6 kuisat...@gmail.com
>> wrote:
>>
>>> I was wrong you cannot configure the ciphers for the ssh server on the
>>> Java security files. The SSH server on Jenkins uses the
>>> https://github.com/apache/mina-sshd , IIRC the Jenkins implementation
>>> of the ssh server not read the sshd_config files so it is not posible to
>>> configure the ssh server. Apache mina has deprecated and disable those
>>> algorithms on 2.6.0 https://issues.apache.org/jira/browse/SSHD-1004,
>>> the sshd-module and CLI are using 1.7.0
>>> https://github.com/jenkinsci/sshd-module/blob/master/pom.xml#L42 and
>>> https://github.com/jenkinsci/jenkins/blob/master/cli/pom.xml#L77 So I
>>> guess both should bump the dependency to remove support for weak algorithms
>>>
>>>
>>> El miércoles, 26 de agosto de 2020 a las 16:06:22 UTC+2,
>>> eric@gmail.com escribió:
>>>
>>>> I think I found the solution to this:
>>>>
>>>>
>>>> https://www.thegeekdiary.com/how-to-disable-md5-based-hmac-algorithms-for-ssh/
>>>>
>>>>
>>>> On Tuesday, August 25, 2020 at 1:59:49 PM UTC-6 eric@gmail.com
>>>> wrote:
>>>>
>>>>> I'm confused.  It doesn't look like the ciphers the vulnerability is
>>>>> citing are allowed in the java.security file on this system.  We're 
>>>>> getting
>>>>> flagged for:
>>>>>
>>>>>  hmac-md5
>>>>>   hmac-md5-96
>>>>>   hmac-sha1-96
>>>>>
>>>>> Settings are:
>>>>>
>>>>> jdk.tls.disabledAlgorithms=SSLv3, RC4, DES, MD5withRSA, DH keySize <
>>>>> 1024, \
>>>>> EC keySize < 224, 3DES_EDE_CBC, anon, NULL
>>>>>
>>>>> Am I missing this, not a java security expert by any means...  Thanks!
>>>>> On Monday, August 24, 2020 at 11:09:43 AM UTC-6 kuisat...@gmail.com
>>>>> wrote:
>>>>>
>>>>>> Yes, configuring the ciphers accepted by your JDK edit the
>>>>>> file lib\security\java.security (the path will vary based on your Java
>>>>>> version)
>>>>>>
>>>>>> El lunes, 24 de agosto de 2020 a las 16:48:22 UTC+2,
>>>>>> eric@gmail.com escribió:
>>>>>>
>>>>>>> Hi all!  I'm getting hit by my secuity team for a vulnerability for
>>>>>>> the Jenkins CLI via ssh allowing the following weak ciphers:
>>>>>>>
>>>>>>>   hmac-md5
>>>>>>>   hmac-md5-96
>>>>>>>   hmac-sha1-96
>>>>>>>
>>>>>>> Is there a way to configure ciphers accepted for the Jenkins CLI?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Eric
>>>>>>>
>>>>>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Jenkins Users" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/jenkinsci-users/f84HCfhF4vY/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, 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/07db750a-9c00-40ee-bc68-0a2b051c48fdn%40googlegroups.com
>> <https://groups.google.com/d/msgid/jenk

Re: Security Vulnerability on my Jenkins Server

2021-02-09 Thread eric....@gmail.com

I'm sorry, I just saw the last comment on here and, once again, this showed 
up on our vulnerability report.  I don't get exactly what I need to do in 
order to fix this.  Can someone lay it out for me please?  Thanks - Eric

On Wednesday, August 26, 2020 at 12:39:40 PM UTC-6 kuisat...@gmail.com 
wrote:

> I was wrong you cannot configure the ciphers for the ssh server on the 
> Java security files. The SSH server on Jenkins uses the 
> https://github.com/apache/mina-sshd , IIRC the Jenkins implementation of 
> the ssh server not read the sshd_config files so it is not posible to 
> configure the ssh server. Apache mina has deprecated and disable those 
> algorithms on 2.6.0 https://issues.apache.org/jira/browse/SSHD-1004, the 
> sshd-module and CLI are using 1.7.0 
> https://github.com/jenkinsci/sshd-module/blob/master/pom.xml#L42 and 
> https://github.com/jenkinsci/jenkins/blob/master/cli/pom.xml#L77 So I 
> guess both should bump the dependency to remove support for weak algorithms 
>
>
> El miércoles, 26 de agosto de 2020 a las 16:06:22 UTC+2, 
> eric@gmail.com escribió:
>
>> I think I found the solution to this:
>>
>>
>> https://www.thegeekdiary.com/how-to-disable-md5-based-hmac-algorithms-for-ssh/
>>   
>>
>> On Tuesday, August 25, 2020 at 1:59:49 PM UTC-6 eric@gmail.com wrote:
>>
>>> I'm confused.  It doesn't look like the ciphers the vulnerability is 
>>> citing are allowed in the java.security file on this system.  We're getting 
>>> flagged for:
>>>
>>>  hmac-md5
>>>   hmac-md5-96
>>>   hmac-sha1-96
>>>
>>> Settings are:
>>>
>>> jdk.tls.disabledAlgorithms=SSLv3, RC4, DES, MD5withRSA, DH keySize < 
>>> 1024, \
>>> EC keySize < 224, 3DES_EDE_CBC, anon, NULL
>>>
>>> Am I missing this, not a java security expert by any means...  Thanks!
>>> On Monday, August 24, 2020 at 11:09:43 AM UTC-6 kuisat...@gmail.com 
>>> wrote:
>>>
>>>> Yes, configuring the ciphers accepted by your JDK edit the 
>>>> file lib\security\java.security (the path will vary based on your Java 
>>>> version)
>>>>
>>>> El lunes, 24 de agosto de 2020 a las 16:48:22 UTC+2, eric@gmail.com 
>>>> escribió:
>>>>
>>>>> Hi all!  I'm getting hit by my secuity team for a vulnerability for 
>>>>> the Jenkins CLI via ssh allowing the following weak ciphers:
>>>>>
>>>>>   hmac-md5
>>>>>   hmac-md5-96
>>>>>   hmac-sha1-96
>>>>>
>>>>> Is there a way to configure ciphers accepted for the Jenkins CLI?
>>>>>
>>>>> Thanks,
>>>>> Eric
>>>>>
>>>>

-- 
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/07db750a-9c00-40ee-bc68-0a2b051c48fdn%40googlegroups.com.

Re: Doxygen integration with Jenkins

2020-11-05 Thread Eric Pyle

Hi Arjuman,

In your screenshot of the Doxygen Installations configuration, it shows
that the configured path to Doxygen does not exist on your Jenkins
master. It appears that you have two Jenkins installations (two
masters), and one of them has Doxygen.exe installed at C:\Program
Files\doxygen\bin, but the other does not.

Regards,
Eric

On 11/5/2020 12:46 AM, Arjuman Banu wrote:

Hi,

I am integrating Doxygen tool with Jenkins.

Given .exe path in Jenkins global tool configurations.

While configuring a project, build->generating documentation using
doxygen,

Doxygen Installations:
Doxyfile Path: (given configuration file path)

When I run, it is generating the documentation.

When I do the same in other Jenkins server, getting error as
Started by user _Akumalla Arjuman Banu
<http://10.1.1.222:8080/user/akumallabanu>_ Running as SYSTEM Building
in workspace D:\Projects\workspace\Aesculap_GN740_Demo1 Starting
Doxygen documentation generation FATAL: The path to Doxygen executable
doesn't exist : "C:\Program Files\doxygen\bin\doxygen.exe" Build step
'Generate documentation using Doxygen' marked build as failure
Finished: FAILURE.

But the same process is working on one system.

I will share the images, please guide me.Capture5 (1).pngCapture8
(1).pngCapture6 (1).pngCapture7 (1).png

Regards,
Arjuman
--
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
<mailto:jenkinsci-users+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-users/ee9060df-eef9-45ae-a395-68790157e7d2n%40googlegroups.com
<https://groups.google.com/d/msgid/jenkinsci-users/ee9060df-eef9-45ae-a395-68790157e7d2n%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/abdd6a6b-3e4c-dfcb-7dba-86175a3353ff%40cd-adapco.com.

Re: How to get command versions supported by Pipeline

2020-10-13 Thread Eric Pyle

This message is telling you that your "bat" step does not know where to 
find the "dotnet" command. If you give the full path it should succeed.


On 10/13/2020 9:33 AM, Ven H wrote:

In my Jenkinsfile, I am using the following command

bat "dotnet restore"

I have .NET Core SDK installed in the Jenkins Slave, but still the job 
throws an error saying "'dotnet' is not recognized as an internal or 
external command,

operable program or batch file."

So, how to know which version of .NET Core SDK or for that matter any 
command (say MSBuild) is supported by the "bat" step of Jenkinsfile.


Please help.

Regards,
Venkatesh
--
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/CAPp28eqvJyaz_C2G%2Bs2v1V7txGb_tAJoprA6qmUAMRh4Vf%3DQsA%40mail.gmail.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/a4c84b6c-57fb-0547-d30d-12c6246c5242%40cd-adapco.com.

Vulnerability in JQuery on Jenkins

2020-08-26 Thread eric....@gmail.com

Hi All,

Just got gigged by our security team for a vulnerability in Jenkins with 
the version of JQuery installed.  How do I go about updating the version of 
JQuery Jenkins runs?  Here's the specifics of the vulnerability:

Plugin Output: 
  URL   : http://myMachine:8081/js/jquery-1.11.1.min.js
  Installed version : 1.11.1
  Fixed version : 3.5.0

I'm running version 2.235.5 of Jenkins.

Thanks,
Eric

-- 
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/13c921b1-02f4-4f00-a474-266fe766ced0n%40googlegroups.com.

Re: Security Vulnerability on my Jenkins Server

2020-08-25 Thread eric....@gmail.com

I'm confused.  It doesn't look like the ciphers the vulnerability is citing 
are allowed in the java.security file on this system.  We're getting 
flagged for:

 hmac-md5
  hmac-md5-96
  hmac-sha1-96

Settings are:

jdk.tls.disabledAlgorithms=SSLv3, RC4, DES, MD5withRSA, DH keySize < 1024, \
EC keySize < 224, 3DES_EDE_CBC, anon, NULL

Am I missing this, not a java security expert by any means...  Thanks!
On Monday, August 24, 2020 at 11:09:43 AM UTC-6 kuisat...@gmail.com wrote:

> Yes, configuring the ciphers accepted by your JDK edit the 
> file lib\security\java.security (the path will vary based on your Java 
> version)
>
> El lunes, 24 de agosto de 2020 a las 16:48:22 UTC+2, eric@gmail.com 
> escribió:
>
>> Hi all!  I'm getting hit by my secuity team for a vulnerability for the 
>> Jenkins CLI via ssh allowing the following weak ciphers:
>>
>>   hmac-md5
>>   hmac-md5-96
>>   hmac-sha1-96
>>
>> Is there a way to configure ciphers accepted for the Jenkins CLI?
>>
>> Thanks,
>> Eric
>>
>

-- 
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/cd72f7b2-5aa3-4e6e-96da-579cb50b43e3n%40googlegroups.com.

Security Vulnerability on my Jenkins Server

2020-08-24 Thread eric....@gmail.com

Hi all!  I'm getting hit by my secuity team for a vulnerability for the 
Jenkins CLI via ssh allowing the following weak ciphers:

  hmac-md5
  hmac-md5-96
  hmac-sha1-96

Is there a way to configure ciphers accepted for the Jenkins CLI?

Thanks,
Eric

-- 
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/392ef479-9516-4f17-9373-8054ef703bb5n%40googlegroups.com.

Re: Robot Framework test run from Jenkins. - No module named robot

2020-07-24 Thread Eric Pyle

I wonder if this is because AppData is a hidden folder, and/or not 
accessible to the user running Jenkins. Can you try a directory listing 
of that Scripts directory in a Jenkins job batch command?


Eric

On 7/22/2020 11:50 AM, Robert Szabo wrote:

Hi,

Jenkins cant run my Robot Framework test cases.

I run this job in Execute Windows batch command

cd C:\work\robot\Es1P\
set 
PYTHONPATH=C:\Users\robert.szabo\AppData\Roaming\Python\Python37\Scripts

echo %PYTHONPATH%
python.exe -m robot C:\work\robot\Es1P
echo Completed


Jenkins run of it always fails, console output is this:

-
Console Output
Started by useradmin  <http://localhost:8080/user/admin>
Running as SYSTEM
Building in workspace C:\Program Files (x86)\Jenkins\workspace\r1
[r1] $ cmd /c call C:\windows\TEMP\jenkins1877465942945470142.bat

C:\Program Files (x86)\Jenkins\workspace\r1>cd C:\work\robot\Es1P\

C:\work\robot\Es1P>set 
PYTHONPATH=C:\Users\robert.szabo\AppData\Roaming\Python\Python37\Scripts

C:\work\robot\Es1P>echo 
C:\Users\robert.szabo\AppData\Roaming\Python\Python37\Scripts
C:\Users\robert.szabo\AppData\Roaming\Python\Python37\Scripts

C:\work\robot\Es1P>python.exe -m robot C:\work\robot\Es1P
C:\Program Files\Python37\python.exe: No module named robot

C:\work\robot\Es1P>echo Completed
Completed

C:\work\robot\Es1P>exit 1
Build step 'Execute Windows batch command' marked build as failure
Finished: FAILURE
-
checking robot location in Powershell
(get-command robot.exe).Path
PS C:\work\robot\Es1P> (get-command robot.exe).Path 
C:\Users\robert.szabo\AppData\Roaming\Python\Python37\Scripts\robot.exe

So i think PYTHONPATH should work, but seems not.
--
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 
<mailto:jenkinsci-users+unsubscr...@googlegroups.com>.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/63d9fc16-cdd1-4db1-bb3e-cbb5908ddb83o%40googlegroups.com 
<https://groups.google.com/d/msgid/jenkinsci-users/63d9fc16-cdd1-4db1-bb3e-cbb5908ddb83o%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/986c8bfa-07c4-7660-9d7f-db553d713d90%40cd-adapco.com.

Re: Parametrized build for E2E testing in different environments

2020-06-04 Thread Eric Pyle

Go to the Build section of the job config, and add a build step of type
"Use builders from another project". Your job will now use all the Build
steps configured in the other job you specify there.

The configuration you added would use the "Build Environment" settings
from the job you specified, which may also be useful, but I think you
were looking for build steps.

Regarding Multiple SCM plugin, that is indeed deprecated, and I don't
recommend using it directly.

-Eric

On 6/4/2020 12:30 PM, Alberto Scotto wrote:

I see thanks!

I never really had the chance to look into pipelines, but now the time
might have come.

Even Multiple SCM is stating <https://plugins.jenkins.io/multiple-scms/>:

Deprecated: Users should migrate to
https://wiki.jenkins-ci.org/display/JENKINS/Pipeline+Plugin

Anyway, back to the template plugin,
after installing the Multiple SCMs plugin now I can see the checkbox
"Use build environment from another project", but I still can't seem
to get it to work.

In the jobs console output I have:

Started by user admin
Running as SYSTEM
Building in workspace C:\Program Files (x86)\Jenkins\workspace\asd
[TemplateProject] Starting pre-checkout from: E2E Template
[TemplateProject] Successfully performed pre-checkout from: 'E2E
Template'
Cloning the remote Git repository
[..]
[TemplateProject] Getting environment from: E2E Template
[TemplateProject] Successfully setup environment from: 'E2E Template'
Finished: SUCCESS

Any idea what could be wrong?

Il giorno giovedì 4 giugno 2020 17:53:39 UTC+2, Eric Pyle ha scritto:

Using Pipeline you would take a different approach, like having a
common script in source control that all the jobs could use to
accomplish the common task.

I'm surprised that the Template plugin is not working for you,
however. We're not at the very latest LTS but at 2.204.5, and it
works fine for us. We use it in hundreds of jobs. A quick look at
your stack trace suggests you are missing the Multiple SCM plugin
as a dependency.

Regards,
Eric

On 6/4/2020 11:42 AM, Alberto Scotto wrote:

Thanks Eric, I appreciate it.
Unfortunately the template plugin seems not be up-to-date.
I've just opened a new issue on JIRA, but I'm not really hopeful..
https://issues.jenkins-ci.org/browse/JENKINS-62568
<https://issues.jenkins-ci.org/browse/JENKINS-62568>

I noticed there seems to be a couple more template plugins, I
might give them a try.

Assuming you are using a Freestyle project (not Pipeline)

What if we were to use Pipeline? Would it make things easier?

Thank you

Alberto

Il giorno venerdì 29 maggio 2020 00:17:42 UTC+2, Eric Pyle ha
scritto:

Assuming you are using a Freestyle project (not Pipeline) you
could use the Template Project Plugin
https://plugins.jenkins.io/template-project/
<https://plugins.jenkins.io/template-project/>. You create a
template job which contains all the common functionality, and
then in the separate job for each environment you add the
template job as a build step (Use builders from another project).

-Eric

On 5/28/2020 7:39 AM, Alberto Scotto wrote:

Hi,

Long story short: is it possible to have a job which builds
another job, in particular a parametrized one?

We have a Cucumber+Selenium project which runs E2E tests
against our different test environments.
Something pretty standard.

For this kind of job, the parametrized build seems to be the
best idea.
Otherwise we would have to create one job for each test
environment. duplicating the job configuration.
Then it would be a nightmare to keep all the job
configurations in sync, in case we need to change something.

But there's a problem with the build history.
I want to see a separate build history for each environment.
It doesn't make sense to have an interleaved history. It
would be messy.

So an easy solution could be to have a job which calls the
parametrized job passing the actual value for the environment.
This way the build histories would be kept separate, and at
the same time we would also get to avoid duplication.

Is that possible? Or do you have any other idea/solution?

Thank you very much.

Alberto
--
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/5f64c8d1-db57-4002-9aa7-5e574638b76c%40googlegroups.com

Re: Parametrized build for E2E testing in different environments

2020-06-04 Thread Eric Pyle

Using Pipeline you would take a different approach, like having a common
script in source control that all the jobs could use to accomplish the
common task.

I'm surprised that the Template plugin is not working for you, however.
We're not at the very latest LTS but at 2.204.5, and it works fine for
us. We use it in hundreds of jobs. A quick look at your stack trace
suggests you are missing the Multiple SCM plugin as a dependency.

Regards,
Eric

On 6/4/2020 11:42 AM, Alberto Scotto wrote:

I noticed there seems to be a couple more template plugins, I might
give them a try.

Assuming you are using a Freestyle project (not Pipeline)

What if we were to use Pipeline? Would it make things easier?

Thank you

Alberto

Il giorno venerdì 29 maggio 2020 00:17:42 UTC+2, Eric Pyle ha scritto:

Assuming you are using a Freestyle project (not Pipeline) you
could use the Template Project Plugin
https://plugins.jenkins.io/template-project/
<https://plugins.jenkins.io/template-project/>. You create a
template job which contains all the common functionality, and then
in the separate job for each environment you add the template job
as a build step (Use builders from another project).

-Eric

On 5/28/2020 7:39 AM, Alberto Scotto wrote:

Hi,

Long story short: is it possible to have a job which builds
another job, in particular a parametrized one?

We have a Cucumber+Selenium project which runs E2E tests against
our different test environments.
Something pretty standard.

For this kind of job, the parametrized build seems to be the best
idea.
Otherwise we would have to create one job for each test
environment. duplicating the job configuration.
Then it would be a nightmare to keep all the job configurations
in sync, in case we need to change something.

But there's a problem with the build history.
I want to see a separate build history for each environment.
It doesn't make sense to have an interleaved history. It would be
messy.

So an easy solution could be to have a job which calls the
parametrized job passing the actual value for the environment.
This way the build histories would be kept separate, and at the
same time we would also get to avoid duplication.

Is that possible? Or do you have any other idea/solution?

Thank you very much.

Alberto
--
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/5f64c8d1-db57-4002-9aa7-5e574638b76c%40googlegroups.com

<https://groups.google.com/d/msgid/jenkinsci-users/5f64c8d1-db57-4002-9aa7-5e574638b76c%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
<mailto:jenkinsci-users+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-users/b75ccb32-b748-4af1-8331-ace29a2c6074%40googlegroups.com
<https://groups.google.com/d/msgid/jenkinsci-users/b75ccb32-b748-4af1-8331-ace29a2c6074%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/cbde6bf8-45e1-8fa0-1b73-dabf63bd6fc0%40cd-adapco.com.

Re: Parametrized build for E2E testing in different environments

2020-05-28 Thread Eric Pyle

Assuming you are using a Freestyle project (not Pipeline) you could use
the Template Project Plugin
https://plugins.jenkins.io/template-project/. You create a template job
which contains all the common functionality, and then in the separate
job for each environment you add the template job as a build step (Use
builders from another project).

-Eric

On 5/28/2020 7:39 AM, Alberto Scotto wrote:

Hi,

Long story short: is it possible to have a job which builds another
job, in particular a parametrized one?

We have a Cucumber+Selenium project which runs E2E tests against our
different test environments.

Something pretty standard.

For this kind of job, the parametrized build seems to be the best idea.
Otherwise we would have to create one job for each test environment.
duplicating the job configuration.
Then it would be a nightmare to keep all the job configurations in
sync, in case we need to change something.

But there's a problem with the build history.
I want to see a separate build history for each environment.
It doesn't make sense to have an interleaved history. It would be messy.

So an easy solution could be to have a job which calls the
parametrized job passing the actual value for the environment.
This way the build histories would be kept separate, and at the same
time we would also get to avoid duplication.

Is that possible? Or do you have any other idea/solution?

Thank you very much.

Alberto
--
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
<mailto:jenkinsci-users+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-users/5f64c8d1-db57-4002-9aa7-5e574638b76c%40googlegroups.com
<https://groups.google.com/d/msgid/jenkinsci-users/5f64c8d1-db57-4002-9aa7-5e574638b76c%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/0bca5d47-881f-4b61-1078-fc854c63a1dd%40cd-adapco.com.

Re: Process the powershell result on the jenkins server

2020-02-26 Thread Eric Pyle

Extending on Slide's idea, you can write the result to a file in the
workspace and save that file as a build artifact. Then in the downstream
job that runs on the master you can retrieve the artifact from the
upstream job (copy artifacts from other job) and read the value in your
bash script. Or similarly, if you write the file in the upstream job as
a properties file "VARNAME=$value" then you can use that file to set a
parameter to pass to the downstream job (parameters from properties file).

Eric

On 2/26/2020 8:26 AM, Michael Renner wrote:

Moin,

I am new to this group but I have been using jenkins for many years.
Now I have a request that I don't know what to do next. My jenkins
server (Linux) connect to an agent on a Windows server and calls a
power shell script. The script reports a result back, for example,
"day", "night", "red" or "blue". This should now be processed on the
Jenkins server (a bash script). But how? An other build step would run
at the Windows server again, a post build action won't start external
processes like bash scripts. I could create a second job that runs on
the Jenkins master itself. But how do I get the results of the Power
Shell script?

Grateful for hints
--
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
<mailto:jenkinsci-users+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-users/7604abe1-01fd-4f07-94c9-0352318ebba7%40googlegroups.com
<https://groups.google.com/d/msgid/jenkinsci-users/7604abe1-01fd-4f07-94c9-0352318ebba7%40googlegroups.com?utm_medium=email_source=footer>.

--
Eric Pyle
Siemens Digital Industries Software
Simulation and Test Solutions, Product Development
eric.p...@siemens.com
https://www.sw.siemens.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/ec42bd65-5454-ba03-8825-148a67323ca1%40siemens.com.

Re: Jobs with a wildcard tag refspec sometimes rebuild tags at same commit

2020-01-09 Thread Eric Pierson

Issue entered and will update this thread as things develop.
https://issues.jenkins-ci.org/browse/JENKINS-60717

Thanks,
Eric

On Thu, Jan 9, 2020 at 7:53 AM Eric Pierson  wrote:

> Yes, I intend to write up the issue today for tracking.
>
> I have been troubleshooting more but unfortunately don't have anything
> valuable to add just yet. I will reply to this thread once the issue has
> been opened with more details.
>
> Eric
>
> On Thu, Jan 9, 2020, 05:49 Beushausen, Christian <
> christian.beushau...@continental-corporation.com> wrote:
>
>> Hi Eric, Mark,
>>
>>
>>
>> Could you keep the list updated? Or have you created a new issue on Jira
>> for this?
>> We do see this (or a very similar) issue also for at least one job in our
>> environment
>>
>>
>>
>> Thank you and cheers.
>>
>>
>>
>> Mit freundlichen Gruessen/Best regards,
>>
>> *Christian Beushausen*
>> I S PD SW SWF
>> Interior Systems & Technology
>>
>> *E-Mail:* christian.beushau...@continental-corporation.com
>>
>>
>> *From:* jenkinsci-users@googlegroups.com <
>> jenkinsci-users@googlegroups.com> *On Behalf Of *Mark Waite
>> *Sent:* Dienstag, 7. Januar 2020 01:21
>> *To:* Jenkins Users 
>> *Subject:* Re: Jobs with a wildcard tag refspec sometimes rebuild tags
>> at same commit
>>
>>
>>
>> Discard old builds is very likely the problem.  If a tag build is removed
>> from the history by "Discard old builds" then future searches for the that
>> tag (or the SHA-1 of the commit associated with the tag) will fail and it
>> will build again.
>>
>>
>>
>> On Mon, Jan 6, 2020 at 5:18 PM Eric Pierson  wrote:
>>
>> Thank you for your response, Mark!
>>
>>
>>
>> I have not tried to run any scripts to prune history as I see described
>> in JENKINS-19022.  There are a lot of comments in this one and I am still
>> re-reading them to be sure I am not missing something else relevant folks
>> discovered along the way.
>>
>>
>>
>> I do have "Discard old builds" enabled with Strategy "Log Rotation" and
>> "Max # of builds to keep" = 10.  Forgive me for omitting the fact that I
>> use Discard old builds initially.
>>
>>
>>
>> Reading more about  "Discard old builds":
>>
>>- Build count: discard the *oldest build* when a certain number of
>>builds already exist
>>- Note that Jenkins does not discard items immediately when this
>>configuration is updated, or as soon as any of the configured values are
>>exceeded; *these rules are evaluated each time a build of this
>>project completes.*
>>
>> I am now focusing on the "Discard old builds" settings and build.xml
>> content, and what may be happening to the build history when a build
>> completes.  I have one job that has only run a total of 7 times that had
>> the issue on builds #3 and #4, and the example I initially provided has
>> only run a total of 12 times and we see the issue on multiple builds there,
>> too.  So while there are indeed many tags in the repo, the build history is
>> not "large" yet.
>>
>>
>>
>> I have another Jenkins environment I used for a while where I did not
>> have this issue.  It had the same settings (including "Discard old
>> builds"), but when I was running jobs through this environment on a regular
>> basis, Jenkins and plugins would have been at older versions.
>>
>>
>>
>> To hone in on git plugin versions just in the change they are relevant, I
>> compared my build.xml:
>>
>>
>>
>> New Environment
>>
>> 
>>
>> 
>>
>> 
>>
>>
>>
>> Old Environment
>>
>> 
>>
>> 
>>
>> 
>>
>>
>>
>>  ---
>>
>>
>>
>> Given this additional information, please let me know if you have any new
>> thoughts or if you feel I should file a bug report (for perhaps the
>> logRotate or BuildDiscarder area?) as I continue to research and test.
>>
>>
>>
>> Thank you again for your help and everything you do for the Jenkins
>> community!
>>
>>
>>
>> -Eric
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Jan 3, 2020 at 8:38 PM Mark Waite 
>> wrote:
>>
>>
>>
>>
>>
>> On Fri, Jan 3, 2020 at 2:51 PM Eric Pierson  wrote:
>>
>> I am tr

Re: Jobs with a wildcard tag refspec sometimes rebuild tags at same commit

2020-01-09 Thread Eric Pierson

Yes, I intend to write up the issue today for tracking.

I have been troubleshooting more but unfortunately don't have anything
valuable to add just yet. I will reply to this thread once the issue has
been opened with more details.

Eric

On Thu, Jan 9, 2020, 05:49 Beushausen, Christian <
christian.beushau...@continental-corporation.com> wrote:

> Hi Eric, Mark,
>
>
>
> Could you keep the list updated? Or have you created a new issue on Jira
> for this?
> We do see this (or a very similar) issue also for at least one job in our
> environment
>
>
>
> Thank you and cheers.
>
>
>
> Mit freundlichen Gruessen/Best regards,
>
> *Christian Beushausen*
> I S PD SW SWF
> Interior Systems & Technology
>
> *E-Mail:* christian.beushau...@continental-corporation.com
>
>
> *From:* jenkinsci-users@googlegroups.com 
> *On Behalf Of *Mark Waite
> *Sent:* Dienstag, 7. Januar 2020 01:21
> *To:* Jenkins Users 
> *Subject:* Re: Jobs with a wildcard tag refspec sometimes rebuild tags at
> same commit
>
>
>
> Discard old builds is very likely the problem.  If a tag build is removed
> from the history by "Discard old builds" then future searches for the that
> tag (or the SHA-1 of the commit associated with the tag) will fail and it
> will build again.
>
>
>
> On Mon, Jan 6, 2020 at 5:18 PM Eric Pierson  wrote:
>
> Thank you for your response, Mark!
>
>
>
> I have not tried to run any scripts to prune history as I see described in
> JENKINS-19022.  There are a lot of comments in this one and I am still
> re-reading them to be sure I am not missing something else relevant folks
> discovered along the way.
>
>
>
> I do have "Discard old builds" enabled with Strategy "Log Rotation" and
> "Max # of builds to keep" = 10.  Forgive me for omitting the fact that I
> use Discard old builds initially.
>
>
>
> Reading more about  "Discard old builds":
>
>- Build count: discard the *oldest build* when a certain number of
>builds already exist
>- Note that Jenkins does not discard items immediately when this
>configuration is updated, or as soon as any of the configured values are
>exceeded; *these rules are evaluated each time a build of this project
>completes.*
>
> I am now focusing on the "Discard old builds" settings and build.xml
> content, and what may be happening to the build history when a build
> completes.  I have one job that has only run a total of 7 times that had
> the issue on builds #3 and #4, and the example I initially provided has
> only run a total of 12 times and we see the issue on multiple builds there,
> too.  So while there are indeed many tags in the repo, the build history is
> not "large" yet.
>
>
>
> I have another Jenkins environment I used for a while where I did not have
> this issue.  It had the same settings (including "Discard old builds"), but
> when I was running jobs through this environment on a regular basis,
> Jenkins and plugins would have been at older versions.
>
>
>
> To hone in on git plugin versions just in the change they are relevant, I
> compared my build.xml:
>
>
>
> New Environment
>
> 
>
> 
>
> 
>
>
>
> Old Environment
>
> 
>
> 
>
> 
>
>
>
>  ---
>
>
>
> Given this additional information, please let me know if you have any new
> thoughts or if you feel I should file a bug report (for perhaps the
> logRotate or BuildDiscarder area?) as I continue to research and test.
>
>
>
> Thank you again for your help and everything you do for the Jenkins
> community!
>
>
>
> -Eric
>
>
>
>
>
>
>
> On Fri, Jan 3, 2020 at 8:38 PM Mark Waite 
> wrote:
>
>
>
>
>
> On Fri, Jan 3, 2020 at 2:51 PM Eric Pierson  wrote:
>
> I am troubleshooting a scenario where jobs with a wildcard tag refspec
> (+refs/tags/*:refs/remotes/origin/tags/*) sometimes detect changes and
> rebuild a successfully built tag referencing the same commit.
>
>
>
> When a rerun occurs, prior job runs for the tag are no longer present in
> the Git Build History for the job.
>
>
>
>
>
> That sounds to me as though you are relying on the JENKINS-19022 memory
> bloat bug to retain history of more jobs in the BuildData than are actually
> in the build history.
>
>
>
> If someone executed one of the scripts that is mentioned in JENKINS-19022
> to clean the excess BuildData from the history, that seems like it might
> cause the SHA-1's referenced by some of the tags to be removed from the
> history.
>
>
>
> If build history w

Re: Jobs with a wildcard tag refspec sometimes rebuild tags at same commit

2020-01-06 Thread Eric Pierson

Thank you for your response, Mark!

I have not tried to run any scripts to prune history as I see described in
JENKINS-19022.  There are a lot of comments in this one and I am still
re-reading them to be sure I am not missing something else relevant folks
discovered along the way.

I do have "Discard old builds" enabled with Strategy "Log Rotation" and
"Max # of builds to keep" = 10.  Forgive me for omitting the fact that I
use Discard old builds initially.

Reading more about  "Discard old builds":

   - Build count: discard the *oldest build* when a certain number of
   builds already exist
   - Note that Jenkins does not discard items immediately when this
   configuration is updated, or as soon as any of the configured values are
   exceeded; *these rules are evaluated each time a build of this project
   completes.*

I am now focusing on the "Discard old builds" settings and build.xml
content, and what may be happening to the build history when a build
completes.  I have one job that has only run a total of 7 times that had
the issue on builds #3 and #4, and the example I initially provided has
only run a total of 12 times and we see the issue on multiple builds there,
too.  So while there are indeed many tags in the repo, the build history is
not "large" yet.

I have another Jenkins environment I used for a while where I did not have
this issue.  It had the same settings (including "Discard old builds"), but
when I was running jobs through this environment on a regular basis,
Jenkins and plugins would have been at older versions.

To hone in on git plugin versions just in the change they are relevant, I
compared my build.xml:

New Environment

Old Environment

 ---

Given this additional information, please let me know if you have any new
thoughts or if you feel I should file a bug report (for perhaps the
logRotate or BuildDiscarder area?) as I continue to research and test.

Thank you again for your help and everything you do for the Jenkins
community!

-Eric

On Fri, Jan 3, 2020 at 8:38 PM Mark Waite  wrote:

>
>
> On Fri, Jan 3, 2020 at 2:51 PM Eric Pierson  wrote:
>
>> I am troubleshooting a scenario where jobs with a wildcard tag refspec
>> (+refs/tags/*:refs/remotes/origin/tags/*) sometimes detect changes and
>> rebuild a successfully built tag referencing the same commit.
>>
>> When a rerun occurs, prior job runs for the tag are no longer present in
>> the Git Build History for the job.
>>
>>
> That sounds to me as though you are relying on the JENKINS-19022 memory
> bloat bug to retain history of more jobs in the BuildData than are actually
> in the build history.
>
> If someone executed one of the scripts that is mentioned in JENKINS-19022
> to clean the excess BuildData from the history, that seems like it might
> cause the SHA-1's referenced by some of the tags to be removed from the
> history.
>
> If build history were being removed based on a specific number of builds,
> then it also could be that the history entry which included that tag was
> removed from the list, and thus was no longer visible.
>
> Mark Waite
>
>
>> I am seeking help to further investigate and trace polling activity to
>> try to determine what changes are being detected that trigger the job to
>> run again, or learn if i should submit this as a bug report for assistance
>> instead.
>>
>> Thanks, everyone!
>>
>>
>> ---
>> Existing Bugs Found:
>>
>> This was the most relative bug I could find, yet my situation is
>> different.
>>
>>
>> https://issues.jenkins-ci.org/browse/JENKINS-17614?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel=true
>> ---
>>
>>
>> *My Environment:*
>>
>> Jenkins 2.176.3 on traditional VMs (not containers)
>> GitHub Plugin 1.29.5
>> Git Plugin 4.0.0
>>
>>
>> *Steps to reproduce:*
>>
>> 1. Add a webhook to a GitHub repo which sends the following events to
>> Jenkins:  Pushes, Branch or tag creation, Releases.
>>
>> 2. Create two “Pipeline” jobs in Jenkins, both referencing the same
>> GitHub repo.  The jobs execute a Declarative Pipeline Jenkinsfile script.
>>
>> *NOTE: JJB is used to create the jobs (jobs are not copied).*
>>
>>
>>
>> Settings for job 1 (master branch job):
>> Do not allow concurrent builds
>> GitHub hook trigger for GITScm polling
>> Pipeline script from SCM: Git
>> Repo ID:  origin
>> Refspec:  +refs/heads/*:refs/remotes/origin/*
>> Branch Specifier: refs/heads/master
>> Additional Behaviors:  Wipe out repository & forc

Jobs with a wildcard tag refspec sometimes rebuild tags at same commit

2020-01-03 Thread Eric Pierson

I am troubleshooting a scenario where jobs with a wildcard tag refspec
(+refs/tags/*:refs/remotes/origin/tags/*) sometimes detect changes and
rebuild a successfully built tag referencing the same commit.

When a rerun occurs, prior job runs for the tag are no longer present in
the Git Build History for the job.

I am seeking help to further investigate and trace polling activity to try
to determine what changes are being detected that trigger the job to run
again, or learn if i should submit this as a bug report for assistance
instead.

Thanks, everyone!

---
Existing Bugs Found:

This was the most relative bug I could find, yet my situation is different.

https://issues.jenkins-ci.org/browse/JENKINS-17614?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel=true
---

*My Environment:*

Jenkins 2.176.3 on traditional VMs (not containers)
GitHub Plugin 1.29.5
Git Plugin 4.0.0

*Steps to reproduce:*

1. Add a webhook to a GitHub repo which sends the following events to
Jenkins: Pushes, Branch or tag creation, Releases.

2. Create two “Pipeline” jobs in Jenkins, both referencing the same GitHub
repo. The jobs execute a Declarative Pipeline Jenkinsfile script.

*NOTE: JJB is used to create the jobs (jobs are not copied).*

Settings for job 1 (master branch job):
Do not allow concurrent builds
GitHub hook trigger for GITScm polling
Pipeline script from SCM: Git
Repo ID: origin
Refspec: +refs/heads/*:refs/remotes/origin/*
Branch Specifier: refs/heads/master
Additional Behaviors: Wipe out repository & force clone
Lightweight checkout: false

Settings for job 2 (tag job):
Do not allow concurrent builds
GitHub hook trigger for GITScm polling
Pipeline script from SCM: Git
Repo ID: origin
Refspec: +refs/tags/*:refs/remotes/origin/tags/*
Branch Specifier: */tags/*
Additional Behaviors: Wipe out repository & force clone
Lightweight checkout: false

3. When commits are merged to the master branch of the repo, the webhook
fires and Job 1 executes.

4. When new releases (tags) are published, the webhook fires and Job 2
executes for the most recent (new) tag.

(Things have been running smoothly for me with this type of setup for a
couple years.)

5. Occasionally there is a situation with jobs configured like job 2,
specifically:

- New commits are pushed to master which triggers the webhook to Jenkins.
- Job 1 polls and detects the new commits to master and runs.
- Job 2 polls and detects changes even though no tags have been created
and previously built tags still reference the same commit.
- Job 2 then runs and rebuilds the last tag it had already built
successfully.
- The polling log shows last built revision is the same commit and tag,
no diff is performed, but changes are found.
- The changes page for the job shows no changes.

Observations when this occurs:

- Let's say the tag has been built 4 times. We will have a polling log
and change logs for the first job run that initially built the tag, then
jobs 2 and 3 will have no polling log on the filesystem but will have an
empty changelog0.xml, then the last build of the tag has a polling log and
change log files.
- When a tag is being re-built, when you look at Git Build Data for the
job rebuilding that tag, all prior job runs that built that tag
successfully are missing from the history.
- The problem does not always happen in my environment. It can happen
for a repo one day then not happen the next. Perhaps I am simply
overlooking some activity in the repo that results in polling detecting
changes with my wildcard tag specifier.
- Workspaces appear to be intact as required for the git plugin to
perform a wildcard tag poll (post-clone). There are no indications of
workspaces needing to be created as job runs start.
- The same build node (same workspace) can be used for all job runs and
the issue can still occur.

*Example polling log and Git Build Data for a re-run:*

Started on Dec 30, 2019 7:54:51 AM
Started by event from 10.25.59.190 ⇒ https:///github-webhook/ on Mon
Dec 30 07:54:51 EST 2019
Using strategy: Default
[poll] Last Built Revision: Revision
f44c2c56f44b84a5d2b534eacf9c51a099f65dc2 (origin/tags/v2.3.0,
refs/tags/v2.3.0)
using credential 28d104ae-ad72-401a-8dc2-d72cf4b8e913
> /data/git-client/bin/git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repositories
> /data/git-client/bin/git config remote.origin.url
https://github.com/repo.git # timeout=10
Fetching upstream changes from https://github.com/repo.git
> /data/git-client/bin/git --version # timeout=10
using GIT_ASKPASS to set credentials Service Account
> /data/git-client/bin/git fetch --tags --force --progress --
https://github.com/repo.git +refs/tags/*:refs/remotes/origin/tags/* #
timeout=10

Re: Git Commit Message as an Environment Variable

2019-11-20 Thread 'Eric Boehm' via Jenkins Users

You could use groovy to collect the commit message from the ChangeSet and 
then put it in an environment variable.

On Tuesday, November 19, 2019 at 9:53:52 AM UTC-5, Jeremy Hartley wrote:
>
> Hi,
>
> I'm playing around a bit with Git environment variables to send to slack 
> and would like to include the Git commit message. I don't see it available 
> in the list here: 
> https://wiki.jenkins.io/display/JENKINS/Git+Plugin#GitPlugin-Environmentvariables
>
> Is there any way to send the Git commit message to slackSend as an 
> environment variable in my pipeline?
>
> Thanks
>
> Jeremy
>

-- 
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/a0b485ff-8f48-4432-be5b-8a2d6af600a4%40googlegroups.com.

Re: Jenkins NON-GUI notification of core / plug-in vulnerabilities / warnings and updates

2019-09-24 Thread Eric Engstrom



On Monday, September 23, 2019 at 11:08:58 AM UTC-5, Daniel Beck wrote:
>
> Jenkins uses the update center metadata to show applicable warnings. It 
> would be a bit of a hack, and use internals not meant for public 
> consumption, but you could do that, too. See the bottom of 
> https://updates.jenkins.io/update-center.actual.json for the warning 
> definitions. (No complaining if we change the format without prior warning 
> etc.!)
>

The implication of this is that there is no current method to have jenkins 
send notifications (emails, or otherwise) on known vulnerabilities, core or 
plug-in.  Sounds like an opportunity for improvement, to which I'd be 
somewhat happy to help with development, but as a total jenkins _user_, I 
would need more pointers for development. The most obvious would be: is 
this something that should be in core or should it be yet-another-plug-in?  
Or, I suppose, I could develop it as a groovy script that one could run as 
a jenkins job within jenkins itself.  

Thoughts?
 

>
> On Mon, Sep 23, 2019 at 5:52 PM Eric Engstrom  > wrote:
>
>> Yes, I'm subscribed to the "Security advisories" mailing list 
>> <https://groups.google.com/forum/m/#!forum/jenkinsci-advisories>, and 
>> while it provides indications of core updates w.r.t. vulnerabilities, it's 
>> not as helpful for plug-ins - that is, not only would I have to look at all 
>> the plug-ins that are listed as being patched, but it doesn't, AFAICT, tell 
>> me when there are unpatched vulnerabilities.
>>
>
> Counterexample: 
> https://groups.google.com/d/msg/jenkinsci-advisories/T3Zt01nhGao/kn_VhKasCgAJ 
> (Aug 7 this year, second email in the "thread" -- Thanks Google!)
>

Proven wrong - thanks.  I'll pay more attention. 

-- 
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/71abc41c-ad1a-4b0a-96b5-aff68b6aaad4%40googlegroups.com.

Jenkins NON-GUI notification of core / plug-in vulnerabilities / warnings and updates

2019-09-23 Thread Eric Engstrom

Jenkins is great at telling me when there are updates available for
Jenkins's core or when there are security vulnerabilities in plug-ins.
This it does with a "nice-fat-red" number of vulnerabilities on the top
of the web page when I am logged in. And when one clicks on that, you
get a nice synopsis.

However, I cannot find any system setting or plug-in which will notify
me (presumably via email) when there is a core or plug-in update which
is available to mitigate a vulnerability, or even when there are ANY
updates to apply.

I have used the CLI (via SSH) to find a way to list the plug-ins with
updates available, as in this very hackish approach which relies on the
formatting of the list-plugins command:

$ ssh -l USER -p PORT JENKINS.domain list-plugins | egrep '$[0-9.]+$'
| sort
ant Ant Plugin 1.9 (1.10)
antisamy-markup-formatter OWASP Markup Formatter Plugin 1.5 (1.6)
branch-api Branch API Plugin 2.5.3 (2.5.4)
...

But I have not found any way via the CLI to:

distinguish between security updates and general/feature updates
identify core updates I've also looked at the jenkins log
(/var/lib/jenkins/jenkins.log on Ubuntu) to no avail.

Specific question: Is there a setting (and I've looked extensively) or
plug-in (or even CLI method) which will provide the warnings /
vulnerabilities without being forced to login to Jenkins' web interface
and look manually?

Yes, I'm subscribed to the "Security advisories" mailing list, and while
it provides indications of core updates w.r.t. vulnerabilities, it's not
as helpful for plug-ins - that is, not only would I have to look at all
the plug-ins that are listed as being patched, but it doesn't, AFAICT,
tell me when there are unpatched vulnerabilities.

General question: How should I go about ensuring that my Jenkins
installation is automatically kept up-to-date, including all plug-ins?
Ideally this would be with respect to security vulnerabilities only,
leaving feature updates aside.

--
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/66a1dfa1-9558-18d4-28d5-7cd207d38139%40gmail.com.

Jenkins NON-GUI notification of core / plug-in vulnerabilities / warnings and updates

2019-09-23 Thread Eric Engstrom

Jenkins is great at telling me when there are updates available for
Jenkins's core or when there are security vulnerabilities in plug-ins. This
it does with a "nice-fat-red" number of vulnerabilities on the top of the
web page when I am logged in. And when one clicks on that, you get a nice
synopsis such as:

(Yes, I've already updated my Jenkins instance to patch these issues, post
screen-shot).

However, I cannot find any system setting or plug-in which will notify me
(presumably via email) when there is a core or plug-in update which is
available to mitigate a vulnerability, or even when there are ANY updates
to apply.

I have used the CLI (via SSH) to find a way to list the plug-ins with
updates available, as in this very hackish approach which relies on the
formatting of the list-plugins command:

$ ssh -l USER -p PORT JENKINS.domain list-plugins | egrep '$[0-9.]+$' |
sort
ant Ant Plugin 1.9 (1.10)
antisamy-markup-formatter OWASP Markup Formatter Plugin 1.5 (1.6)
branch-api Branch API Plugin 2.5.3 (2.5.4)
...

But I have not found any way via the CLI to:

- distinguish between security updates and general/feature updates
- identify core updates

I've also looked at the jenkins log (/var/lib/jenkins/jenkins.log on
Ubuntu) to no avail.

*Specific question*: Is there a setting (and I've looked extensively) or
plug-in (or even CLI method) which will provide the warnings /
vulnerabilities without being forced to login to Jenkins' web interface and
look manually?

Yes, I'm subscribed to the "Security advisories" mailing list
, and while
it provides indications of core updates w.r.t. vulnerabilities, it's not as
helpful for plug-ins - that is, not only would I have to look at all the
plug-ins that are listed as being patched, but it doesn't, AFAICT, tell me
when there are unpatched vulnerabilities.

*General question*: How should I go about ensuring that my Jenkins
installation is automatically kept up-to-date, including all plug-ins?
Ideally this would be with respect to security vulnerabilities only,
leaving feature updates aside.

--
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/04730f67-7b82-43ff-8f2a-ee5ccc421170%40googlegroups.com.

Re: jenkins-cli.jar stopped working for not apparent reason

2019-06-27 Thread Eric Pyle

I don't think that will help. The CLI changed in a recent release, and 
even without the reverse proxy you have to change how you use it. Did 
you have a look at the "Common Problems with the CLI client" in the 
docs? Remember that the username you are passing with -user is a Jenkins 
user id, not a Linux username. Have you added the public key for that 
user to Jenkins as shown in the doc?


One other thing: You are using "java -cp /path/to/cli.jar", while all 
the examples in the help show "java -jar /path/to/cli.jar". Might be 
worth trying. In any case, I ended up switching to the direct ssh method 
I showed in my shell script, and it's been working for me.


Good luck!
Eric

On 6/27/2019 10:17 AM, Eric Fetzer wrote:
Hi Eric, thanks for the reply.  I'm not using a reverse proxy on my 
Jenkins server.  It's pretty much out of the box.  I've been using the 
jenkins-cli.jar file for about 6 years.  I just recently upgraded it 
and it stopped working. Before, I was able to connect with just the -s 
and the -i.  Not sure why with the new version -i needs the ssh 
option.  Maybe I should just call straight to the jenkins-cli.jar on 
the server to bypass jenkins remote security functionality?


Thanks,
Eric


On Tue, Jun 25, 2019 at 11:10 AM Eric Pyle <mailto:eric.p...@cd-adapco.com>> wrote:


Have a look at the docs: https://jenkins.io/doc/book/managing/cli/
.  As stated there, if you are using a reverse proxy on your
Jenkins server, it won't work using the jenkins-cli.jar as you
are. You can try using the property
-Dorg.jenkinsci.main.modules.sshd.SSHD.hostName on Jenkins
startup, but that didn't work for our installation. I ended up
switching to accessing CLI via the ssh command, as documented
under "Using the CLI over SSH". Here's a little shell script I set
up to access CLI from a bash prompt:

$ *cat bin/jenkins*
if [ $# == 0 ]; then DEF_ARG=help;fi
port=`curl -Lv ${JENKINS_URL}/login 2>&1 | grep -i
'x-ssh-endpoint'|grep -oE '([0-9]+)'`
ssh -p $port starci $@ $DEF_ARG


    On 6/25/2019 11:52 AM, Eric Fetzer wrote:

Thanks Eric!  I updated my java version to 1.8 and it appears my
command line has changed since the version of java-cli.jar I was
using.  the -i doesn't work together with the -s without a -ssh
and the -ssh needs a -user, lol.  But once I put all those
together, I get:

java -cp /my/path/to/jar/jenkins-cli.jar -s
http://myJenkinsServer:8080 <http://myjenkinsserver:8080/>  -ssh
-user jenkins -i /my/key/.ssh/id_rsa help

Jun 25, 2019 9:48:19 AM
org.apache.sshd.common.util.security.AbstractSecurityProviderRegistrar
getOrCreateProvider
INFO: getOrCreateProvider(EdDSA) created instance of
net.i2p.crypto.eddsa.EdDSASecurityProvider
Jun 25, 2019 9:48:19 AM hudson.cli.SSHCLI sshConnection
WARNING: No header 'X-SSH-Endpoint' returned by Jenkins


I don't think this is a success as it didn't return help to me.


On Tuesday, June 25, 2019 at 9:33:37 AM UTC-6, Eric Pyle wrote:

It's telling you the Java version is not correct. What
version of Java are you using? Needs to be 1.8 for current
Jenkins.

On 6/25/2019 11:27 AM, Eric Fetzer wrote:

OK, that was a flop.  I downloaded the correct
jenkins-cli.jar from : http://myJenkinsServer:8080
<http://myjenkinsserver:8080/>/jnlpJars/jenkins-cli.jar
<https://jenkins.example.com/jnlpJars/jenkins-cli.jar>, and
now I get:

Exception in thread "main"
java.lang.UnsupportedClassVersionError: hudson/cli/CLI :
Unsupported major.minor version 52.0
        at java.lang.ClassLoader.defineClass1(Native Method)
        at
java.lang.ClassLoader.defineClass(ClassLoader.java:648)
        at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
        at
java.net.URLClassLoader.defineClass(URLClassLoader.java:272)
        at
java.net.URLClassLoader.access$000(URLClassLoader.java:68)
        at
java.net.URLClassLoader$1.run(URLClassLoader.java:207)
        at
java.net.URLClassLoader$1.run(URLClassLoader.java:201)
        at
java.security.AccessController.doPrivileged(Native Method)
        at
java.net.URLClassLoader.findClass(URLClassLoader.java:200)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:325)
        at
sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:296)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:270)
        at
sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:406)

On Tuesday, June 25, 2019 at 8:12:58 AM UTC-6, Eric Fetzer
wrote:

This makes no sens

Re: jenkins-cli.jar stopped working for not apparent reason

Thanks Eric!  I updated my java version to 1.8 and it appears my command 
line has changed since the version of java-cli.jar I was using.  the -i 
doesn't work together with the -s without a -ssh and the -ssh needs a 
-user, lol.  But once I put all those together, I get:

java -cp /my/path/to/jar/jenkins-cli.jar -s http://myJenkinsServer:8080 
<http://myjenkinsserver:8080/>  -ssh -user jenkins -i /my/key/.ssh/id_rsa 
help

Jun 25, 2019 9:48:19 AM 
org.apache.sshd.common.util.security.AbstractSecurityProviderRegistrar 
getOrCreateProvider
INFO: getOrCreateProvider(EdDSA) created instance of 
net.i2p.crypto.eddsa.EdDSASecurityProvider
Jun 25, 2019 9:48:19 AM hudson.cli.SSHCLI sshConnection
WARNING: No header 'X-SSH-Endpoint' returned by Jenkins


I don't think this is a success as it didn't return help to me.


On Tuesday, June 25, 2019 at 9:33:37 AM UTC-6, Eric Pyle wrote:
>
> It's telling you the Java version is not correct. What version of Java are 
> you using? Needs to be 1.8 for current Jenkins.
>
> On 6/25/2019 11:27 AM, Eric Fetzer wrote:
>
> OK, that was a flop.  I downloaded the correct jenkins-cli.jar from : 
> http://myJenkinsServer:8080 <http://myjenkinsserver:8080/>/
> jnlpJars/jenkins-cli.jar 
> <https://jenkins.example.com/jnlpJars/jenkins-cli.jar>, and now I get: 
>
> Exception in thread "main" java.lang.UnsupportedClassVersionError: 
> hudson/cli/CLI : Unsupported major.minor version 52.0
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:648)
> at 
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:272)
> at java.net.URLClassLoader.access$000(URLClassLoader.java:68)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:207)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:201)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:200)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:325)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:296)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:270)
> at 
> sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:406)
>
> On Tuesday, June 25, 2019 at 8:12:58 AM UTC-6, Eric Fetzer wrote: 
>>
>> This makes no sense.  When I run the command: 
>>
>> java -cp /my/path/to/jar/jenkins-cli.jar -s http://myJenkinsServer:8080 
>> -i /my/key/id_rsa help
>>
>> I get:
>>
>> Neither -s nor the JENKINS_URL env var is specified.
>> Jenkins CLI
>> Usage: java -jar jenkins-cli.jar [-s URL] command [opts...] args...
>> Options:
>> -s URL   : the server URL (defaults to the JENKINS_URL env var)
>> -i KEY   : SSH private key file used for authentication
>> -p HOST:PORT : HTTP proxy host and port for HTTPS proxy tunneling. See 
>> http://jenkins-ci.org/https-proxy-tunnel
>> -noCertificateCheck : bypass HTTPS certificate check entirely. Use with 
>> caution
>> -noKeyAuth   : dont try to load the SSH authentication private key. 
>> Conflicts with -i
>>
>> The available commands depend on the server. Run the help command to
>> see the list.
>>
>>
>> So I figure I'll play, and set the env variable even though the -s was in 
>> there plain as day.  So I do:
>>
>> export JENKINS_URL='http://my.JenkinsServer:8080' 
>> java -cp /my/path/to/jar/jenkins-cli.jar -jar 
>> /my/path/to/jar/jenkins-cli.jar -i /my/key/id_rsa help
>>
>> I get:
>>
>>
>> Exception in thread "main" java.io.IOException: Failed to connect to 
>> http://my.JenkinsServer:8080/
>> at hudson.cli.CLI.getCliTcpPort(CLI.java:271)
>> at hudson.cli.CLI.(CLI.java:126)
>> at 
>> hudson.cli.CLIConnectionFactory.connect(CLIConnectionFactory.java:72)
>> at hudson.cli.CLI._main(CLI.java:471)
>> at hudson.cli.CLI.main(CLI.java:387)
>> Caused by: java.net.UnknownHostException: my.JenkinsServer
>> at 
>> java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:175)
>> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)
>> at java.net.Socket.connect(Socket.java:543)
>> at java.net.Socket.connect(Socket.java:492)
>> at sun.net.NetworkClient.doConnect(NetworkClient.java:178)
>> at sun.net.www.http.HttpClient.openServer(HttpClient.java:417)
>> at sun.net.www.http.HttpClient

Re: jenkins-cli.jar stopped working for not apparent reason

2019-06-25 Thread Eric Pyle

It's telling you the Java version is not correct. What version of Java 
are you using? Needs to be 1.8 for current Jenkins.


On 6/25/2019 11:27 AM, Eric Fetzer wrote:
OK, that was a flop.  I downloaded the correct jenkins-cli.jar from : 
http://myJenkinsServer:8080 
<http://myjenkinsserver:8080/>/jnlpJars/jenkins-cli.jar 
<https://jenkins.example.com/jnlpJars/jenkins-cli.jar>, and now I get:


Exception in thread "main" java.lang.UnsupportedClassVersionError: 
hudson/cli/CLI : Unsupported major.minor version 52.0

        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:648)
        at 
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)

        at java.net.URLClassLoader.defineClass(URLClassLoader.java:272)
        at java.net.URLClassLoader.access$000(URLClassLoader.java:68)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:207)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:201)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:200)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:325)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:296)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:270)
        at 
sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:406)


On Tuesday, June 25, 2019 at 8:12:58 AM UTC-6, Eric Fetzer wrote:

This makes no sense.  When I run the command:

java -cp /my/path/to/jar/jenkins-cli.jar -s
http://myJenkinsServer:8080 -i /my/key/id_rsa help

I get:

Neither -s nor the JENKINS_URL env var is specified.
Jenkins CLI
Usage: java -jar jenkins-cli.jar [-s URL] command [opts...]
args...
Options:
-s URL       : the server URL (defaults to the JENKINS_URL env
var)
-i KEY       : SSH private key file used for authentication
-p HOST:PORT : HTTP proxy host and port for HTTPS proxy
tunneling. See http://jenkins-ci.org/https-proxy-tunnel
<http://jenkins-ci.org/https-proxy-tunnel>
-noCertificateCheck : bypass HTTPS certificate check entirely.
Use with caution
-noKeyAuth   : dont try to load the SSH authentication private
key. Conflicts with -i

The available commands depend on the server. Run the help
command to
see the list.


So I figure I'll play, and set the env variable even though the -s
was in there plain as day.  So I do:

export JENKINS_URL='http://my.JenkinsServer:8080
<http://my.JenkinsServer:8080>'
java -cp /my/path/to/jar/jenkins-cli.jar -jar
/my/path/to/jar/jenkins-cli.jar -i /my/key/id_rsa help

I get:


Exception in thread "main" java.io.IOException: Failed to
connect to http://my.JenkinsServer:8080/
        at hudson.cli.CLI.getCliTcpPort(CLI.java:271)
        at hudson.cli.CLI.(CLI.java:126)
        at
hudson.cli.CLIConnectionFactory.connect(CLIConnectionFactory.java:72)
        at hudson.cli.CLI._main(CLI.java:471)
        at hudson.cli.CLI.main(CLI.java:387)
Caused by: java.net.UnknownHostException: my.JenkinsServer
        at

java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:175)
        at
java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)
        at java.net.Socket.connect(Socket.java:543)
        at java.net.Socket.connect(Socket.java:492)
        at sun.net.NetworkClient.doConnect(NetworkClient.java:178)
        at
sun.net.www.http.HttpClient.openServer(HttpClient.java:417)
        at
sun.net.www.http.HttpClient.openServer(HttpClient.java:519)
        at sun.net.www.http.HttpClient.(HttpClient.java:203)
        at sun.net.www.http.HttpClient.New(HttpClient.java:296)
        at sun.net.www.http.HttpClient.New(HttpClient.java:315)
        at

sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:1004)
        at

sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:940)
        at

sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:858)
        at hudson.cli.CLI.getCliTcpPort(CLI.java:269)
        ... 4 more


A week ago I had no issues whatsoever.  Both of these servers were
patched since then.  Both servers are RHEL 6.10.  Jenkins version
2.176.1.  Any ideas of what my sudden issue could be or where to
start trouble shooting this?

Thanks,
Eric

--
You received this message because you are subscribed to the Google 
Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emai

Re: jenkins-cli.jar stopped working for not apparent reason

OK, that was a flop.  I downloaded the correct jenkins-cli.jar from : 
http://myJenkinsServer:8080 <http://myjenkinsserver:8080/>/
jnlpJars/jenkins-cli.jar 
<https://jenkins.example.com/jnlpJars/jenkins-cli.jar>, and now I get:

Exception in thread "main" java.lang.UnsupportedClassVersionError: 
hudson/cli/CLI : Unsupported major.minor version 52.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:648)
at 
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:272)
at java.net.URLClassLoader.access$000(URLClassLoader.java:68)
at java.net.URLClassLoader$1.run(URLClassLoader.java:207)
at java.net.URLClassLoader$1.run(URLClassLoader.java:201)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:200)
at java.lang.ClassLoader.loadClass(ClassLoader.java:325)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:296)
at java.lang.ClassLoader.loadClass(ClassLoader.java:270)
at 
sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:406)

On Tuesday, June 25, 2019 at 8:12:58 AM UTC-6, Eric Fetzer wrote:
>
> This makes no sense.  When I run the command:
>
> java -cp /my/path/to/jar/jenkins-cli.jar -s http://myJenkinsServer:8080 
> -i /my/key/id_rsa help
>
> I get:
>
> Neither -s nor the JENKINS_URL env var is specified.
> Jenkins CLI
> Usage: java -jar jenkins-cli.jar [-s URL] command [opts...] args...
> Options:
> -s URL   : the server URL (defaults to the JENKINS_URL env var)
> -i KEY   : SSH private key file used for authentication
> -p HOST:PORT : HTTP proxy host and port for HTTPS proxy tunneling. See 
> http://jenkins-ci.org/https-proxy-tunnel
> -noCertificateCheck : bypass HTTPS certificate check entirely. Use with 
> caution
> -noKeyAuth   : dont try to load the SSH authentication private key. 
> Conflicts with -i
>
> The available commands depend on the server. Run the help command to
> see the list.
>
>
> So I figure I'll play, and set the env variable even though the -s was in 
> there plain as day.  So I do:
>
> export JENKINS_URL='http://my.JenkinsServer:8080' 
> java -cp /my/path/to/jar/jenkins-cli.jar -jar 
> /my/path/to/jar/jenkins-cli.jar -i /my/key/id_rsa help
>
> I get:
>
>
> Exception in thread "main" java.io.IOException: Failed to connect to 
> http://my.JenkinsServer:8080/
> at hudson.cli.CLI.getCliTcpPort(CLI.java:271)
> at hudson.cli.CLI.(CLI.java:126)
> at 
> hudson.cli.CLIConnectionFactory.connect(CLIConnectionFactory.java:72)
> at hudson.cli.CLI._main(CLI.java:471)
> at hudson.cli.CLI.main(CLI.java:387)
> Caused by: java.net.UnknownHostException: my.JenkinsServer
> at 
> java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:175)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)
> at java.net.Socket.connect(Socket.java:543)
> at java.net.Socket.connect(Socket.java:492)
> at sun.net.NetworkClient.doConnect(NetworkClient.java:178)
> at sun.net.www.http.HttpClient.openServer(HttpClient.java:417)
> at sun.net.www.http.HttpClient.openServer(HttpClient.java:519)
> at sun.net.www.http.HttpClient.(HttpClient.java:203)
> at sun.net.www.http.HttpClient.New(HttpClient.java:296)
> at sun.net.www.http.HttpClient.New(HttpClient.java:315)
> at 
> sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:1004)
> at 
> sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:940)
> at 
> sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:858)
> at hudson.cli.CLI.getCliTcpPort(CLI.java:269)
> ... 4 more
>
>
> A week ago I had no issues whatsoever.  Both of these servers were patched 
> since then.  Both servers are RHEL 6.10.  Jenkins version 2.176.1.  Any 
> ideas of what my sudden issue could be or where to start trouble shooting 
> this?
>
> Thanks,
> Eric
>

-- 
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/6eef6538-ad55-49e9-8ae0-ed2c727509de%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: jenkins-cli.jar stopped working for not apparent reason

OK, I think I've been getting lucky for years.  It appears I'm supposed to 
be updating jenkins-cli.jar as jenkins is updated (happening from yum 
update all, but it's not me doing it so I don't think about it).  Updating 
the jenkins client, I'll respond how that worked in a bit.  Thanks!


On Tuesday, June 25, 2019 at 8:12:58 AM UTC-6, Eric Fetzer wrote:
>
> This makes no sense.  When I run the command:
>
> java -cp /my/path/to/jar/jenkins-cli.jar -s http://myJenkinsServer:8080 
> -i /my/key/id_rsa help
>
> I get:
>
> Neither -s nor the JENKINS_URL env var is specified.
> Jenkins CLI
> Usage: java -jar jenkins-cli.jar [-s URL] command [opts...] args...
> Options:
> -s URL   : the server URL (defaults to the JENKINS_URL env var)
> -i KEY   : SSH private key file used for authentication
> -p HOST:PORT : HTTP proxy host and port for HTTPS proxy tunneling. See 
> http://jenkins-ci.org/https-proxy-tunnel
> -noCertificateCheck : bypass HTTPS certificate check entirely. Use with 
> caution
> -noKeyAuth   : dont try to load the SSH authentication private key. 
> Conflicts with -i
>
> The available commands depend on the server. Run the help command to
> see the list.
>
>
> So I figure I'll play, and set the env variable even though the -s was in 
> there plain as day.  So I do:
>
> export JENKINS_URL='http://my.JenkinsServer:8080' 
> java -cp /my/path/to/jar/jenkins-cli.jar -jar 
> /my/path/to/jar/jenkins-cli.jar -i /my/key/id_rsa help
>
> I get:
>
>
> Exception in thread "main" java.io.IOException: Failed to connect to 
> http://my.JenkinsServer:8080/
> at hudson.cli.CLI.getCliTcpPort(CLI.java:271)
> at hudson.cli.CLI.(CLI.java:126)
> at 
> hudson.cli.CLIConnectionFactory.connect(CLIConnectionFactory.java:72)
> at hudson.cli.CLI._main(CLI.java:471)
> at hudson.cli.CLI.main(CLI.java:387)
> Caused by: java.net.UnknownHostException: my.JenkinsServer
> at 
> java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:175)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)
> at java.net.Socket.connect(Socket.java:543)
> at java.net.Socket.connect(Socket.java:492)
> at sun.net.NetworkClient.doConnect(NetworkClient.java:178)
> at sun.net.www.http.HttpClient.openServer(HttpClient.java:417)
> at sun.net.www.http.HttpClient.openServer(HttpClient.java:519)
> at sun.net.www.http.HttpClient.(HttpClient.java:203)
> at sun.net.www.http.HttpClient.New(HttpClient.java:296)
> at sun.net.www.http.HttpClient.New(HttpClient.java:315)
> at 
> sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:1004)
> at 
> sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:940)
> at 
> sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:858)
> at hudson.cli.CLI.getCliTcpPort(CLI.java:269)
> ... 4 more
>
>
> A week ago I had no issues whatsoever.  Both of these servers were patched 
> since then.  Both servers are RHEL 6.10.  Jenkins version 2.176.1.  Any 
> ideas of what my sudden issue could be or where to start trouble shooting 
> this?
>
> Thanks,
> Eric
>

-- 
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/90dcf58e-8998-4e9e-b7db-b20ab9e8fbf9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: jenkins-cli.jar stopped working for not apparent reason

Looks like this issue was fixed with Jenkins 1.424:

java.io.EOFException
> $ java -jar jenkins-cli.jar -s YOUR_SERVER_URL login
> Exception in thread "main" java.io.EOFException
> at java.io.DataInputStream.readBoolean(DataInputStream.java:227)
> at hudson.cli.Connection.readBoolean(Connection.java:90)
> at hudson.cli.CLI.authenticate(CLI.java:360)
> at hudson.cli.CLI._main(CLI.java:255)
> at hudson.cli.CLI.main(CLI.java:199)
>
> If on the server side you have such logs (perhaps with another security 
> manager)
> INFO: Accepted connection #54 from /88.171.115.235:60876
> Exception in thread "Thread-3518" java.lang.UnsupportedOperationException: 
> Not giving you the password
> at 
> com.atlassian.crowd.integration.acegi.user.CrowdUserDetails.getPassword(CrowdUserDetails.java:
> 52)
> at hudson.model.User.impersonate(User.java:250)
> at 
> org.jenkinsci.main.modules.cli.auth.ssh.SshCliAuthenticator.authenticate(SshCliAuthenticator.java:
> 44)
> at hudson.cli.CliManagerImpl$1.run(CliManagerImpl.java:99)
>
> This issues was fixed in Jenkins 1.424
>

Yet I'm getting it on version 2.176.1.

Thanks,
Eric 

On Tuesday, June 25, 2019 at 8:12:58 AM UTC-6, Eric Fetzer wrote:
>
> This makes no sense.  When I run the command:
>
> java -cp /my/path/to/jar/jenkins-cli.jar -s http://myJenkinsServer:8080 
> -i /my/key/id_rsa help
>
> I get:
>
> Neither -s nor the JENKINS_URL env var is specified.
> Jenkins CLI
> Usage: java -jar jenkins-cli.jar [-s URL] command [opts...] args...
> Options:
> -s URL   : the server URL (defaults to the JENKINS_URL env var)
> -i KEY   : SSH private key file used for authentication
> -p HOST:PORT : HTTP proxy host and port for HTTPS proxy tunneling. See 
> http://jenkins-ci.org/https-proxy-tunnel
> -noCertificateCheck : bypass HTTPS certificate check entirely. Use with 
> caution
> -noKeyAuth   : dont try to load the SSH authentication private key. 
> Conflicts with -i
>
> The available commands depend on the server. Run the help command to
> see the list.
>
>
> So I figure I'll play, and set the env variable even though the -s was in 
> there plain as day.  So I do:
>
> export JENKINS_URL='http://my.JenkinsServer:8080' 
> java -cp /my/path/to/jar/jenkins-cli.jar -jar 
> /my/path/to/jar/jenkins-cli.jar -i /my/key/id_rsa help
>
> I get:
>
>
> Exception in thread "main" java.io.IOException: Failed to connect to 
> http://my.JenkinsServer:8080/
> at hudson.cli.CLI.getCliTcpPort(CLI.java:271)
> at hudson.cli.CLI.(CLI.java:126)
> at 
> hudson.cli.CLIConnectionFactory.connect(CLIConnectionFactory.java:72)
> at hudson.cli.CLI._main(CLI.java:471)
> at hudson.cli.CLI.main(CLI.java:387)
> Caused by: java.net.UnknownHostException: my.JenkinsServer
> at 
> java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:175)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)
> at java.net.Socket.connect(Socket.java:543)
> at java.net.Socket.connect(Socket.java:492)
> at sun.net.NetworkClient.doConnect(NetworkClient.java:178)
> at sun.net.www.http.HttpClient.openServer(HttpClient.java:417)
> at sun.net.www.http.HttpClient.openServer(HttpClient.java:519)
> at sun.net.www.http.HttpClient.(HttpClient.java:203)
> at sun.net.www.http.HttpClient.New(HttpClient.java:296)
> at sun.net.www.http.HttpClient.New(HttpClient.java:315)
> at 
> sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:1004)
> at 
> sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:940)
> at 
> sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:858)
> at hudson.cli.CLI.getCliTcpPort(CLI.java:269)
> ... 4 more
>
>
> A week ago I had no issues whatsoever.  Both of these servers were patched 
> since then.  Both servers are RHEL 6.10.  Jenkins version 2.176.1.  Any 
> ideas of what my sudden issue could be or where to start trouble shooting 
> this?
>
> Thanks,
> Eric
>

-- 
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/f5249ec1-693f-4067-a433-4aa673adbf37%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: jenkins-cli.jar stopped working for not apparent reason

OK, fixed the typo in my export statement and the actual error I'm getting 
is:

Exception in thread "main" java.io.EOFException
at java.io.DataInputStream.readFully(DataInputStream.java:197)
at java.io.DataInputStream.readUTF(DataInputStream.java:609)
at java.io.DataInputStream.readUTF(DataInputStream.java:564)
at hudson.cli.CLI.connectViaCliPort(CLI.java:230)
at hudson.cli.CLI.(CLI.java:126)
at 
hudson.cli.CLIConnectionFactory.connect(CLIConnectionFactory.java:72)
at hudson.cli.CLI._main(CLI.java:471)
at hudson.cli.CLI.main(CLI.java:387)


The -s is definitely an issue but I could work around it with an export in 
my script.  Sorry for the misinformation in my original post!

Thanks,
Eric

On Tuesday, June 25, 2019 at 8:12:58 AM UTC-6, Eric Fetzer wrote:
>
> This makes no sense.  When I run the command:
>
> java -cp /my/path/to/jar/jenkins-cli.jar -s http://myJenkinsServer:8080 
> -i /my/key/id_rsa help
>
> I get:
>
> Neither -s nor the JENKINS_URL env var is specified.
> Jenkins CLI
> Usage: java -jar jenkins-cli.jar [-s URL] command [opts...] args...
> Options:
> -s URL   : the server URL (defaults to the JENKINS_URL env var)
> -i KEY   : SSH private key file used for authentication
> -p HOST:PORT : HTTP proxy host and port for HTTPS proxy tunneling. See 
> http://jenkins-ci.org/https-proxy-tunnel
> -noCertificateCheck : bypass HTTPS certificate check entirely. Use with 
> caution
> -noKeyAuth   : dont try to load the SSH authentication private key. 
> Conflicts with -i
>
> The available commands depend on the server. Run the help command to
> see the list.
>
>
> So I figure I'll play, and set the env variable even though the -s was in 
> there plain as day.  So I do:
>
> export JENKINS_URL='http://my.JenkinsServer:8080' 
> java -cp /my/path/to/jar/jenkins-cli.jar -jar 
> /my/path/to/jar/jenkins-cli.jar -i /my/key/id_rsa help
>
> I get:
>
>
> Exception in thread "main" java.io.IOException: Failed to connect to 
> http://my.JenkinsServer:8080/
> at hudson.cli.CLI.getCliTcpPort(CLI.java:271)
> at hudson.cli.CLI.(CLI.java:126)
> at 
> hudson.cli.CLIConnectionFactory.connect(CLIConnectionFactory.java:72)
> at hudson.cli.CLI._main(CLI.java:471)
> at hudson.cli.CLI.main(CLI.java:387)
> Caused by: java.net.UnknownHostException: my.JenkinsServer
> at 
> java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:175)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)
> at java.net.Socket.connect(Socket.java:543)
> at java.net.Socket.connect(Socket.java:492)
> at sun.net.NetworkClient.doConnect(NetworkClient.java:178)
> at sun.net.www.http.HttpClient.openServer(HttpClient.java:417)
> at sun.net.www.http.HttpClient.openServer(HttpClient.java:519)
> at sun.net.www.http.HttpClient.(HttpClient.java:203)
> at sun.net.www.http.HttpClient.New(HttpClient.java:296)
> at sun.net.www.http.HttpClient.New(HttpClient.java:315)
> at 
> sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:1004)
> at 
> sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:940)
> at 
> sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:858)
> at hudson.cli.CLI.getCliTcpPort(CLI.java:269)
> ... 4 more
>
>
> A week ago I had no issues whatsoever.  Both of these servers were patched 
> since then.  Both servers are RHEL 6.10.  Jenkins version 2.176.1.  Any 
> ideas of what my sudden issue could be or where to start trouble shooting 
> this?
>
> Thanks,
> Eric
>

-- 
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/107f5203-e8bd-4f4a-9f29-fea3b422a3cb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: jenkins-cli.jar stopped working for not apparent reason

I can figure out why I can't connect on port 8080.  Just need to figure out 
why all-of-a-sudden, he doesn't understand the -s.

Thanks,
Eric

On Tuesday, June 25, 2019 at 8:12:58 AM UTC-6, Eric Fetzer wrote:
>
> This makes no sense.  When I run the command:
>
> java -cp /my/path/to/jar/jenkins-cli.jar -s http://myJenkinsServer:8080 
> -i /my/key/id_rsa help
>
> I get:
>
> Neither -s nor the JENKINS_URL env var is specified.
> Jenkins CLI
> Usage: java -jar jenkins-cli.jar [-s URL] command [opts...] args...
> Options:
> -s URL   : the server URL (defaults to the JENKINS_URL env var)
> -i KEY   : SSH private key file used for authentication
> -p HOST:PORT : HTTP proxy host and port for HTTPS proxy tunneling. See 
> http://jenkins-ci.org/https-proxy-tunnel
> -noCertificateCheck : bypass HTTPS certificate check entirely. Use with 
> caution
> -noKeyAuth   : dont try to load the SSH authentication private key. 
> Conflicts with -i
>
> The available commands depend on the server. Run the help command to
> see the list.
>
>
> So I figure I'll play, and set the env variable even though the -s was in 
> there plain as day.  So I do:
>
> export JENKINS_URL='http://my.JenkinsServer:8080' 
> java -cp /my/path/to/jar/jenkins-cli.jar -jar 
> /my/path/to/jar/jenkins-cli.jar -i /my/key/id_rsa help
>
> I get:
>
>
> Exception in thread "main" java.io.IOException: Failed to connect to 
> http://my.JenkinsServer:8080/
> at hudson.cli.CLI.getCliTcpPort(CLI.java:271)
> at hudson.cli.CLI.(CLI.java:126)
> at 
> hudson.cli.CLIConnectionFactory.connect(CLIConnectionFactory.java:72)
> at hudson.cli.CLI._main(CLI.java:471)
> at hudson.cli.CLI.main(CLI.java:387)
> Caused by: java.net.UnknownHostException: my.JenkinsServer
> at 
> java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:175)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)
> at java.net.Socket.connect(Socket.java:543)
> at java.net.Socket.connect(Socket.java:492)
> at sun.net.NetworkClient.doConnect(NetworkClient.java:178)
> at sun.net.www.http.HttpClient.openServer(HttpClient.java:417)
> at sun.net.www.http.HttpClient.openServer(HttpClient.java:519)
> at sun.net.www.http.HttpClient.(HttpClient.java:203)
> at sun.net.www.http.HttpClient.New(HttpClient.java:296)
> at sun.net.www.http.HttpClient.New(HttpClient.java:315)
> at 
> sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:1004)
> at 
> sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:940)
> at 
> sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:858)
> at hudson.cli.CLI.getCliTcpPort(CLI.java:269)
> ... 4 more
>
>
> A week ago I had no issues whatsoever.  Both of these servers were patched 
> since then.  Both servers are RHEL 6.10.  Jenkins version 2.176.1.  Any 
> ideas of what my sudden issue could be or where to start trouble shooting 
> this?
>
> Thanks,
> Eric
>

-- 
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/79c3bafc-8129-4073-adbc-039087aebbc1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

jenkins-cli.jar stopped working for not apparent reason