Re: Build Promotion and Copy Artifact: current build is overwritten

[bl0ck3r]

On Friday, August 17, 2012 5:56:29 PM UTC-4, qazwart wrote:
>
>
> On Aug 17, 2012, at 5:12 PM, bl0ck3r > 
> wrote: 
>
> > Well, I think what I am trying to achieve is simple: promote a build 
> while another build is running on the same project 
>
> Wait a second. Is the problem your copying in files to a project while a 
> build is running or copying files out of a build while a second build on 
> that project is running? 
>

What confused me is that the "Copy Artifact" (which is recommended by the 
Promoted Builds Plugin as the solution for not interfering with the 
workspace) does offer as a default value, the workspace as the target 
directory for the copy of the archived artifact. When I changed the target 
directory to be an absolute path outside of the workspace, it worked. This 
was counter intuitive to me.
 

>
> Anything you want to save should be "archived" which is a post build step. 
> Archived artifacts are kept for each build, so they're not overwritten when 
> a new build starts. You can copy out archived artifacts w/o affecting the 
> currently running build. 
>

Only if I the target directory for the copy is NOT the workspace.

Martin

RE: Active Directory authentication error with 1.466.1 LTS

[Dan Stine]

We also have this issue.  And it's filed as
https://issues.jenkins-ci.org/browse/JENKINS-14057

 

We're running 1.466.1.  These exceptions were in the log when we ran 1.448,
too, though there was no manifestation in the UI.

 

Dan

 

From: jenkinsci-users@googlegroups.com
[mailto:jenkinsci-users@googlegroups.com] On Behalf Of David Aldrich
Sent: Friday, August 17, 2012 9:25 AM
To: jenkinsci-users@googlegroups.com
Subject: Active Directory authentication error with 1.466.1 LTS

 

Hi

 

I am running Jenkins 1.466.1 LTS with Active Directory authentication.  The
authentication has been working correctly, but today I noticed the following
type of error in:

 

Manage Jenkins > Configure System > Authorization > Project-based Matrix
Authorization Strategy:

 

Failed to test the validity of the user name 
 (show details)

