Re: Jenkins 2.7.4 fails to load some plugins

[zhu kane]

Daniel, thanks for your information.

I had a look at the issue 14616, looks like the major issue of it had been
fixed for a while. Only two edge cases are still opening. I did upgrade the
existing plugins via the official Jenkins update site, not manually
updating them. Not sure if they are the same problem.

Kane

https://vme360.com

On Sun, Oct 2, 2016 at 5:29 AM, Daniel Beck  wrote:

>
> > On 01.10.2016, at 08:22, zhu kane  wrote:
> >
> > Anyway the partial upgrading of plugins should not break the plugin
> loading.
>
> Tracked as JENKINS-14616
>
> --
> 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/EB0414C8-B534-4DDE-8C3F-55A4F1B737CF%40beckweb.net.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Jenkins 2.7.4 fails to load some plugins

[zhu kane]

I worked it out!

The system log of Jenkins showed me the hints. The problematic git client
plugin and parameter plugin were not loaded due to missing dependencies
plugins, such as git plugin and build step plugin. Reinstalling the missing
plugins fixed the problem.

It's really strange why the git plugin and so on became uninstalled. I
recall some plugins failed to be upgraded due to network issue. Anyway the
partial upgrading of plugins should not break the plugin loading.


Kane

https://vme360.com

On Sat, Oct 1, 2016 at 1:23 AM, zhu kane  wrote:

> I'm using official docker image(2.7.4) to launch Jenkins CI. The Jenkins
> data locates in external disk and is mounted by container. I use Jenkins in
> this way for more than a year. The original version was 1.6.x LTS, I always
> upgrade Jenkins to new LTS version bi-weekly or monthly. But after
> restarting the container today, Jenkins informs me that some job config
> data is unreadable. The error message looks like below,
>
> *CannotResolveClassException: hudson.plugins.git.GitSCM,
> CannotResolveClassException:
> com.cloudbees.jenkins.plugins.BitBucketTrigger,
> CannotResolveClassException:
> hudson.plugins.emailext.ExtendedEmailPublisher,
> CannotResolveClassException:
> hudson.plugins.parameterizedtrigger.BuildTrigger*
>
> However the git plugin(2.0.0) already is listed as installed. There was no
> luck after I manually downgraded it to 1.21.0. I also checked the jar file
> /plugins/git/WEB-INF/lib/git.jar, it's a valid jar file.
> And the GitSCM.class can be found inside it. I'm wondering why those
> classes can not be resolved.
>
> This error definitely breaks CI/CD of my project. The git and triggering
> downstream totally does not work now.
>
> Is there any way to fix it?
>
> Thanks.
>
> Kane
>
> https://vme360.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/CAM%2BCGXS2BtDn%3DFNfxBaMMxLUD13iiy40980TvG47%3DNSxkgpaCw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Jenkins 2.7.4 fails to load some plugins

[zhu kane]

I'm using official docker image(2.7.4) to launch Jenkins CI. The Jenkins
data locates in external disk and is mounted by container. I use Jenkins in
this way for more than a year. The original version was 1.6.x LTS, I always
upgrade Jenkins to new LTS version bi-weekly or monthly. But after
restarting the container today, Jenkins informs me that some job config
data is unreadable. The error message looks like below,

*CannotResolveClassException: hudson.plugins.git.GitSCM,
CannotResolveClassException:
com.cloudbees.jenkins.plugins.BitBucketTrigger,
CannotResolveClassException:
hudson.plugins.emailext.ExtendedEmailPublisher,
CannotResolveClassException:
hudson.plugins.parameterizedtrigger.BuildTrigger*

However the git plugin(2.0.0) already is listed as installed. There was no
luck after I manually downgraded it to 1.21.0. I also checked the jar file
/plugins/git/WEB-INF/lib/git.jar, it's a valid jar file. And
the GitSCM.class can be found inside it. I'm wondering why those classes
can not be resolved.

