Possible infrastructure compromise

[R. Tyler Croy]

Last week, the infrastructure team identified the potential compromise of a key
infrastructure machine. This compromise could have taken advantage of, what I
could be categorized as, an attempt to target contributors with elevated
access. Unfortunately, when facing the uncertainty of a potential compromise,
the safest option is to treat it as if it were an actual incident, and react
accordingly. The machine in question had access to binaries published to our
primary and secondary mirrors and contributor account information.

Since this machine is not the source of truth for Jenkins binaries, we verified
that the files distributed to Jenkins users: plugins, packages, etc, were not
tampered with. We cannot, however, verify that contributor account information
was not accessed or tampered with and, as a proactive measure, we are issuing a
password reset for all contributor accounts. We have also spent significant
effort migrating all key services off of the potentially compromised machine to
(virtual) hardware so the machine can be re-imaged or decommissioned entirely.

WHAT YOU SHOULD DO NOW
--


If you have ever filed an issue in JIRA, edited a wiki page, released a plugin
or otherwise created an account via the Jenkins website, you have a Jenkins
community account. You should be receiving a password reset email shortly, but
if you have re-used your Jenkins account password with other services we
strongly encourage you to update your passwords with those other services. If
you’re not already using one, we also encourage the use of a password manager
for generating and managing service-specific passwords.

This does not apply to your own Jenkins installation, or any account that you
may use to log into it. If you do not have a Jenkins community account, there
is no action you need to take.


WHAT WE'RE DOING TO PREVENT EVENTS LIKE THIS IN THE FUTURE
--

As stated above, the potentially compromised machine is being removed from our
infrastructure. That helps address the immediate problem but doesn’t put
guarantees in place for the future. To help prevent potential issues in the
future we’re taking the following actions:

* Incorporating more security policy enforcement into our Puppet-driven
  infrastructure. Without a configuration management tool enforcing a given 
state
  for some legacy services, user error and manual mis-configurations can
  adversely affect project security. As of right now, all key services are
  managed by Puppet.

* Balkanizing our machine and permissions model more. The machine affected was
  literally the first independent (outside of Sun) piece of project
  infrastructure and like many legacy systems, it grew to host a multitude of
  services. We are rapidly evolving away from that model with increasing levels
  of user and host separation for project services.

* In a similar vein, we have also introduced a trusted zone in our 
infrastructure
  which is not routable on the public internet, where sensitive operations, such
  as generating update center information, can be managed and secured more
  effectively.

* We are performing an infrastructure permissions audit. Some portions of our
  infrastructure are 6+ years old and have had contributors come and go. Any
  inactive users with unnecessarily elevated permissions in the project
  infrastructure will have those permissions revoked.


I would like to extend thanks, on behalf of the Jenkins project, to CloudBees
for their help in funding and migrating this infrastructure.

If you have further questions about the Jenkins project infrastructure, you can
join us in the #jenkins-infra channel on Freenode or in an Infrastructure Q
session I’ve scheduled for next Wednesday (April 27) at 20:00 UTC (12:00 PST).



Cheers
- R. Tyler Croy

--
 Code: 
  Chatter: 

  % gpg --keyserver keys.gnupg.net --recv-key 3F51E16F
--

-- 
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/20160423000623.GG23033%40blackberry.coupleofllamas.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: GPG signatures on http://repo.jenkins-ci.org/ incorrect?

[Steven Clark]

On Friday, April 22, 2016 at 6:03:08 PM UTC-4, Daniel Beck wrote:
>
>
> > On 22.04.2016, at 17:02, Steven Clark  
> wrote: 
> > 
> > Is anyone else aware that the GPG signatures seem to be faulty on the 
> repo? Or am I not verifying them correctly? 
>
> You're right. Something's wrong with KK's machine doing the signing (his 
> local Maven repo is affected as well). I'm filing INFRA issues so we get 
> this fixed. 
>
> Note that `jarsigner --verify` still works, so there's still a code 
> integrity check you can do. 
>
>
Great thanks for following up and letting me know about jarsigner as a 
workaround for now.

Regards,
-Steven 

-- 
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/3081c141-2f77-4e99-8600-79d7a149068e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Extracting credentials from Jenkins server

[Jakov Sosic]

Hi guys,

I'm trying to extract credentials from Jenkins server and migrate them to a 
new server I'm setting up. I don't want to simply copy whole 
/var/lib/jenkins directory, because I inherited an instance which isn't 
documented very well.

I'm trying to rectify that by migrating step by step and documenting stuff 
in the process, but the credentials part is really hard. I did manage to 
extract all the username/password combinations by using fake build plan 
which would echo them to log, but the issue I'm having problem the most are 
the SSH keys.

Is there a way to extract SSH keys?


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/9acff7de-dcfc-4df2-8a76-e721320ff8de%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GPG signatures on http://repo.jenkins-ci.org/ incorrect?

[Kohsuke Kawaguchi]

I figured out what was wrong. During the release process, GPG signing 
happened before jarsigner happened.

jarsigner inserts the signature into the war file, which changes the war. 
So the signature became invalid.

In 2.0 release, jarsigner somehow run before gpg, so it produced the 
correct signature.

I don't know how to force this ordering to Maven. I'll ask around.


On Friday, April 22, 2016 at 3:03:08 PM UTC-7, Daniel Beck wrote:
>
>
> > On 22.04.2016, at 17:02, Steven Clark  wrote: 
> > 
> > Is anyone else aware that the GPG signatures seem to be faulty on the 
> repo? Or am I not verifying them correctly? 
>
> You're right. Something's wrong with KK's machine doing the signing (his 
> local Maven repo is affected as well). I'm filing INFRA issues so we get 
> this fixed. 
>
> Note that `jarsigner --verify` still works, so there's still a code 
> integrity check you can do. 
>
>

-- 
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/7e89469f-cfb7-4fb1-ad3b-08142a0cb298%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GPG signatures on http://repo.jenkins-ci.org/ incorrect?

[Daniel Beck]

> On 22.04.2016, at 17:02, Steven Clark  wrote:
> 
> Is anyone else aware that the GPG signatures seem to be faulty on the repo? 
> Or am I not verifying them correctly?

You're right. Something's wrong with KK's machine doing the signing (his local 
Maven repo is affected as well). I'm filing INFRA issues so we get this fixed.

Note that `jarsigner --verify` still works, so there's still a code integrity 
check you can do.

-- 
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/DECFE445-3D8A-4F88-A021-89B1F5B09CF8%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.