org.acegisecurity.BadCredentialsException: Failed to retrieve user
information for ; nested exception is javax.naming.NamingException:
[LDAP: error code 1 - : LdapErr: DSID-0C090627, comment: In order to
perform this operation a successful bind must be completed on the
connection., data 0, vece

 

I clicked 'Test' underneath 'Active Directory' and it gave an error.  I then
downgraded the Active Directory plugin from 1.29 to 1.19.  'Test' now
succeeds but the 'Project-based Matrix Authorization Strategy' area still
shows the above error against each user.

 

Any ideas how to fix this please?

 

Best regards

 

David

 

RE: Security Realm by Custom Script Plugin: Group Command Script

[Bowling, Brad]

Thanks Domi.  I'm using the role strategy plugin and its working great.  I 
appreciate your help.

-Original Message-
From: jenkinsci-users@googlegroups.com 
[mailto:jenkinsci-users@googlegroups.com] On Behalf Of domi
Sent: Saturday, August 18, 2012 2:36 PM
To: jenkinsci-users@googlegroups.com
Subject: Re: Security Realm by Custom Script Plugin: Group Command Script

you could use role strategy plugin to administrate the group/role assignments 
or just enter some group names where you usually add  single users in the 
security config.
https://wiki.jenkins-ci.org/display/JENKINS/Role+Strategy+Plugin
regards Domi


On 17.08.2012, at 23:01, "Bowling, Brad"  wrote:

> Domi,
> 
> In your example below, do you need to create the "admin" and  "superuser" 
> groups within Jenkins assigning various privileges to each?
> 
> -Brad
> 
> -Original Message-
> From: jenkinsci-users@googlegroups.com 
> [mailto:jenkinsci-users@googlegroups.com] On Behalf Of Bowling, Brad
> Sent: Wednesday, August 15, 2012 1:22 PM
> To: jenkinsci-users@googlegroups.com
> Subject: RE: Security Realm by Custom Script Plugin: Group Command Script
> 
> Thanks Domi.
> 
> -Original Message-
> From: jenkinsci-users@googlegroups.com 
> [mailto:jenkinsci-users@googlegroups.com] On Behalf Of domi
> Sent: Wednesday, August 15, 2012 1:13 PM
> To: jenkinsci-users@googlegroups.com
> Subject: Re: Security Realm by Custom Script Plugin: Group Command Script
> 
> I also updated the documentation: 
> https://wiki.jenkins-ci.org/display/JENKINS/Script+Security+Realm
> Domi
> 
> On 15.08.2012, at 19:05, domi  wrote:
> 
>> Hi Brad,
>> you'r right with the purpose of the group command script, thats exactly what 
>> it is for.
>> The script can be any kind of shell script and should return 0 for any 
>> successful execution.
>> a simple script would be like this:
>> 
>> #!/bin/sh
>> if [ "$U" == "domi" ]; then
>> echo "admin,superuser"
>> fi
>> 
>> Domi
>> 
>> On 14.08.2012, at 18:47, "Bowling, Brad"  
>> wrote:
>> 
>>> I am a system admin setting up Jenkins 1.477.  I have "Security Realm by 
>>> custom script" plugin installed so I can customize my user authentication.  
>>> My question concerns the Group Command script.  I am thinking that this 
>>> functionality provides a custom way to determine the group that a certain 
>>> user belongs to (I could be wrong).  I am wanting assign privileges based 
>>> on the group that the custom script determines they are in, i.e. admin, 
>>> user or Anonymous (guest).  Am I getting the purpose of the custom group 
>>> command script?  Would anyone happen to have such a script that they have 
>>> successfully implemented.  Any help will be greatly appreciated.
>>> 
>>> Thanks,
>>> Brad
>>> 
>>> --
>>> This message w/attachments (message) is intended solely for the use of the 
>>> intended recipient(s) and may contain information that is privileged, 
>>> confidential or proprietary. If you are not an intended recipient, please 
>>> notify the sender, and then please delete and destroy all copies and 
>>> attachments, and be advised that any review or dissemination of, or the 
>>> taking of any action in reliance on, the information contained in or 
>>> attached to this message is prohibited. 
>>> Unless specifically indicated, this message is not an offer to sell or a 
>>> solicitation of any investment products or other financial product or 
>>> service, an official confirmation of any transaction, or an official 
>>> statement of Sender. Subject to applicable law, Sender may intercept, 
>>> monitor, review and retain e-communications (EC) traveling through its 
>>> networks/systems and may produce any such EC to regulators, law 
>>> enforcement, in litigation and as required by law. 
>>> The laws of the country of each sender/recipient may impact the handling of 
>>> EC, and EC may be archived, supervised and produced in countries other than 
>>> the country in which you are located. This message cannot be guaranteed to 
>>> be secure or free of errors or viruses. 
>>> 
>>> References to "Sender" are references to any subsidiary of Bank of America 
>>> Corporation. Securities and Insurance Products: * Are Not FDIC Insured * 
>>> Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not 
>>> a Condition to Any Banking Service or Activity * Are Not Insured by Any 
>>> Federal Government Agency. Attachments that are part of this EC may have 
>>> additional important disclosures and disclaimers, which you should read. 
>>> This message is subject to terms available at the following link: 
> 
> 
>>> http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you 
>>> consent to the foregoing.
>> 
> 
> --
> This message w/attachments (message) is intended solely for the use of the 
> intended recipient(s) and may contain information that is pr

Re: Git plugin trigger of downstream is not building same branch

[Sami Tikka]

Maybe something has changed? Someone upgraded some Jenkins plugin or installed 
a new one or changed something in the job configuration.

I happen to know if you install the Workspace Cleanup plugin and configure a 
job to use it, it deletes the workspace and that somehow causes git plugin to 
get confused about which changes it has already seen and often it starts 
building the wrong branch.

-- Sami

Allen Bierbaum  kirjoitti 18.8.2012 kello 14.42:

> Our jenkins build process has been stable and working with no problems
> for the last 6 months or so.  We have a build monitor job that polls
> our git repository looking for changes and then triggers downstream
> jobs to build the given branch (using "Build other projects" post
> build action).  This allows us to queue up multiple build jobs run
> against the same git branch at the same time.  We do it this way to
> work around this known issue
> (https://issues.jenkins-ci.org/browse/JENKINS-7423) and to make sure
> we get all the builds we need.
> 
> This has been working well, but sometime in the last 2 weeks it
> stopped working.  What we are seeing now is that the monitoring job
> sees a change on a branch (ex: dev/new_featureA) but when it triggers
> the downstream job, that job normally picks up a different branch to
> build (ex: dev/new_featureB).
> 
> Has anyone else seen this behavior?  Is it expected?
> 
> Note we have also tried using the parameterized trigger plugin to pass
> the exact SHA hash to the downstream build.  This does force the
> correct commit to build, but it uses a detached HEAD, so we don't end
> up with a valid GIT_BRANCH environment variable during the build.  We
> use the branch name as part of our build process (and as part of our
> build name) so this doesn't work well for us either.  If there was a
> way to have the parameterized trigger pass along the correct
> GIT_BRANCH environment variable then this option would probably work
> great.
> 
> -Allen

Re: Security Realm by Custom Script Plugin: Group Command Script

[domi]

you could use role strategy plugin to administrate the group/role assignments 
or just enter some group names where you usually add  single users in the 
security config.
https://wiki.jenkins-ci.org/display/JENKINS/Role+Strategy+Plugin
regards Domi


On 17.08.2012, at 23:01, "Bowling, Brad"  wrote:

> Domi,
> 
> In your example below, do you need to create the "admin" and  "superuser" 
> groups within Jenkins assigning various privileges to each?
> 
> -Brad
> 
> -Original Message-
> From: jenkinsci-users@googlegroups.com 
> [mailto:jenkinsci-users@googlegroups.com] On Behalf Of Bowling, Brad
> Sent: Wednesday, August 15, 2012 1:22 PM
> To: jenkinsci-users@googlegroups.com
> Subject: RE: Security Realm by Custom Script Plugin: Group Command Script
> 
> Thanks Domi.
> 
> -Original Message-
> From: jenkinsci-users@googlegroups.com 
> [mailto:jenkinsci-users@googlegroups.com] On Behalf Of domi
> Sent: Wednesday, August 15, 2012 1:13 PM
> To: jenkinsci-users@googlegroups.com
> Subject: Re: Security Realm by Custom Script Plugin: Group Command Script
> 
> I also updated the documentation: 
> https://wiki.jenkins-ci.org/display/JENKINS/Script+Security+Realm
> Domi
> 
> On 15.08.2012, at 19:05, domi  wrote:
> 
>> Hi Brad,
>> you'r right with the purpose of the group command script, thats exactly what 
>> it is for.
>> The script can be any kind of shell script and should return 0 for any 
>> successful execution.
>> a simple script would be like this:
>> 
>> #!/bin/sh
>> if [ "$U" == "domi" ]; then
>> echo "admin,superuser"
>> fi
>> 
>> Domi
>> 
>> On 14.08.2012, at 18:47, "Bowling, Brad"  
>> wrote:
>> 
>>> I am a system admin setting up Jenkins 1.477.  I have "Security Realm by 
>>> custom script" plugin installed so I can customize my user authentication.  
>>> My question concerns the Group Command script.  I am thinking that this 
>>> functionality provides a custom way to determine the group that a certain 
>>> user belongs to (I could be wrong).  I am wanting assign privileges based 
>>> on the group that the custom script determines they are in, i.e. admin, 
>>> user or Anonymous (guest).  Am I getting the purpose of the custom group 
>>> command script?  Would anyone happen to have such a script that they have 
>>> successfully implemented.  Any help will be greatly appreciated.
>>> 
>>> Thanks,
>>> Brad
>>> 
>>> --
>>> This message w/attachments (message) is intended solely for the use of the 
>>> intended recipient(s) and may contain information that is privileged, 
>>> confidential or proprietary. If you are not an intended recipient, please 
>>> notify the sender, and then please delete and destroy all copies and 
>>> attachments, and be advised that any review or dissemination of, or the 
>>> taking of any action in reliance on, the information contained in or 
>>> attached to this message is prohibited. 
>>> Unless specifically indicated, this message is not an offer to sell or a 
>>> solicitation of any investment products or other financial product or 
>>> service, an official confirmation of any transaction, or an official 
>>> statement of Sender. Subject to applicable law, Sender may intercept, 
>>> monitor, review and retain e-communications (EC) traveling through its 
>>> networks/systems and may produce any such EC to regulators, law 
>>> enforcement, in litigation and as required by law. 
>>> The laws of the country of each sender/recipient may impact the handling of 
>>> EC, and EC may be archived, supervised and produced in countries other than 
>>> the country in which you are located. This message cannot be guaranteed to 
>>> be secure or free of errors or viruses. 
>>> 
>>> References to "Sender" are references to any subsidiary of Bank of America 
>>> Corporation. Securities and Insurance Products: * Are Not FDIC Insured * 
>>> Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not 
>>> a Condition to Any Banking Service or Activity * Are Not Insured by Any 
>>> Federal Government Agency. Attachments that are part of this EC may have 
>>> additional important disclosures and disclaimers, which you should read. 
>>> This message is subject to terms available at the following link: 
> 
> 
>>> http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you 
>>> consent to the foregoing.
>> 
> 
> --
> This message w/attachments (message) is intended solely for the use of the 
> intended recipient(s) and may contain information that is privileged, 
> confidential or proprietary. If you are not an intended recipient, please 
> notify the sender, and then please delete and destroy all copies and 
> attachments, and be advised that any review or dissemination of, or the 
> taking of any action in reliance on, the information contained in or attached 
> to this message is prohibited. 
> Unless specifically indica

Re: cannot install msbuild plugin...

[waysys]

>
> I am having a similar problem.
>  
>
Jenkins Version:  J*enkins ver. 1.477*  
Browser:  Internet Explorer 9
Symptom:
 
1. Select a plugin to install on Available tab.
2. Click either Install Without Restart or Download and Install after 
Restart.
3. Nothing happens.
 
IE security has been reduced to lowest level.
 
Thanx for any suggestions.

Re: Why might hostname not be fully qualified

[John R. Cary]

Nevermind.   Found it on configuration page.

On 8/18/12 7:38 AM, John R. Cary wrote:

When jenkins runs on one of my machines, the URLs are not
with fully qualified domainnames, e.g.,

JOB_URL =http://cerb:8300/job/bilderall-abs/./label=master/
instead of

JOB_URL =http://cerb.mydomain.com:8300/job/bilderall-abs/./label=master/

I have checked that `hostname` gives a fully qualified domain name.

Any ideas?

(I am running Jenkins ver. 1.477 on RHEL 6.2, with
jre-1.6.0-openjdk.x86_64)

Thx.John

Why might hostname not be fully qualified

[John R. Cary]

When jenkins runs on one of my machines, the URLs are not
with fully qualified domainnames, e.g.,

JOB_URL =http://cerb:8300/job/bilderall-abs/./label=master/  


instead of

JOB_URL =http://cerb.mydomain.com:8300/job/bilderall-abs/./label=master/  


I have checked that `hostname` gives a fully qualified domain name.

Any ideas?

(I am running Jenkins ver. 1.477 on RHEL 6.2, with
jre-1.6.0-openjdk.x86_64)

Thx.John

Git plugin trigger of downstream is not building same branch

[Allen Bierbaum]

Our jenkins build process has been stable and working with no problems
for the last 6 months or so.  We have a build monitor job that polls
our git repository looking for changes and then triggers downstream
jobs to build the given branch (using "Build other projects" post
build action).  This allows us to queue up multiple build jobs run
against the same git branch at the same time.  We do it this way to
work around this known issue
(https://issues.jenkins-ci.org/browse/JENKINS-7423) and to make sure
we get all the builds we need.

This has been working well, but sometime in the last 2 weeks it
stopped working.  What we are seeing now is that the monitoring job
sees a change on a branch (ex: dev/new_featureA) but when it triggers
the downstream job, that job normally picks up a different branch to
build (ex: dev/new_featureB).

Has anyone else seen this behavior?  Is it expected?

Note we have also tried using the parameterized trigger plugin to pass
the exact SHA hash to the downstream build.  This does force the
correct commit to build, but it uses a detached HEAD, so we don't end
up with a valid GIT_BRANCH environment variable during the build.  We
use the branch name as part of our build process (and as part of our
build name) so this doesn't work well for us either.  If there was a
way to have the parameterized trigger pass along the correct
GIT_BRANCH environment variable then this option would probably work
great.

-Allen

Re: 'This node is offline because it uses old slave.jar'

[Richard Bywater]

What version did you upgrade from?

Richard.

On Sat, Aug 18, 2012 at 4:36 AM, Lata Kopalle  wrote:
> I just updated Jenkins Master to 1.447.
> All the nodes went offline.
> Jenkins is installed as a windows service on these nodes.
> I've stopped the service, and gave the jnlp command as follows:
> javaws http://localhost:8080/computer//slave-agent.jnlp
> Restarted the service.
> But nothing happens.
>
> found this but no resolution to it:
> https://issues.jenkins-ci.org/browse/JENKINS-10985
>
> does anyone know how to fix this? (ofcourse it's really urgent, :-) )