This error definitely breaks CI/CD of my project. The git and triggering
downstream totally does not work now.

Is there any way to fix it?

Thanks.

Kane

https://vme360.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/CAM%2BCGXQRjBUyHZ0sGtBkdSABWw7Se%3DqHDNdXbvaQxMpJnxTVhQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Remote build with token parameter crashing

[zhu kane]

IMO the remote api of parameter build does not work if you enabled
authentication, there is no workaround especially you are using oauth2.

You can workaround it via Build Token Root plugin.

https://wiki.jenkins-ci.org/display/JENKINS/Build+Token+Root+Plugin


Kane

On Wed, Sep 16, 2015 at 1:30 AM, John Marks  wrote:

> I'm using the following linux command line to do a remote build using
> Jenkins version 1.613
>
> curl -X POST
> http://gmastst-app2.cadm.harvard.edu:8915/jenkins/job/build-gmas-entity-service/build
> --data token=gmasbuild
>
> What I get looks like a long HTML response that's expecting a log in
> followed by a stack trace which says it can't find method
> java.net.URLEncoder.encode().
>
> A similar command line (host, build name and token differ) run against
> version 1.541 works flawlessly. I've tried the above using both Java 1.7.
> and 1.8 with the same result.
>
> Can someone help me figure out what might be wrong?
>
> --
> 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/4dfba08f-9091-43fb-a5b1-aa63a6ec8224%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Intermittently met 404 when fetch /queue/item//api/json

[zhu kane]

Daniel,

Thanks for your explanation.

Looks like it is not easy to track the final build number if it's scheduled
via remote api.

The caller only receives the queue item after scheduling a new build. And
the queue item which is corresponding to the new build will be removed in 5
minutes after the scheduled build is started or canceled. However it's
impossible for caller to point out the certain time when the queue item
lefts queue. The scheduled new build might be ran immediately, or wait for
minutes, hours or even longer. Looks like the caller has to continuously
poll the queue item url every N(<300) seconds.

Is it correct? or do you know another more efficient and reliable way to
track the final build state which is scheduled via remote api?


Kane

On Sun, Sep 13, 2015 at 9:29 AM, Daniel Beck  wrote:

>
> On 12.09.2015, at 11:41, zhu kane  wrote:
>
> > Does it mean the third party who are using remote APIs to track the job
> information having to fetch the corresponding job information via queue
> item in 3 minutes?
>
> It's five minutes, otherwise you're right.
>
> > What will happen if the queue item is blocked than 3 minutes due to no
> available executor or quiet time exceeding 3 minutes? They will be removed
> as well?
>
> This caches only "left items", i.e. those that left the queue (canceled or
> building), starting the moment they leave the queue.
>
> --
> 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/FC8C2B4A-90F8-4624-8F83-B88E762D023B%40beckweb.net
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Intermittently met 404 when fetch /queue/item//api/json

[zhu kane]

After browsing the source code, I found below code changed by kohsuke in
Queue.java[1],

+// private final FifoMap leftItems = new
FifoMap(256);+ private final Cache
leftItems = CacheBuilder.newBuilder().expireAfterWrite(5*60, TimeUnit.
SECONDS).build();


A fixed size map was replaced by a cache which drops the items that lives
more than 3 minutes.

Does it mean the third party who are using remote APIs to track the job
information having to fetch the corresponding job information via queue
item in 3 minutes?

What will happen if the queue item is blocked than 3 minutes due to no
available executor or quiet time exceeding 3 minutes? They will be removed
as well?

Thanks.

[1]
https://github.com/jenkinsci/jenkins/commit/84a259388c0a1a0d7e70b3d870c10f52e1205c8b#diff-7e8de48a31688987a2521079ff3828b9R177



Kane

On Fri, Sep 11, 2015 at 2:11 PM, zhu kane  wrote:

> I am using Jenkins LTS 1.609.2. My app heavily depends on Jenkins remote
> APIs to run new job then fetch the job result later.
>
> I noticed the Jenkins server throws 404 not found error when fetching the
> detail job information via queue item API.
>
> The Jenkins server was not restarted and always runs well.
>
> From the log of my app, I could see the 404 responses few times, it does
> not always happens. However it occurred again in few queue number.
>
> I know there is a known bug JENKINS-27256 that had been fixed in 1.603.
> Looks like they are different issues. Does Jenkins only store queue item
> records in memory? I observed the queue number reseted after restarting
> Jenkins server. And is Jenkins using weak or soft reference to keep the
> queue item records? So they might lost if GC happens.
>
> *Failed to fetch job status from   queue url
> 'http://127.0.0.1:/queue/item/378/
> <http://127.0.0.1:/queue/item/378/>', received code '404' and message
> '*
>
> *63736 *
>
> *63737 *
>
> *63738 Error 404 Not Found*
>
> *63739 *
>
> *63740 HTTP ERROR 404*
>
> *63741 Problem accessing /queue/item/378/api/json. Reason:*
>
> *63742 Not FoundPowered by
> Jetty://*
>
> *...*
>
> *HTTP ERROR 404*
>
> *63830 Problem accessing /queue/item/382/api/json. Reason:*
> *...*
>
> *64224 HTTP ERROR 404*
>
> *64225 Problem accessing /queue/item/389/api/json. Reason:*
>
> Kane
>

-- 
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/CAM%2BCGXSy8OXUmXyP%2BoTY%2BBfDme5hA82dG%3DaZkudO9NsR57G0sg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Intermittently met 404 when fetch /queue/item//api/json

[zhu kane]

I am using Jenkins LTS 1.609.2. My app heavily depends on Jenkins remote
APIs to run new job then fetch the job result later.

I noticed the Jenkins server throws 404 not found error when fetching the
detail job information via queue item API.

The Jenkins server was not restarted and always runs well.

>From the log of my app, I could see the 404 responses few times, it does
not always happens. However it occurred again in few queue number.

I know there is a known bug JENKINS-27256 that had been fixed in 1.603.
Looks like they are different issues. Does Jenkins only store queue item
records in memory? I observed the queue number reseted after restarting
Jenkins server. And is Jenkins using weak or soft reference to keep the
queue item records? So they might lost if GC happens.

*Failed to fetch job status from   queue url
'http://127.0.0.1:/queue/item/378/
', received code '404' and message
'*

*63736 *

*63737 *

*63738 Error 404 Not Found*

*63739 *

*63740 HTTP ERROR 404*

*63741 Problem accessing /queue/item/378/api/json. Reason:*

*63742 Not FoundPowered by
Jetty://*

*...*

*HTTP ERROR 404*

*63830 Problem accessing /queue/item/382/api/json. Reason:*
*...*

*64224 HTTP ERROR 404*

*64225 Problem accessing /queue/item/389/api/json. Reason:*

Kane

-- 
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/CAM%2BCGXTNQoDVHcZ6aUEz6efMfBJNTh_PbNwsXx_xEVN4ANnfRw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

linux daemon exits unexpected after jenkins completes the shell script

[zhu kane]

I put below simple script in 'Execute shell' block,

*daemon --name=test-daemon -- sleep 200*
*sleep 60*

The process 'daemon' and 'sleep 200' should exit after 200 seconds the
'sleep' exits. The jenkins job will be finished in 60 secs.

*jenkins   9954  9950  0 21:48 ?00:00:00 sleep 60*
*jenkins   9955 1  0 21:48 ?00:00:00 daemon —name=test-daemon —
sleep 200*
*jenkins   9956  9955  0 21:48 ?00:00:00 sleep 200*

Above is the process info queried via ps command. The father pid of daemon
is 1, not the script generated by jenkins.

But both the process 'daemon' and 'sleep 200' immediately exited when the
script finished.