Re: A program accessible directly on MAC system is reported as "command not found"

[Daniel Beck]

> On 22.04.2016, at 19:47, Naveen G.M.  wrote:
> 
> When I extended the same job to run on a MAC system, the MAC job is failing 
> by saying "command not found".
> If I login directly on the MAC system and run the same command, it runs 
> without any problems.

Your script expects maya to be on the PATH but it's not applied to Jenkins, 
probably because you modify it for a specific (different) user, or in .bashrc, 
or a similar approach.

-- 
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/CE96BF01-D68C-4B4A-88CF-7730F2162255%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.

Re: why is the groovy code failing in jenkins?

[Daniel Beck]

> On 22.04.2016, at 17:03, ok999  wrote:
> 
> Is this issue intermittent by any chance ? I thought i got it working 
> yesterday (the looping part) thanks to stackoverflow but it wont perform the 
> loop today (on a friday!!!) 

No. However, there was a version of the 'Pipeline: Groovy' plugin (2.0) in 
which this was fixed, unfortunately this resulted in more severe problems, so 
it had to be reverted in 2.1.

https://wiki.jenkins-ci.org/display/JENKINS/Pipeline+Groovy+Plugin

-- 
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/8406392A-7709-444B-BBF1-E40A94EA6782%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.

Re: Under Jenkins SignTool Error "No certificates were found", works fine logged on as user

[Vikram Parthasarathy]

My dongle is from Symantec. When I spoke to them about this last year, they
didn't have much help to offer. Please let me know if you find something.

On Fri, Apr 22, 2016 at 3:37 PM, Tim Mills <
tmi...@citystateentertainment.com> wrote:

> My understanding was that a certain category of Safenet dongles could be
> configured to be "rdp enabled" though I'm not certain this is something
> digicert, or the dongles they issue, are capable of.  My hope was that Ed's
> solution would magically circumvent this limitation.  I'm also in the
> process of talking to verisign/symantec to see if their hardware solution
> handles jenkins/CI any better.
>
> On 4/22/2016 4:33 PM, Vikram Parthasarathy wrote:
>
> I've had the same experience. The dongle cannot be used from an RDP
> session. And RDPing into the machine will require the password to be
> re-entered. I spoke to the vendor (Safenet) and they said RDP is not
> supported and it was intentionally done for security purposes.
>
> On Fri, Apr 22, 2016 at 3:20 PM, Tim Mills <
> tmi...@citystateentertainment.com> wrote:
>
>> I'm investigating this solution and I'm curious if you know if RDPing
>> into the box will cause bad things to happen?  My experience has been that
>> the dongle doesn't work for RDP users and each time I RDP into the box I
>> have to re-enter the password by logging into a local session.  I'm worried
>> that this would cause code signing to fail if a build happens to sign while
>> someone is RDPd in.
>>
>> On Thursday, August 27, 2015 at 11:55:57 AM UTC-4, Ed of the Mountain
>> wrote:
>>>
>>> Solved.
>>>
>>> Disable jenkins service and replace with slave-agent.jnlp.
>>>
>>> Yay! I finally have automatic EV code signing!
>>>
>>> -Ed
>>>
>>>
>>> On Thursday, August 27, 2015 at 9:51:29 AM UTC-5, Ed of the Mountain
>>> wrote:

 When I try to code sign in my Jenkins job I receive a SignTool error:

  c:\jenkins\workspace\codesign-windows>

 signtool sign /t http://timestamp.digicert.com /n "Acme Inc." code.exe

 SignTool Error: No certificates were found that met all the given criteria.

 I am using a DigiCert Extend Validation ( EV ) USB token that requires the 
 USB token be connected to the build machine.  This works fine when logged 
 on as normal user.

- I am running Jenkins as a Windows service.
- Service Log On is set to Local System account.
- Service is *allowed to interact with desktop.*

 When I logon as a normal user to the build machine, it works fine.

 1 - signtool sign /t http://timestamp.digicert.com /n "Acme Inc." code.exe

 2 - This triggers a pop-up "Token Logon" dialog that requires user 
 interaction

 3 - I have a separate "Token Logon" watcher that finds the WIndows ID and 
 enters password.

 4 - C
 ode is signed automatically

 C:\jenkins\workspace\codesign-windows>signtool sign /t 
 http://timestamp.digicert
 .com /n "The Charles Machine Works, Inc." token-logon.exe
 Done Adding Additional Store
 Successfully signed: token-logon.exe

 Any suggestions to try are much appreciated,

 -Ed

 --
>> 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/RQyUWZilrRE/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/91f3155f-6b7c-4b39-b8c0-db31a0f7d008%40googlegroups.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> 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/RQyUWZilrRE/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/CADE%2BD%2BVq8CepSpWLmYpqM05q6aOFFc-cZFfj0NwZUcYT%2B%2BRteg%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> 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/RQyUWZilrRE/unsubscribe.
> 

Re: Under Jenkins SignTool Error "No certificates were found", works fine logged on as user

[Tim Mills]

My understanding was that a certain category of Safenet dongles could be 
configured to be "rdp enabled" though I'm not certain this is something 
digicert, or the dongles they issue, are capable of. My hope was that 
Ed's solution would magically circumvent this limitation.  I'm also in 
the process of talking to verisign/symantec to see if their hardware 
solution handles jenkins/CI any better.


On 4/22/2016 4:33 PM, Vikram Parthasarathy wrote:
I've had the same experience. The dongle cannot be used from an RDP 
session. And RDPing into the machine will require the password to be 
re-entered. I spoke to the vendor (Safenet) and they said RDP is not 
supported and it was intentionally done for security purposes.


On Fri, Apr 22, 2016 at 3:20 PM, Tim Mills 
> wrote:


I'm investigating this solution and I'm curious if you know if
RDPing into the box will cause bad things to happen?  My
experience has been that the dongle doesn't work for RDP users and
each time I RDP into the box I have to re-enter the password by
logging into a local session.  I'm worried that this would cause
code signing to fail if a build happens to sign while someone is
RDPd in.

On Thursday, August 27, 2015 at 11:55:57 AM UTC-4, Ed of the
Mountain wrote:

Solved.

Disable jenkins service and replace with slave-agent.jnlp.

Yay! I finally have automatic EV code signing!

-Ed


On Thursday, August 27, 2015 at 9:51:29 AM UTC-5, Ed of the
Mountain wrote:

When I try to code sign in my Jenkins job I receive a
SignTool error:

c:\jenkins\workspace\codesign-windows>

signtool sign /thttp://timestamp.digicert.com 
  /n "Acme Inc." code.exe

SignTool Error: No certificates were found that met all the given 
criteria.

I am using a DigiCert Extend Validation ( EV ) USB token
that requires the USB token be connected to the build
machine.  This works fine when logged on as normal user.

  * I am running Jenkins as a Windows service.
  * Service Log On is set to Local System account.
  * Service is *_allowed to interact with desktop._*

When I logon as a normal user to the build machine, it works fine.

1 - signtool sign /thttp://timestamp.digicert.com 
  /n "Acme Inc." code.exe

2 - This triggers a pop-up "Token Logon" dialog that requires user 
interaction

3 - I have a separate "Token Logon" watcher that finds the WIndows 
ID and enters password.

4 - Code is signed automatically

C:\jenkins\workspace\codesign-windows>signtool sign /t
http://timestamp.digicert .com /n "The Charles Machine
Works, Inc." token-logon.exe Done Adding Additional Store
Successfully signed: token-logon.exe

Any suggestions to try are much appreciated,

-Ed

-- 
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/RQyUWZilrRE/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/91f3155f-6b7c-4b39-b8c0-db31a0f7d008%40googlegroups.com

.
For more options, visit https://groups.google.com/d/optout.


--
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/RQyUWZilrRE/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/CADE%2BD%2BVq8CepSpWLmYpqM05q6aOFFc-cZFfj0NwZUcYT%2B%2BRteg%40mail.gmail.com 
.

For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "Jenkins 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 

Re: Under Jenkins SignTool Error "No certificates were found", works fine logged on as user

[Vikram Parthasarathy]

I've had the same experience. The dongle cannot be used from an RDP
session. And RDPing into the machine will require the password to be
re-entered. I spoke to the vendor (Safenet) and they said RDP is not
supported and it was intentionally done for security purposes.

On Fri, Apr 22, 2016 at 3:20 PM, Tim Mills <
tmi...@citystateentertainment.com> wrote:

> I'm investigating this solution and I'm curious if you know if RDPing into
> the box will cause bad things to happen?  My experience has been that the
> dongle doesn't work for RDP users and each time I RDP into the box I have
> to re-enter the password by logging into a local session.  I'm worried that
> this would cause code signing to fail if a build happens to sign while
> someone is RDPd in.
>
> On Thursday, August 27, 2015 at 11:55:57 AM UTC-4, Ed of the Mountain
> wrote:
>>
>> Solved.
>>
>> Disable jenkins service and replace with slave-agent.jnlp.
>>
>> Yay! I finally have automatic EV code signing!
>>
>> -Ed
>>
>>
>> On Thursday, August 27, 2015 at 9:51:29 AM UTC-5, Ed of the Mountain
>> wrote:
>>>
>>> When I try to code sign in my Jenkins job I receive a SignTool error:
>>>
>>>
>>> c:\jenkins\workspace\codesign-windows>
>>>
>>> signtool sign /t http://timestamp.digicert.com /n "Acme Inc." code.exe
>>>
>>> SignTool Error: No certificates were found that met all the given criteria.
>>>
>>>
>>> I am using a DigiCert Extend Validation ( EV ) USB token that requires the 
>>> USB token be connected to the build machine.  This works fine when logged 
>>> on as normal user.
>>>
>>>
>>>- I am running Jenkins as a Windows service.
>>>- Service Log On is set to Local System account.
>>>- Service is *allowed to interact with desktop.*
>>>
>>>
>>>
>>> When I logon as a normal user to the build machine, it works fine.
>>>
>>>
>>> 1 - signtool sign /t http://timestamp.digicert.com /n "Acme Inc." code.exe
>>>
>>> 2 - This triggers a pop-up "Token Logon" dialog that requires user 
>>> interaction
>>>
>>> 3 - I have a separate "Token Logon" watcher that finds the WIndows ID and 
>>> enters password.
>>>
>>> 4 - Code is signed automatically
>>>
>>>
>>> C:\jenkins\workspace\codesign-windows>signtool sign /t 
>>> http://timestamp.digicert
>>> .com /n "The Charles Machine Works, Inc." token-logon.exe
>>> Done Adding Additional Store
>>> Successfully signed: token-logon.exe
>>>
>>>
>>> Any suggestions to try are much appreciated,
>>>
>>>
>>> -Ed
>>>
>>> --
> 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/RQyUWZilrRE/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/91f3155f-6b7c-4b39-b8c0-db31a0f7d008%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/CADE%2BD%2BVq8CepSpWLmYpqM05q6aOFFc-cZFfj0NwZUcYT%2B%2BRteg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Under Jenkins SignTool Error "No certificates were found", works fine logged on as user

[Tim Mills]

I'm investigating this solution and I'm curious if you know if RDPing into 
the box will cause bad things to happen?  My experience has been that the 
dongle doesn't work for RDP users and each time I RDP into the box I have 
to re-enter the password by logging into a local session.  I'm worried that 
this would cause code signing to fail if a build happens to sign while 
someone is RDPd in.

On Thursday, August 27, 2015 at 11:55:57 AM UTC-4, Ed of the Mountain wrote:
>
> Solved.
>
> Disable jenkins service and replace with slave-agent.jnlp.
>
> Yay! I finally have automatic EV code signing!
>
> -Ed
>
>
> On Thursday, August 27, 2015 at 9:51:29 AM UTC-5, Ed of the Mountain wrote:
>>
>> When I try to code sign in my Jenkins job I receive a SignTool error:
>>
>>
>> c:\jenkins\workspace\codesign-windows>
>>
>> signtool sign /t http://timestamp.digicert.com /n "Acme Inc." code.exe 
>>
>> SignTool Error: No certificates were found that met all the given criteria.
>>
>>
>> I am using a DigiCert Extend Validation ( EV ) USB token that requires the 
>> USB token be connected to the build machine.  This works fine when logged on 
>> as normal user.
>>
>>
>>- I am running Jenkins as a Windows service.
>>- Service Log On is set to Local System account.
>>- Service is *allowed to interact with desktop.*
>>
>>
>>
>> When I logon as a normal user to the build machine, it works fine.
>>
>>
>> 1 - signtool sign /t http://timestamp.digicert.com /n "Acme Inc." code.exe
>>
>> 2 - This triggers a pop-up "Token Logon" dialog that requires user 
>> interaction
>>
>> 3 - I have a separate "Token Logon" watcher that finds the WIndows ID and 
>> enters password.
>>
>> 4 - Code is signed automatically
>>
>>
>> C:\jenkins\workspace\codesign-windows>signtool sign /t 
>> http://timestamp.digicert
>> .com /n "The Charles Machine Works, Inc." token-logon.exe
>> Done Adding Additional Store
>> Successfully signed: token-logon.exe
>>
>>
>> Any suggestions to try are much appreciated,
>>
>>
>> -Ed
>>
>>