It's something really strange. Does Jenkins automatically kill all child
processes forked by the script in build step? Did anybody suffer this
before? How did you resolve it?

p.s: Everything works fine if I ran above script in a linux shell.

Kane Zhu

-- 
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/CAM%2BCGXR0Ekbb-arQKCuHXwXCfVHmK0shxsV05rYdYej9njhM5g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: SWTBot

[zhu kane]

Assuming you are running under Linux.

Use vnc plug-in to create X env in your job that will run swtbot tests.

Then connect the port via vncviewer.


Kane


On Tue, Nov 12, 2013 at 11:24 PM, Brosh, Yossi  wrote:

>  Thanks a lot Gergely Nagy !!!
>
>
>
> The plugin seems not working with SWTBot .
>
>
>
> Yes – I mean to see SWTBot clicking around my  GUI app- I am working with
> windows 7 .
>
>
>
> BR
>
> Yossi
>
>
>
> *From:* jenkinsci-users@googlegroups.com [mailto:
> jenkinsci-users@googlegroups.com] *On Behalf Of *Gergely Nagy
> *Sent:* Tuesday 12 November 2013 16:58
> *To:* jenkinsci-users@googlegroups.com
> *Subject:* Re: SWTBot
>
>
>
> Do you mean seeing the test progress?
> https://wiki.jenkins-ci.org/display/JENKINS/Test+In+Progress+Plugin
>
>
>
> Or do you mean seeing SWTBot clicking around on your GUI app? It's
> possible too depending on your platform (e.g xvnc, etc..)
>
>
>
> On 12 November 2013 10:16, yossibr9876  wrote:
>
> Hi to all,
>
>
>
> i am trying to run SWTBot via Jenkins, can I see the UI tests running as a
> gui ?
>
>
>
> BR
>
> Yossi
>
> --
> 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.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
> --
> 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.
> For more options, visit https://groups.google.com/groups/opt_out.
>
> --
> 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.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Error running groovysh via jenkins-cli due to anonymous missing the Administrator permission

[zhu kane]

Had you reported bug for this issue?

On Friday, May 11, 2012 1:26:49 AM UTC+8, Carlton Brown wrote:
>
> Running groovysh via the SSH server doesn't seem to work.   It returns an 
> exit 255 with no output.The who-am-i command shows i'm authenticated.
>
> On Wed, May 2, 2012 at 10:15 AM, Carlton Brown 
> 
> > wrote:
>
>> Thanks for the explanation, I will try that.
>>
>>
>> On Wed, May 2, 2012 at 3:44 AM, Daniel PETISME 
>> 
>> > wrote:
>>
>>> The groovysh command seems broken with the jenkins-cli.jar.
>>> if you use a "recent" version of Jenkins you should use the Jenkins SSH 
>>> server to invoke the groovysh command. 
>>>
>>> https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+SSH
>>> http://kohsuke.org/2011/12/27/jenkins-now-acts-as-an-ssh-daemon/
>>>
>>> Cheers
>>> Daniel
>>>
>>> Le jeudi 26 avril 2012 17:23:50 UTC+2, Carlton Brown a écrit :
>>>
 I wish to use groovysh to interact directly with Jenkins.   Does it 
 work?

 On Wed, Apr 25, 2012 at 4:58 PM, Daniel PETISME 
 
 > wrote:

> Hi Carlton, 
>
> Jenkins-cli seems to have some issues concerning authentication. 
> Groovysh allows you to interact directly with the Jenkins JVM using the 
> goovy language.
>
> If you don't need this "interaction" prefer the groovy command as a 
> possible workaround
>
>
> For instance.
>
> $ java -jar jenkins-cli.jar -s http://localhost:8080/jenkins/ -i 
>  groovy test_script.gsh
> Enter passphrase for :
> ant - 1.1
> javadoc - 1.0
> Jenkins CVS Plug-in - 1.6
> Maven Integration plugin - 1.460
> Jenkins SSH Slaves plugin - 0.21
> Jenkins Subversion Plug-in - 1.34
> Jenkins Translation Assistance plugin - 1.8
>
> and the test_script.gsh is reusing your command "jenkins.model.Jenkins.
> **instance.pluginManager.**plugins.each { println("${it.longName} - 
> ${it.version}") }"
>
> I try to add more details concerning jenkins-cli.jar tool: Jenkins 
> CLI in Dev 
> ML
>
> To skip the step of the creation of a groovy script file for each 
> command, the usage talks about a pramater "=" to write the command in 
> stdin.
>
> Cheers
>
> Daniel
>
>
> On Wednesday, April 25, 2012 4:27:14 PM UTC+2, Carlton Brown wrote:
>>
>> Steps to reproduce:
>> 1:  set up an SSH key under my username 
>> 2:  verified that I am authenticated:  java -jar jenkins-cli.jar -s 
>> http://myserver/jenkins  **wh**o-am-i
>>  Authenticated as: myuser
>> Authorities:
>> authenticated
>> 3:  tried to run a trivial script via groovysh and got an error
>>   java -jar jenkins-cli.jar -s 
>> http://myserver/jenkins
>>  **gro**ovysh 
>> 'jenkins.model.Jenkins.**instanc**e.pluginManager.**plugins.each 
>> { println("${it.longName} - ${it.version}") };'
>> Exception in thread "main" java.lang.reflect.**UndeclaredTh**
>> rowableException
>> at $Proxy2.main(Unknown Source)
>> at hudson.cli.CLI.execute(CLI.**jav**a:271)
>>  at hudson.cli.CLI._main(CLI.java:417)
>> at hudson.cli.CLI.main(CLI.java:**3**22)
>> Caused by: hudson.remoting.**ProxyException**: hudson.security.**
>> AccessDeniedEx**ception2: anonymous is missing the Administer 
>> permission
>>  at hudson.security.ACL.**checkPermi**ssion(ACL.java:53)
>> at hudson.model.Node.**checkPermiss**ion(Node.java:381)
>>  at hudson.cli.GroovyshCommand.**mai**n(GroovyshCommand.java:61)
>>  at hudson.cli.CliManagerImpl.**main**(CliManagerImpl.java:92)
>> at sun.reflect.**GeneratedMethodAcc**essor5352.**invoke(Unknown 
>> Source)
>>  at sun.reflect.**DelegatingMethodAc**cessorImpl.**invoke(**
>> DelegatingMe**thodAccessorImpl.**java:43)
>> at java.lang.reflect.Method.**invok**e(Method.java:601)
>>  at hudson.remoting.**RemoteInvocati**onHandler$**RPCRequest.perform(
>> **R**emoteInvocationHandler.java:**27**4)
>> at hudson.remoting.**RemoteInvocati**onHandler$**RPCRequest.call(**
>> Remo**teInvocationHandler.java:**255)
>>  at hudson.remoting.**RemoteInvocati**onHandler$**RPCRequest.call(**
>> Remo**teInvocationHandler.java:**215)
>> at hudson.remoting.UserRequest.**pe**rform(UserRequest.java:118)
>>  at hudson.remoting.UserRequest.**pe**rform(UserRequest.java:48)
>> at hudson.remoting.Request$2.run(Request.java:287)
>>  at hudson.remoting.**InterceptingEx**ecutorService$1.**call(**
>> Intercept**ingExecutorService.**java:72)
>> at hudson.cli.CliManagerImpl$1.**ca**ll(CliManagerImpl.java:63)
>>  at hudson.remoting.**InterceptingEx**ecutorService$2.**call(**
>> Intercept**ingExecutorService.**java:95)
>> at java.util.concurrent.**FutureTas**k$Sync.innerRun(**FutureTask.**
>> java:334)
>>  at java.