-- 
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/91f3155f-6b7c-4b39-b8c0-db31a0f7d008%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing git build creds

[Larry Martell]

I already did that. How can I see what it's getting "Permission denied" on?

On Fri, Apr 22, 2016 at 1:34 PM, Indra Gunawan (ingunawa)
 wrote:
> Don’t you need to upload the SSH public key of the build user to your
> github?
>
> From:  on behalf of Larry Martell
> 
> Reply-To: "jenkinsci-users@googlegroups.com"
> 
> Date: Friday, April 22, 2016 at 9:20 AM
> To: "jenkinsci-users@googlegroups.com" 
> Subject: Changing git build creds
>
> I am a new user to Jenkins, so please bear with me.
>
> The employee who set up Jenkins quit and we removed his access to our github
> repo. But he had configured our automated build to access git as himself, so
> of course that is failing now. I went into the project settings and added a
> new credential for a user that does have access to our github repo, along
> with their github password. Now when the build runs I get this:
>
> Permission denied (publickey).
>
> What else do I have to do to switch the user that accesses our repo for
> builds?
>
> 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/CACwCsY619h54uNkMQxZ3xGmN3edyD%3DE_vCMW7iXVJhT%2BMfJvdg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

A program accessible directly on MAC system is reported as "command not found"

[Naveen G.M.]

Hi, 

Jenkins Version : Jenkins ver. 1.638

I have configured a Jenkins Matrix Job which is running file on Windows 
system.
When I extended the same job to run on a MAC system, the MAC job is failing 
by saying "command not found".
If I login directly on the MAC system and run the same command, it runs 
without any problems.

Can anyone tell me what could be wrong. The complete log of build is as 
follows.

Started by upstream project "TallyWorld_Win_MultiNode_09 
"
 build number 21 

originally caused by:
 Started by user Naveen G M 

[EnvInject] - Loading node environment variables.
Building remotely on TW_Mac_01 
 (Mac1 
TW_Mac32_Build TW_Mac64_Build TallyWorld Mac) in workspace 
/users/buildmgr/jenkins_slave/workspace/TallyWorld_Win_MultiNode_09/Artefact/TW_Artefact/Diagnostic/Standard/NodeLabel/TW_Mac32_Build/Optimization/Debug
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url 
 > ssh://git@10.20.65.66/srv/Users/naveen.gm/pop.TallyWorld.git # timeout=10
Fetching upstream changes from 
ssh://git@10.20.65.66/srv/Users/naveen.gm/pop.TallyWorld.git
 > git --version # timeout=10
using GIT_SSH to set credentials 
 > git -c core.askpass=true fetch --tags --progress 
 > ssh://git@10.20.65.66/srv/Users/naveen.gm/pop.TallyWorld.git 
 > +refs/heads/*:refs/remotes/origin/*
Checking out Revision edf6f3bb847a67021a02c15ad5330df83f94e91e 
(refs/remotes/origin/Jenkins_Daily_Build)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f edf6f3bb847a67021a02c15ad5330df83f94e91e
 > git rev-list edf6f3bb847a67021a02c15ad5330df83f94e91e # timeout=10
[EnvInject] - Executing scripts and injecting environment variables after the 
SCM step.
[EnvInject] - Evaluation the following Groovy script content: 
import java.text.SimpleDateFormat
def map = [ "BUILD_TIMESTAMP":new SimpleDateFormat("-MM-dd").format(new 
Date()) ]; 
if ((NodeLabel=="TW_Lin32_Build") || (NodeLabel=="TW_Mac32_Build") || 
(NodeLabel=="TW_Win32_Build"))
 map.put("Bitness","32"); 
if ((NodeLabel=="TW_Lin64_Build") || (NodeLabel=="TW_Mac64_Build") || 
(NodeLabel=="TW_Win64_Build"))
 map.put("Bitness","64");

return map; 

[Debug] $ /bin/sh -xe 
/var/folders/sd/j4k_9f217252c2d1c5y01qb0gr/T/hudson4532749190972800024.sh
+ echo buildmgr
buildmgr
+ pwd
/Users/buildmgr/jenkins_slave/workspace/TallyWorld_Win_MultiNode_09/Artefact/TW_Artefact/Diagnostic/Standard/NodeLabel/TW_Mac32_Build/Optimization/Debug
+ echo 'C:\Program' 'Files\Java\jdk1.8.0_60/bin:/usr/bin:/bin:/usr/sbin:/sbin'
C:\Program Files\Java\jdk1.8.0_60/bin:/usr/bin:/bin:/usr/sbin:/sbin
+ maya -f .manage/config.maya buildfullclean fullclean
/var/folders/sd/j4k_9f217252c2d1c5y01qb0gr/T/hudson4532749190972800024.sh: 
line 5: maya: command not found
Build step 'Execute shell' marked build as failure
[WARNINGS] Skipping publisher since build result is FAILURE
Sending e-mails to: naveen...@tallysolutions.com
Finished: FAILURE


With Regards,

Naveen GM



-- 
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/87d0b8e0-edee-41e5-ade6-c353f6cf042f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing git build creds

[Indra Gunawan (ingunawa)]

Don't you need to upload the SSH public key of the build user to your github?

From: 
> on 
behalf of Larry Martell 
>
Reply-To: 
"jenkinsci-users@googlegroups.com" 
>
Date: Friday, April 22, 2016 at 9:20 AM
To: "jenkinsci-users@googlegroups.com" 
>
Subject: Changing git build creds

I am a new user to Jenkins, so please bear with me.

The employee who set up Jenkins quit and we removed his access to our github 
repo. But he had configured our automated build to access git as himself, so of 
course that is failing now. I went into the project settings and added a new 
credential for a user that does have access to our github repo, along with 
their github password. Now when the build runs I get this:

Permission denied (publickey).

What else do I have to do to switch the user that accesses our repo for builds?

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/96ae7a96-6f75-4d94-a344-1dae736b44d8%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/D33FAE1F.507FD%25ingunawa%40cisco.com.
For more options, visit https://groups.google.com/d/optout.

Changing git build creds

[Larry Martell]

I am a new user to Jenkins, so please bear with me. 

The employee who set up Jenkins quit and we removed his access to our 
github repo. But he had configured our automated build to access git as 
himself, so of course that is failing now. I went into the project settings 
and added a new credential for a user that does have access to our github 
repo, along with their github password. Now when the build runs I get this:

Permission denied (publickey).

What else do I have to do to switch the user that accesses our repo for 
builds? 

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/96ae7a96-6f75-4d94-a344-1dae736b44d8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: why is the groovy code failing in jenkins?

[ok999]

Is this issue intermittent by any chance ? I thought i got it working 
yesterday (the looping part) thanks to stackoverflow but it wont perform 
the loop today (on a friday!!!) 


node('windows') {
checkout([$class: 'GitSCM', branches: [[name: '*/master']], 
doGenerateSubmoduleConfigurations: false, extensions: [], submoduleCfg: [], 
userRemoteConfigs: [[credentialsId: 'cca9c557-65b8-4c72-9176-f78d91c22907', 
url: 'g...@github.com:RocketScienceProjects/testrobocopy.git']]])

def paths = ['folder1', 'folder2', 'folder3']
def dirs = ['dst1', 'dst2', 'dst3']
   [paths, dirs].transpose().each { pd ->
 def path = pd[0]
 def dir = pd[1]
  bat "xcopy %cd%\\${path} C:\\${dir} /E /Y /V"
  bat "(robocopy %cd%\\${path} C:\\${dir}\\temp lab.conf) ^& IF 
%ERRORLEVEL% LEQ 7 exit 0"
}
 }


PS: please dont worry abt the batch commands, they doesnt make sense. i am 
just trying to get the loop rolling :)



On Thursday, April 21, 2016 at 3:33:45 PM UTC-5, ok999 wrote:
>
> This a very basic test code for the pipleine job
>
>
> node('windows') {
> checkout([$class: 'GitSCM', branches: [[name: '*/master']], 
> doGenerateSubmoduleConfigurations: false, extensions: [], submoduleCfg: [], 
> userRemoteConfigs: [[credentialsId: 'cca9c557-65b8-4c72-9176-f78d', url: 
> 'g...@github.com:SomeProjects/trobocopy.git']]])
>
>
> def pathMap = ['folder1':'dst1', 'folder2':'dst2', 'folder3':'dst3', 
> 'folder4':'dst4'] 
>   pathMap.each { path, dir -> 
>bat "xcopy %cd%${path} C:\\${dir} /E /Y /V" 
>  }
> }
>
>
> The jenkins console shows 
>
> [Pipeline] End of Pipelinejava.io.NotSerializableException: 
> java.util.LinkedHashMap$Entry
>   at 
> org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:860)
>   at 
> org.jboss.marshalling.river.BlockMarshaller.doWriteObject(BlockMarshaller.java:65)
>   at 
> org.jboss.marshalling.river.BlockMarshaller.writeObject(BlockMarshaller.java:56)
>   at 
> org.jboss.marshalling.MarshallerObjectOutputStream.writeObjectOverride(MarshallerObjectOutputStream.java:50)
>   at 
> org.jboss.marshalling.river.RiverObjectOutputStream.writeObjectOverride(RiverObjectOutputStream.java:179)
>   at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:343)
>   at java.util.HashMap.writeObject(HashMap.java:1129)
>   at sun.reflect.GeneratedMethodAccessor28.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>
>
>
>
> Caused by: an exception which occurred:
>   in field locals
>   in field parent
>   in field capture
>   in field def
>   in field closures
>   in object org.jenkinsci.plugins.workflow.cps.CpsThreadGroup@4d0c20da
> Finished: FAILURE
>
>

-- 
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/b847fd7d-f861-402f-b3d0-2f44198d182e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

GPG signatures on http://repo.jenkins-ci.org/ incorrect?

[Steven Clark]

Hello all,

Is anyone else aware that the GPG signatures seem to be faulty on the repo? 
Or am I not verifying them correctly?

gpg --verify jenkins-war-1.651.1.war.asc jenkins-war-1.651.1.war
gpg: Signature made Thu 14 Apr 2016 01:05:31 AM EDT using DSA key ID 
D50582E6
gpg: BAD signature from "Kohsuke Kawaguchi "


The files seem ok according to the sha1 files as well.

cat jenkins-war-1.651.1.war.sha1
31fcae60edba2ecb6c380c59f374761723981283

sha1sum jenkins-war-1.651.1.war
31fcae60edba2ecb6c380c59f374761723981283  jenkins-war-1.651.1.war

cat jenkins-war-1.651.1.war.asc
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEABECAAYFAlcPJRsACgkQm30y8tUFgubFegCeMp4oYrIZxbhKLMrzsFhEIxet
wfAAniNy42DycpcdSuuubZngegbJiCYp
=PVM5
-END PGP SIGNATURE-

cat jenkins-war-1.651.1.war.asc.sha1
5a3f4bf88da314079dfbc269f6ac0b359cc96938

sha1sum jenkins-war-1.651.1.war.asc
5a3f4bf88da314079dfbc269f6ac0b359cc96938  jenkins-war-1.651.1.war.asc

-Steven

-- 
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/7856451d-4ca4-49c8-9c49-c511252579c7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Grab'ing libraries in jenkins script console

[Guy Matz]

Anyone know how to get this - or an equivalent - to work in jenkins script
console?

@Grab(group='org.codehaus.groovy.modules.http-builder',
module='http-builder', version='0.7.2')
import groovyx.net.http.*

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

Re: https://updates.jenkins.io unstable?

[jbattle]

It's all better this morning - thanks for the quick reply!


On Friday, April 22, 2016 at 1:53:17 AM UTC-5, Daniel Beck wrote:
>
>
> > On 22.04.2016, at 08:16, Daniel Beck  
> wrote: 
> > 
> > workaround 
>
> Workout. It got a workout. 
>
> It's still early morning here :-) 
>
>

-- 
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/f5032972-697d-4ffa-a6b9-cc2a15be10df%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Git Plugin: merge before build not working?

['Björn Pedersen' via Jenkins Users]

Hi,

for me it wis working fine, although the setup is slightly different:

1) I have the full refspec specified: refs/...:refs/...
2) Additionally I use the gerrit trigger checkout strategy to really build 
a specific change.

checkout(changelog: false, poll: false, 
scm: [$class: 'GitSCM', 
branches: [[name: "$GERRIT_BRANCH"]], 
doGenerateSubmoduleConfigurations: false, submoduleCfg: [], 
userRemoteConfigs: [[refspec: 
GERRIT_REFSPEC+':'+GERRIT_REFSPEC, url: '']],

extensions:[[$class:'hudson.plugins.git.extensions.impl.BuildChooserSetting', 


buildChooser:[$class:"com.sonyericsson.hudson.plugins.gerrit.trigger.hudsontrigger.GerritTriggerBuildChooser"]
 
],
   [
$class: 'PreBuildMerge',
options: [
fastForwardMode: 'NO_FF',
mergeRemote: 'origin',
mergeStrategy: 'MergeCommand.Strategy',
mergeTarget: 'master'
]
] ]
])


$GERRIT_BRANCH is normal master, GERRIT_REFSPEC points at a specific 
change, like your pull request refspecs.

-- 
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/6a10e123-5825-455f-9c56-a1d9a0b2313f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Git Plugin: merge before build not working?

[David Karlsen]

Anyone got this to work? I'm running this in context of the multibranch 
pipeline plugin - so I'd like to get whatever branch is triggered to merge 
into an integration-branch before building, then pushing back to the 
integration branch if the build succeeds. 

torsdag 7. april 2016 03.13.37 UTC+2 skrev Martin d'Anjou følgende:
>
> I'm trying to get the Git Plugin to merge a branch to master before build, 
> in a Pipeline DSL script, but it's not convincingly working yet. After the 
> checkout step has run, a quick "git log --graph" command does not reveal a 
> merge. The Pipeline DSL code I have is:
>
> node {
> checkout([
> $class: 'GitSCM',
> branches: [[name: 'refs/heads/master']],
> userRemoteConfigs: [[
> name: 'origin',
> refspec: 'pull-requests/1/from',
> url: path
> ]],
> extensions:
> [[
> $class: 'PreBuildMerge',
> options: [
> fastForwardMode: 'NO_FF',
> mergeRemote: 'origin',
> mergeStrategy: 'MergeCommand.Strategy',
> mergeTarget: 'master'
> ]
> ]]
> ])
> sh 'git log -n 10 --graph --pretty=oneline --abbrev-commit --all 
> --decorate=full'
> }
>
> And the resulting log:
>
>  
>
> [Pipeline] checkout
>  > git rev-parse --is-inside-work-tree # timeout=10
> Fetching changes from the remote Git repository
>  > git config remote.origin.url /tmp/jenkins/upstream-repo # timeout=10
> Fetching upstream changes from /tmp/jenkins/upstream-repo
>  > git --version # timeout=10
>  > git -c core.askpass=true fetch --tags --progress 
> /tmp/jenkins/upstream-repo pull-requests/1/from
>  > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
>  > git rev-parse refs/remotes/origin/refs/heads/master^{commit} # timeout=10
> Merging Revision 19e39345b1b178e3ebc4c5b3af277cbd64c37f9f 
> (refs/remotes/origin/master) to origin/master, 
> UserMergeOptions{mergeRemote='origin', mergeTarget='master', 
> mergeStrategy='MergeCommand.Strategy', fastForwardMode='--no-ff'}
>  > git rev-parse origin/master^{commit} # timeout=10
>  > git config core.sparsecheckout # timeout=10
>  > git checkout -f origin/master
>  > git merge --no-ff 19e39345b1b178e3ebc4c5b3af277cbd64c37f9f # timeout=10
>  > git rev-parse HEAD^{commit} # timeout=10
> Seen branch in repository origin/HEAD
> Seen branch in repository origin/master
> Seen branch in repository origin/pull-requests/1/from
> Seen 3 remote branches
> Checking out Revision 19e39345b1b178e3ebc4c5b3af277cbd64c37f9f 
> (origin/master, origin/master)
>  > git config core.sparsecheckout # timeout=10
>  > git checkout -f 19e39345b1b178e3ebc4c5b3af277cbd64c37f9f
>  > git rev-list 19e39345b1b178e3ebc4c5b3af277cbd64c37f9f # timeout=10
>  > git rev-list 19e39345b1b178e3ebc4c5b3af277cbd64c37f9f # timeout=10
> [Pipeline] sh
> [workspace] Running shell script
> + git log -n 10 --graph --pretty=oneline --abbrev-commit --all --decorate=full
> * 3644c2e (refs/remotes/origin/pull-requests/1/from, 
> refs/remotes/origin/HEAD, refs/heads/pull-requests/1/from) Add file
> * 19e3934 (HEAD, refs/remotes/origin/master, refs/heads/master) init
>
>
> It should end with the git log showing a merge (3 commits), but it only 
> shows two commits. Full code 
>  and 
> log  
> as github gists.
>
> Anyone tried this yet? Any ideas?
>
> Thanks,
> Martin
>

-- 
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/63b49311-0b10-4555-896c-731c4a1823d5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: permission denied error when copying files in jenkins

[Alex Domoradov]

You can check in the server console

# su -l jenkins -s /bin/bash -c 'cp /location/path1/file1.txt 
/location2/path2/file1.txt'

On Thursday, April 21, 2016 at 11:53:59 PM UTC+3, Pradeep Patra wrote:
>
> Hi all,
> .  I have created a Jenkins server (master) and tried copying from one 
> location/path of jenkins server to another  location a Perl script within 
> the same server. I have changed all the file/ folders for Jenkins 
> user/group(chown,chgrp)and restarted the Jenkins server. While copying 
> files I an getting error " regular file cp failed: Permission denied error 
> after trigerring the Jenkins job which uses script to copy files. Can 
> anyone help in this please?
>
> Regards
> Pradeep
>

-- 
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/d34510b8-d16d-423e-8450-d3c93a38f913%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: SCM Poll fails using pipeline

[Nick Witkowski]

Never mind. I had the wrong/invalide credentials string the the git scm 
step.

On Friday, April 22, 2016 at 1:25:11 PM UTC+2, Nick Witkowski wrote:
>
> Hi,
>
> We're running Jenkins ver. 1.609.3 and I have a pipeline job that 
> registers for polling.
>
> Looking at the "Git Polling Log" I see a permission denied error:
>
> Started on Apr 22, 2016 7:06:00 AM
>
> Using strategy: Default
>
> [poll] Last Built Revision: Revision 256109511639dade5d95c561e54fffcc0e263cb0 
> (refs/remotes/origin/work/cascade)
>
>  > git --version # timeout=10
>
>  > git ls-remote -h git@mygithub:ORG/project.git # timeout=10
>
> ERROR: polling failed in 
> /app/jenkins/workspace/project-work-cascade-continuous on ab3-centos7-01
>
> hudson.util.IOException2 
> : 
> hudson.plugins.git.GitException: Command "git ls-remote -h 
> git@mygithub:ORG/project.git" returned status code 128:
>
> stdout: 
>
> stderr: Permission denied (publickey).
>
> fatal: The remote end hung up unexpectedly
>
>   at hudson.plugins.git.GitSCM.compareRemoteRevisionWith(GitSCM.java:529)
>
>   at 
> org.jenkinsci.plugins.workflow.job.WorkflowJob.poll(WorkflowJob.java:531)
>
>   at hudson.triggers.SCMTrigger$Runner.runPolling(SCMTrigger.java:510)
>
>   at hudson.triggers.SCMTrigger$Runner.run(SCMTrigger.java:539)
>
>   at 
> hudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:118)
>
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
>
>   at java.util.concurrent.FutureTask.run(FutureTask.java:262)
>
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>
>   at java.lang.Thread.run(Thread.java:744)
>
> Caused by: hudson.plugins.git.GitException: Command "git ls-remote -h 
> git@mygithub:ORG/project.git" returned status code 128:
>
> stdout: 
>
> stderr: Permission denied (publickey).
>
> fatal: The remote end hung up unexpectedly
>
>   at 
> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1640)
>
>   at 
> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1388)
>
>   at 
> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1282)
>
>   at 
> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1273)
>
>   at 
> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.getHeadRev(CliGitAPIImpl.java:2376)
>
>   at 
> hudson.plugins.git.GitSCM.compareRemoteRevisionWithImpl(GitSCM.java:583)
>
>   at hudson.plugins.git.GitSCM.compareRemoteRevisionWith(GitSCM.java:527)
>
>   ... 9 more
>
> Using strategy: Default
>
> [poll] Last Built Revision: Revision 256109511639dade5d95c561e54fffcc0e263cb0 
> (refs/remotes/origin/work/cascade)
>
>  > git --version # timeout=10
>
>  > git ls-remote -h git@mygithub:ORG/project.git # timeout=10
>
>
> Normally on job where the polling succeeds (a non pipeline job) I'd expect 
> the following:
>
> Started on Apr 22, 2016 7:02:00 AM
>
> Using strategy: Default
>
> [poll] Last Built Revision: Revision 9e4a511217a2af22478bf1f3959b449d30587981 
> (refs/remotes/origin/master)
>
> using *GIT_SSH* to set credentials 
>
>  > git --version # timeout=10
>
>  > git ls-remote -h git@mygithub:ORG/project.git # timeout=10
>
> Found 113 remote heads on git@mygithub:ORG/project.git
>
> [poll] Latest remote head revision on refs/heads/master is: 
> 9e4a511217a2af22478bf1f3959b449d30587981 - already built by 398
>
> Done. Took 0.36 sec
>
> No changes
>
>
> The main difference is that the job that succeeds uses GIT_SSH to set the 
> credentials. How do I set the GIT_SSH credentials for a pipeline script so 
> that polling works?
>
> Thanks,
>
> Nick
>

-- 
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/7d3e32f9-f5cd-40c8-bd52-7ab41b2ed5cc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

SCM Poll fails using pipeline

[Nick Witkowski]

Hi,

We're running Jenkins ver. 1.609.3 and I have a pipeline job that registers 
for polling.

Looking at the "Git Polling Log" I see a permission denied error:

Started on Apr 22, 2016 7:06:00 AM

Using strategy: Default

[poll] Last Built Revision: Revision 256109511639dade5d95c561e54fffcc0e263cb0 
(refs/remotes/origin/work/cascade)

 > git --version # timeout=10

 > git ls-remote -h git@mygithub:ORG/project.git # timeout=10

ERROR: polling failed in /app/jenkins/workspace/project-work-cascade-continuous 
on ab3-centos7-01

hudson.util.IOException2 
: 
hudson.plugins.git.GitException: Command "git ls-remote -h 
git@mygithub:ORG/project.git" returned status code 128:

stdout: 

stderr: Permission denied (publickey).

fatal: The remote end hung up unexpectedly

at hudson.plugins.git.GitSCM.compareRemoteRevisionWith(GitSCM.java:529)

at 
org.jenkinsci.plugins.workflow.job.WorkflowJob.poll(WorkflowJob.java:531)

at hudson.triggers.SCMTrigger$Runner.runPolling(SCMTrigger.java:510)

at hudson.triggers.SCMTrigger$Runner.run(SCMTrigger.java:539)

at 
hudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:118)

at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)

at java.util.concurrent.FutureTask.run(FutureTask.java:262)

at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)

at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)

at java.lang.Thread.run(Thread.java:744)

Caused by: hudson.plugins.git.GitException: Command "git ls-remote -h 
git@mygithub:ORG/project.git" returned status code 128:

stdout: 

stderr: Permission denied (publickey).

fatal: The remote end hung up unexpectedly

at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1640)

at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1388)

at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1282)

at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1273)

at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.getHeadRev(CliGitAPIImpl.java:2376)

at 
hudson.plugins.git.GitSCM.compareRemoteRevisionWithImpl(GitSCM.java:583)

at hudson.plugins.git.GitSCM.compareRemoteRevisionWith(GitSCM.java:527)

... 9 more

Using strategy: Default

[poll] Last Built Revision: Revision 256109511639dade5d95c561e54fffcc0e263cb0 
(refs/remotes/origin/work/cascade)

 > git --version # timeout=10

 > git ls-remote -h git@mygithub:ORG/project.git # timeout=10


Normally on job where the polling succeeds (a non pipeline job) I'd expect 
the following:

Started on Apr 22, 2016 7:02:00 AM

Using strategy: Default

[poll] Last Built Revision: Revision 9e4a511217a2af22478bf1f3959b449d30587981 
(refs/remotes/origin/master)

using *GIT_SSH* to set credentials 

 > git --version # timeout=10

 > git ls-remote -h git@mygithub:ORG/project.git # timeout=10

Found 113 remote heads on git@mygithub:ORG/project.git

[poll] Latest remote head revision on refs/heads/master is: 
9e4a511217a2af22478bf1f3959b449d30587981 - already built by 398

Done. Took 0.36 sec

No changes


The main difference is that the job that succeeds uses GIT_SSH to set the 
credentials. How do I set the GIT_SSH credentials for a pipeline script so 
that polling works?

Thanks,

Nick

-- 
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/d3930509-d9cc-407f-ba6e-a67ad39637e7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins 2.0: Turn off Setup wizard

[Stuart Warren]

Currently I'm creating 2 files:

/var/lib/jenkins/jenkins.install.UpgradeWizard.state
```
2.0
```

/var/lib/jenkins/init.groovy.d/basic-security.groovy
```
#!groovy

import jenkins.model.*
import hudson.security.*

def instance = Jenkins.getInstance()

println "--> creating local user 'admin'"

def hudsonRealm = new HudsonPrivateSecurityRealm(false)
hudsonRealm.createAccount('admin','admin')
instance.setSecurityRealm(hudsonRealm)

def strategy = new FullControlOnceLoggedInAuthorizationStrategy()
instance.setAuthorizationStrategy(strategy)
instance.save()
```

Which seems to do enough.

On 21 April 2016 at 19:20, Scott Cutler  wrote:

> Any updates on this? I am also deploying Jenkins as part of a Vagrant
> script that automatically downloads and deploys Jenkins to Tomcat, then
> immediately begins running jobs via the CLI. When my vagrant script
> downloaded the 2.0 release this morning, the new setup wizard essentially
> blocked the install script. It would be helpful to have a documented
> procedure on the Jenkins site to disable the setup wizard and provide the
> previous "it-just-works-without-authentication" functionality, provided the
> user has root shell access and can edit XMLs or provide JDK arguments.
>
> On Tuesday, April 5, 2016 at 9:09:30 AM UTC-7, Daniel Beck wrote:
>>
>>
>> On 05.04.2016, at 16:54, Stuart Warren  wrote:
>>
>> > Today is the first time I've tried groovy though, so probably doing
>> something silly.
>> > Are there any obvious improvements to the above?
>>
>> You could alternatively just go with patching the JENKINS_HOME so Jenkins
>> considers it not an update:
>>
>> $ echo -n 2.0 > $JENKINS_HOME/upgraded
>> $ echo -n 2.0 > $JENKINS_HOME/.last_exec_version
>>
>> The files are being renamed in
>> https://github.com/jenkinsci/jenkins/pull/2215, but for beta 2, the
>> above appears to work.
>>
>> But please note that this is considered internal storage so may not work
>> this way forever. I think we'll pretty quickly introduce a supported
>> alternative way though.
>>
>> --
> 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/Pb4QZVc2-f0/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/09d68a96-72a6-424f-a3aa-cf11e6bacf5c%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/CADHbheUp_9X%2BCZADnQi-mrbE%2B7FfghVhQWvJPQF%3D_ap0%2Bbh7Tw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: How many jobs can handle by Jenkins master?

[Stephen Connolly]

On 22 April 2016 at 07:24, dennys  wrote:

> We use Jenkins 1.554.3, I know it's old, we'll try to upgrade it.
> And most projects are Maven 2/3, I think we cannot disable fingerprint of
> Maven project, is it correct?
>

It is evil in many many ways:
http://javaadventure.blogspot.ie/2013/11/jenkins-maven-job-type-considered-evil.html
lists just some of the ways in which it is evil.

More critically for you, the fingerprinting of artifacts causes some
concurrency related locking that effectively hobbles the concurrent build
rate. It may have been fixed in newer versions, but I stay away from the
evil one so I cannot confirm.


>
> Btw, Jenkins copies all artifacts from slaves to master after build. Will
> it
> increase disk IO or network loading of Jenkins master?
>

Yes. However file copy is a more optimized path in the remoting protocol so
it should not be as bad... but if you are copying very large (think .iso
images) files it may be better to route around Jenkins remoting


>
>
>
> --
> View this message in context:
> http://jenkins-ci.361315.n4.nabble.com/How-many-jobs-can-handle-by-Jenkins-master-tp4808004p4808474.html
> Sent from the Jenkins users mailing list archive at Nabble.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/1461306253866-4808474.post%40n4.nabble.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/CA%2BnPnMyAh3G1R2xwC09s_o1cHi_hTmXFg3rqqb-OceGL53na4w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Regarding Jenkins Distributed build Vs Maven Parallel build

[Foyzul Hassan]

Hi All,

Seems that Maven automatically partitions source code and perform parallel 
processing software building and testing. Here is the reference link:

https://cwiki.apache.org/confluence/display/MAVEN/Parallel+builds+in+Maven+3

But for Jenkins whether this automatically partition the source code and 
build them in distributed manner? Please clarify the issue.

Regards,
Foyzul
 

On Monday, April 18, 2016 at 4:14:18 PM UTC-5, Foyzul Hassan wrote:
>
> Hi,
>
> For our research work we need to build large open source projects and in 
> that regard we are planning to have distributed Jenkins build system. But I 
> found that maven is already providing parallel build support. So, we 
> thinking about advantage of Jenkins Distributed build over maven parallel 
> build.
>
> Can you please clarify the advantage of Jenkins Distributed build over 
> maven parallel build as for distributed build there are some infrastructure 
> cost for distributed build?
>
>
> Thanks & Regard,
> Foyzul Hassan
>

-- 
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/dd45135c-27ec-48b9-bf79-a463335890a1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How many jobs can handle by Jenkins master?

[dennys]

We use Jenkins 1.554.3, I know it's old, we'll try to upgrade it.
And most projects are Maven 2/3, I think we cannot disable fingerprint of
Maven project, is it correct?

Btw, Jenkins copies all artifacts from slaves to master after build. Will it
increase disk IO or network loading of Jenkins master?



--
View this message in context: 
http://jenkins-ci.361315.n4.nabble.com/How-many-jobs-can-handle-by-Jenkins-master-tp4808004p4808474.html
Sent from the Jenkins users mailing list archive at Nabble.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/1461306253866-4808474.post%40n4.nabble.com.
For more options, visit https://groups.google.com/d/optout.

Re: https://updates.jenkins.io unstable?

[Daniel Beck]

> On 22.04.2016, at 08:16, Daniel Beck  wrote:
> 
> workaround

Workout. It got a workout.

It's still early morning here :-)

-- 
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/AC711CD2-4155-4D50-8DD7-D0137E424885%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.

Re: https://updates.jenkins.io unstable?

[Daniel Beck]

> On 22.04.2016, at 00:45, jbat...@civisanalytics.com wrote:
> 
> I saw someone else facing other network issues earlier today - maybe some of 
> the infrastructure is just in flux?

Turns out you weren't the only one downloading 2.0 and downloading plugins, so 
the infra got a good workaround. I know Tyler was working on it around time you 
wrote your email, and it seems better now, so it's likely fixed.

-- 
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/81356DA2-92E4-416A-B5A8-AB8C637E2950%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.