AW: Jenkins CLI user gets locked in Active Directory
So, I tried again with the new Active Directory plugin. When using our Service_Build user, there is no authentication request coming into Active Directory, which is how it should be. So the problem was the old, buggy Active Directory plugin. Thanks for the help & best regards, Eric -Ursprüngliche Nachricht- Von: jenkinsci-users@googlegroups.com [mailto:jenkinsci-users@googlegroups.com] Im Auftrag von Lewis, Eric Gesendet: Montag, 11. Juni 2012 17:08 An: jenkinsci-users@googlegroups.com Betreff: AW: Jenkins CLI user gets locked in Active Directory Ok, upgrading to the latest Active Directory plugin solves at least the problem in the Jenkins configuration page. I'll check tomorrow about the rest of the problem. Best regards, Eric -Ursprüngliche Nachricht- Von: jenkinsci-users@googlegroups.com [mailto:jenkinsci-users@googlegroups.com] Im Auftrag von Lewis, Eric Gesendet: Montag, 11. Juni 2012 14:14 An: jenkinsci-users@googlegroups.com Betreff: AW: Jenkins CLI user gets locked in Active Directory Ok, I checked with our sysadmin, but there's not more information in the logs. However, another problem, which I postponed, may be the cause. As I mentioned, we're using Active Directory for authentification. In the Jenkins config, I'm using the Matrix-based security. Since we installed the new version, I always see errors in the GUI and in the log. For instance, for the mentioned Service_Build user, I see: Failed to test the validity of the user name Service_Build org.acegisecurity.BadCredentialsException: Failed to retrieve user information for Service_Build; nested exception is javax.naming.NamingException: [LDAP: error code 1 - 04DC: LdapErr: DSID-0C0906E8, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v1db1]; remaining name 'DC=ipie,DC=ch' at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:231) at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:130) at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:95) at hudson.plugins.active_directory.AbstractActiveDirectoryAuthenticationProvider.loadUserByUsername(AbstractActiveDirectoryAuthenticationProvider.java:27) at hudson.plugins.active_directory.ActiveDirectorySecurityRealm.loadUserByUsername(ActiveDirectorySecurityRealm.java:551) at hudson.security.GlobalMatrixAuthorizationStrategy$DescriptorImpl.doCheckName_(GlobalMatrixAuthorizationStrategy.java:304) at hudson.security.GlobalMatrixAuthorizationStrategy$DescriptorImpl.doCheckName(GlobalMatrixAuthorizationStrategy.java:288) at sun.reflect.GeneratedMethodAccessor3018.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:288) at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:151) at org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:90) at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:111) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659) at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:241) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:488) at org.kohsuke.stapler.Stapler.service(Stapler.java:162) at javax.servlet.http.HttpServlet.service(HttpServlet.java:45) at winstone.ServletConfiguration.execute(ServletConfiguration.java:248) at winstone.RequestDispatcher.forward(RequestDispatcher.java:333) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:376) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:95) at hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:74) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98) at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47) at wi
AW: Jenkins CLI user gets locked in Active Directory
Ok, upgrading to the latest Active Directory plugin solves at least the problem in the Jenkins configuration page. I'll check tomorrow about the rest of the problem. Best regards, Eric -Ursprüngliche Nachricht- Von: jenkinsci-users@googlegroups.com [mailto:jenkinsci-users@googlegroups.com] Im Auftrag von Lewis, Eric Gesendet: Montag, 11. Juni 2012 14:14 An: jenkinsci-users@googlegroups.com Betreff: AW: Jenkins CLI user gets locked in Active Directory Ok, I checked with our sysadmin, but there's not more information in the logs. However, another problem, which I postponed, may be the cause. As I mentioned, we're using Active Directory for authentification. In the Jenkins config, I'm using the Matrix-based security. Since we installed the new version, I always see errors in the GUI and in the log. For instance, for the mentioned Service_Build user, I see: Failed to test the validity of the user name Service_Build org.acegisecurity.BadCredentialsException: Failed to retrieve user information for Service_Build; nested exception is javax.naming.NamingException: [LDAP: error code 1 - 04DC: LdapErr: DSID-0C0906E8, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v1db1]; remaining name 'DC=ipie,DC=ch' at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:231) at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:130) at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:95) at hudson.plugins.active_directory.AbstractActiveDirectoryAuthenticationProvider.loadUserByUsername(AbstractActiveDirectoryAuthenticationProvider.java:27) at hudson.plugins.active_directory.ActiveDirectorySecurityRealm.loadUserByUsername(ActiveDirectorySecurityRealm.java:551) at hudson.security.GlobalMatrixAuthorizationStrategy$DescriptorImpl.doCheckName_(GlobalMatrixAuthorizationStrategy.java:304) at hudson.security.GlobalMatrixAuthorizationStrategy$DescriptorImpl.doCheckName(GlobalMatrixAuthorizationStrategy.java:288) at sun.reflect.GeneratedMethodAccessor3018.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:288) at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:151) at org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:90) at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:111) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659) at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:241) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:488) at org.kohsuke.stapler.Stapler.service(Stapler.java:162) at javax.servlet.http.HttpServlet.service(HttpServlet.java:45) at winstone.ServletConfiguration.execute(ServletConfiguration.java:248) at winstone.RequestDispatcher.forward(RequestDispatcher.java:333) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:376) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:95) at hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:74) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98) at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84) at hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:166) at hudson.security.C
AW: Jenkins CLI user gets locked in Active Directory
ilter.java:87) at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:173) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at jenkins.security.ApiTokenFilter.doFilter(ApiTokenFilter.java:61) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249) at hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionContextIntegrationFilter2.java:66) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76) at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at winstone.RequestDispatcher.forward(RequestDispatcher.java:331) at winstone.RequestHandlerThread.processRequest(RequestHandlerThread.java:215) at winstone.RequestHandlerThread.run(RequestHandlerThread.java:138) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at winstone.BoundedExecutorService$1.run(BoundedExecutorService.java:77) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Caused by: javax.naming.NamingException: [LDAP: error code 1 - 04DC: LdapErr: DSID-0C0906E8, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v1db1]; remaining name 'DC=ipie,DC=ch' at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3107) at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3013) at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2820) at com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1829) at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1752) at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1769) at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:394) at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:376) at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:358) at hudson.plugins.active_directory.LDAPSearchBuilder.search(LDAPSearchBuilder.java:52) at hudson.plugins.active_directory.LDAPSearchBuilder.searchOne(LDAPSearchBuilder.java:42) at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:191) ... 70 more The users however can very well log into Jenkins and are authenticated. Also the Active Directory test in the config works. I postponed this error because people can still work, but it's still an error. And I see the same whenever I try to do something with the Service_Build user. So maybe this is the root cause of my problems? It looks like it's a known issue: https://issues.jenkins-ci.org/browse/JENKINS-12619 Best regards, Eric -Ursprüngliche Nachricht- Von: jenkinsci-users@googlegroups.com [mailto:jenkinsci-users@googlegroups.com] Im Auftrag von Lewis, Eric Gesendet: Freitag, 8. Juni 2012 16:56 An: jenkinsci-users@googlegroups.com Betreff: AW: Jenkins CLI user gets locked in Active Directory I don't see that file. I'll have to check with our Linux admin on Monday. Best regards, Eric -Ursprüngliche Nachricht- Von: Alex Earl [mailto:slide.o@gmail.com] Gesendet: Freitag, 8. Juni 2012 16:45 An: Lewis, Eric; jenkinsci-users@googlegroups.com Betreff: RE: Jenkins CLI user gets locked in Active Directory Usually they are in /var/log I believe. Look for auth.log or something similar Sent from my Windows Phone From: Lewis, Eric Sent: 6/8/2012 7:33 AM To: jenkinsci-users@googlegroups.com Subject: AW: Jenkins CLI user gets locked in Active Directory Oh... :-) Well, I'm not really a Linux guru, so could you tell me where I find those logs? (Also, I'm n
AW: Jenkins CLI user gets locked in Active Directory
I don't see that file. I'll have to check with our Linux admin on Monday. Best regards, Eric -Ursprüngliche Nachricht- Von: Alex Earl [mailto:slide.o@gmail.com] Gesendet: Freitag, 8. Juni 2012 16:45 An: Lewis, Eric; jenkinsci-users@googlegroups.com Betreff: RE: Jenkins CLI user gets locked in Active Directory Usually they are in /var/log I believe. Look for auth.log or something similar Sent from my Windows Phone From: Lewis, Eric Sent: 6/8/2012 7:33 AM To: jenkinsci-users@googlegroups.com Subject: AW: Jenkins CLI user gets locked in Active Directory Oh... :-) Well, I'm not really a Linux guru, so could you tell me where I find those logs? (Also, I'm not root either) Best regards, Eric -Ursprüngliche Nachricht- Von: Alex Earl [mailto:slide.o@gmail.com] Gesendet: Freitag, 8. Juni 2012 16:23 An: Lewis, Eric; jenkinsci-users@googlegroups.com Betreff: RE: Jenkins CLI user gets locked in Active Directory I was meaning the logs on the Linux machine. Sent from my Windows Phone From: Lewis, Eric Sent: 6/8/2012 7:06 AM To: jenkinsci-users@googlegroups.com Subject: AW: Jenkins CLI user gets locked in Active Directory Ok, I'll have to check (on Monday) with our Windows admins, since I don't have access to those logs. Best regards, Eric -Ursprüngliche Nachricht- Von: Alex Earl [mailto:slide.o@gmail.com] Gesendet: Freitag, 8. Juni 2012 16:00 An: Lewis, Eric; jenkinsci-users@googlegroups.com Betreff: RE: Jenkins CLI user gets locked in Active Directory Can you check the logs for authentication and see if AD is being tried before the key based auth? Sent from my Windows Phone From: Lewis, Eric Sent: 6/8/2012 6:32 AM To: jenkinsci-users@googlegroups.com Subject: AW: Jenkins CLI user gets locked in Active Directory Sorry! :-) Yes, Jenkins is running on Red Hat Linux (apparently Red Hat Enterprise Linux Server release 5.8 (Tikanga)) Best regards, Eric -Ursprüngliche Nachricht- Von: jenkinsci-users@googlegroups.com [mailto:jenkinsci-users@googlegroups.com] Im Auftrag von Slide Gesendet: Freitag, 8. Juni 2012 15:30 An: jenkinsci-users@googlegroups.com Betreff: Re: Jenkins CLI user gets locked in Active Directory Is this running on Linux? More information about your platforms and such would be useful. On Tue, Jun 5, 2012 at 5:58 AM, Lewis, Eric wrote: > Hi > > We have a user called Service_Build which is used for issuing Jenkins CLI > commands (either in bash or in Jenkins). > This user is defined in Active Directory, which is what we use for > authentication. So normally, I can log in as this user and I have > administrator rights in Jenkins. > > I followed the documentation in the Jenkins wiki and (with help from Rob > Mandeville) managed to authenticate the Service_Build user with > public/private key credentials. So that part works well. > > However, it looks like Jenkins is still trying to authenticate that user with > Active Directory, because the user is locked in Active Directory after a > number of CLI commands (eight in our case). > Should I have created the private key using the Active Directory password? Or > how can I prevent that Active Directory locking? > > Best regards, > Eric -- Website: http://earl-of-code.com
AW: Jenkins CLI user gets locked in Active Directory
Oh... :-) Well, I'm not really a Linux guru, so could you tell me where I find those logs? (Also, I'm not root either) Best regards, Eric -Ursprüngliche Nachricht- Von: Alex Earl [mailto:slide.o@gmail.com] Gesendet: Freitag, 8. Juni 2012 16:23 An: Lewis, Eric; jenkinsci-users@googlegroups.com Betreff: RE: Jenkins CLI user gets locked in Active Directory I was meaning the logs on the Linux machine. Sent from my Windows Phone From: Lewis, Eric Sent: 6/8/2012 7:06 AM To: jenkinsci-users@googlegroups.com Subject: AW: Jenkins CLI user gets locked in Active Directory Ok, I'll have to check (on Monday) with our Windows admins, since I don't have access to those logs. Best regards, Eric -Ursprüngliche Nachricht- Von: Alex Earl [mailto:slide.o@gmail.com] Gesendet: Freitag, 8. Juni 2012 16:00 An: Lewis, Eric; jenkinsci-users@googlegroups.com Betreff: RE: Jenkins CLI user gets locked in Active Directory Can you check the logs for authentication and see if AD is being tried before the key based auth? Sent from my Windows Phone From: Lewis, Eric Sent: 6/8/2012 6:32 AM To: jenkinsci-users@googlegroups.com Subject: AW: Jenkins CLI user gets locked in Active Directory Sorry! :-) Yes, Jenkins is running on Red Hat Linux (apparently Red Hat Enterprise Linux Server release 5.8 (Tikanga)) Best regards, Eric -Ursprüngliche Nachricht- Von: jenkinsci-users@googlegroups.com [mailto:jenkinsci-users@googlegroups.com] Im Auftrag von Slide Gesendet: Freitag, 8. Juni 2012 15:30 An: jenkinsci-users@googlegroups.com Betreff: Re: Jenkins CLI user gets locked in Active Directory Is this running on Linux? More information about your platforms and such would be useful. On Tue, Jun 5, 2012 at 5:58 AM, Lewis, Eric wrote: > Hi > > We have a user called Service_Build which is used for issuing Jenkins CLI > commands (either in bash or in Jenkins). > This user is defined in Active Directory, which is what we use for > authentication. So normally, I can log in as this user and I have > administrator rights in Jenkins. > > I followed the documentation in the Jenkins wiki and (with help from Rob > Mandeville) managed to authenticate the Service_Build user with > public/private key credentials. So that part works well. > > However, it looks like Jenkins is still trying to authenticate that user with > Active Directory, because the user is locked in Active Directory after a > number of CLI commands (eight in our case). > Should I have created the private key using the Active Directory password? Or > how can I prevent that Active Directory locking? > > Best regards, > Eric -- Website: http://earl-of-code.com
AW: Jenkins CLI user gets locked in Active Directory
Ok, I'll have to check (on Monday) with our Windows admins, since I don't have access to those logs. Best regards, Eric -Ursprüngliche Nachricht- Von: Alex Earl [mailto:slide.o@gmail.com] Gesendet: Freitag, 8. Juni 2012 16:00 An: Lewis, Eric; jenkinsci-users@googlegroups.com Betreff: RE: Jenkins CLI user gets locked in Active Directory Can you check the logs for authentication and see if AD is being tried before the key based auth? Sent from my Windows Phone From: Lewis, Eric Sent: 6/8/2012 6:32 AM To: jenkinsci-users@googlegroups.com Subject: AW: Jenkins CLI user gets locked in Active Directory Sorry! :-) Yes, Jenkins is running on Red Hat Linux (apparently Red Hat Enterprise Linux Server release 5.8 (Tikanga)) Best regards, Eric -Ursprüngliche Nachricht- Von: jenkinsci-users@googlegroups.com [mailto:jenkinsci-users@googlegroups.com] Im Auftrag von Slide Gesendet: Freitag, 8. Juni 2012 15:30 An: jenkinsci-users@googlegroups.com Betreff: Re: Jenkins CLI user gets locked in Active Directory Is this running on Linux? More information about your platforms and such would be useful. On Tue, Jun 5, 2012 at 5:58 AM, Lewis, Eric wrote: > Hi > > We have a user called Service_Build which is used for issuing Jenkins CLI > commands (either in bash or in Jenkins). > This user is defined in Active Directory, which is what we use for > authentication. So normally, I can log in as this user and I have > administrator rights in Jenkins. > > I followed the documentation in the Jenkins wiki and (with help from Rob > Mandeville) managed to authenticate the Service_Build user with > public/private key credentials. So that part works well. > > However, it looks like Jenkins is still trying to authenticate that user with > Active Directory, because the user is locked in Active Directory after a > number of CLI commands (eight in our case). > Should I have created the private key using the Active Directory password? Or > how can I prevent that Active Directory locking? > > Best regards, > Eric -- Website: http://earl-of-code.com
AW: Maven build results don't match Jenkins Build Artifacts
Thanks for the help!
>From the plugin documentation, that wasn't obvious: I thought that the
>parameter only influences the final name.
Well, having three different artifacts from one Maven build isn't standard...
;-)
Anyway, I'm still not 100% there, here's what Maven builds:
schemas-private.war
xml-schemas-1.7.0-SNAPSHOT.jar
xml-schemas-1.7.0-SNAPSHOT-sources.jar
xml-schemas-application-server-1.7.0-SNAPSHOT-appserver.zip
xml-schemas-public-schema-server-1.7.0-SNAPSHOT-public.zip
And here are the Jenkins build artifacts:
xml-schemas-1.7.0-SNAPSHOT-private.war
xml-schemas-1.7.0-SNAPSHOT.jar
xml-schemas-1.7.0-SNAPSHOT-sources.jar
xml-schemas-1.7.0-SNAPSHOT-appserver.zip
xml-schemas-1.7.0-SNAPSHOT-public.zip
xml-schemas-1.7.0-SNAPSHOT.pom
But that's really good enough and I can work with that.
Thanks again!
Best regards,
Eric
-Ursprüngliche Nachricht-
Von: jenkinsci-users@googlegroups.com [mailto:jenkinsci-users@googlegroups.com]
Im Auftrag von Stephen Connolly
Gesendet: Donnerstag, 7. Juni 2012 18:07
An: jenkinsci-users@googlegroups.com
Betreff: Re: Maven build results don't match Jenkins Build Artifacts
On 7 June 2012 16:33, Lewis, Eric wrote:
> Well, the 'classifier' property within the Assembly plugin is deprecated.
> Instead, the assembly's ID should be used, which is what I do.
That's fine. I wasn't saying to use the classifier property, rather I
was checking that you had different classifiers feeding into the
reactor.
> I have three different Assembly descriptors in that project.
>
>
> xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2
> http://maven.apache.org/xsd/assembly-1.1.2.xsd";>
> appserver
> ...
>
>
>
> xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2
> http://maven.apache.org/xsd/assembly-1.1.2.xsd";>
> private
> ...
>
>
> xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2
> http://maven.apache.org/xsd/assembly-1.1.2.xsd";>
> public
> ...
>
>
> And here's the relevant part of the POM:
>
> org.apache.maven.plugins
> maven-assembly-plugin
>
>
> create-private-xml-schema-war
> package
>
> single
>
>
>
>
> ${assemblies.default.directory}/private-xml-schemas.xml
>
> ${schema.private.target.war.file}
> false
^^^ this means do not set the classifier to the assembly
id, instead publish as main artifact
> ${project.build.directory}
> target/assembly/work-private
>
>
>
> create-private-xml-schema-appserver-zip
> package
>
> single
>
>
>
>
> ${assemblies.default.directory}/private-xml-schemas-appserver.xml
>
>
> ${schema.private.appserver.target.zip.file}
> false
^^^ this means do not set the classifier to the assembly
id, instead publish as main artifact
> ${project.build.directory}
>
> target/assembly/work-private-appserver
>
>
>
> create-public-xml-schema-zip
> package
>
> single
>
>
>
>
> ${assemblies.default.directory}/public-xml-schemas.xml
>
> ${schema.public.target.zip.file}
> false
^^^ this means do not set the classifier to the assembly
id, instead publish as main artifact
> ${project.build.directory}
> target/assembly/work-public
>
>
>
>
>
> But I wonder whether Jenkins is confused because I define the ZIP's name
> within the POM...
Because you set the main artifact to three different zip files, and
since there can be only one, the winner is
${assemblies.default.directory}/public-xml-schemas.xml being the last
to execute
AW: Jenkins CLI user gets locked in Active Directory
Sorry! :-) Yes, Jenkins is running on Red Hat Linux (apparently Red Hat Enterprise Linux Server release 5.8 (Tikanga)) Best regards, Eric -Ursprüngliche Nachricht- Von: jenkinsci-users@googlegroups.com [mailto:jenkinsci-users@googlegroups.com] Im Auftrag von Slide Gesendet: Freitag, 8. Juni 2012 15:30 An: jenkinsci-users@googlegroups.com Betreff: Re: Jenkins CLI user gets locked in Active Directory Is this running on Linux? More information about your platforms and such would be useful. On Tue, Jun 5, 2012 at 5:58 AM, Lewis, Eric wrote: > Hi > > We have a user called Service_Build which is used for issuing Jenkins CLI > commands (either in bash or in Jenkins). > This user is defined in Active Directory, which is what we use for > authentication. So normally, I can log in as this user and I have > administrator rights in Jenkins. > > I followed the documentation in the Jenkins wiki and (with help from Rob > Mandeville) managed to authenticate the Service_Build user with > public/private key credentials. So that part works well. > > However, it looks like Jenkins is still trying to authenticate that user with > Active Directory, because the user is locked in Active Directory after a > number of CLI commands (eight in our case). > Should I have created the private key using the Active Directory password? Or > how can I prevent that Active Directory locking? > > Best regards, > Eric -- Website: http://earl-of-code.com
AW: Jenkins CLI user gets locked in Active Directory
Anyone? :-) -Ursprüngliche Nachricht- Von: jenkinsci-users@googlegroups.com [mailto:jenkinsci-users@googlegroups.com] Im Auftrag von Lewis, Eric Gesendet: Dienstag, 5. Juni 2012 14:59 An: jenkinsci-users@googlegroups.com Betreff: Jenkins CLI user gets locked in Active Directory Hi We have a user called Service_Build which is used for issuing Jenkins CLI commands (either in bash or in Jenkins). This user is defined in Active Directory, which is what we use for authentication. So normally, I can log in as this user and I have administrator rights in Jenkins. I followed the documentation in the Jenkins wiki and (with help from Rob Mandeville) managed to authenticate the Service_Build user with public/private key credentials. So that part works well. However, it looks like Jenkins is still trying to authenticate that user with Active Directory, because the user is locked in Active Directory after a number of CLI commands (eight in our case). Should I have created the private key using the Active Directory password? Or how can I prevent that Active Directory locking? Best regards, Eric
AW: Maven build results don't match Jenkins Build Artifacts
Well, the 'classifier' property within the Assembly plugin is deprecated.
Instead, the assembly's ID should be used, which is what I do.
I have three different Assembly descriptors in that project.
http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2
http://maven.apache.org/xsd/assembly-1.1.2.xsd";>
appserver
...
http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2
http://maven.apache.org/xsd/assembly-1.1.2.xsd";>
private
...
http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2
http://maven.apache.org/xsd/assembly-1.1.2.xsd";>
public
...
And here's the relevant part of the POM:
org.apache.maven.plugins
maven-assembly-plugin
create-private-xml-schema-war
package
single
${assemblies.default.directory}/private-xml-schemas.xml
${schema.private.target.war.file}
false
${project.build.directory}
target/assembly/work-private
create-private-xml-schema-appserver-zip
package
single
${assemblies.default.directory}/private-xml-schemas-appserver.xml
${schema.private.appserver.target.zip.file}
false
${project.build.directory}
target/assembly/work-private-appserver
create-public-xml-schema-zip
package
single
${assemblies.default.directory}/public-xml-schemas.xml
${schema.public.target.zip.file}
false
${project.build.directory}
target/assembly/work-public
But I wonder whether Jenkins is confused because I define the ZIP's name within
the POM...
Best regards,
Eric
-Ursprüngliche Nachricht-
Von: jenkinsci-users@googlegroups.com [mailto:jenkinsci-users@googlegroups.com]
Im Auftrag von Stephen Connolly
Gesendet: Donnerstag, 7. Juni 2012 17:22
An: jenkinsci-users@googlegroups.com
Betreff: Re: Maven build results don't match Jenkins Build Artifacts
yes but do the assemblies produce different classifiers for the
different assemblies?
On 7 June 2012 14:37, Lewis, Eric wrote:
> Well, according to
> http://maven.apache.org/plugins/maven-assembly-plugin/single-mojo.html the
> ZIP files are attached automatically ('attach' defaults to true).
>
> I'll archive the ZIP files as artifacts (thanks for the hint), but is there
> any way to check what is actually attached to the Maven build?
>
> Best regards,
> Eric
>
> -Ursprüngliche Nachricht-
> Von: jenkinsci-users@googlegroups.com
> [mailto:jenkinsci-users@googlegroups.com] Im Auftrag von Stephen Connolly
> Gesendet: Donnerstag, 7. Juni 2012 12:36
> An: jenkinsci-users@googlegroups.com
> Betreff: Re: Maven build results don't match Jenkins Build Artifacts
>
> I will bet you are not attaching the artifacts to the reactor
> correctly, i.e. one/both of the zip files do not have a classifier, in
> which case the last zip file will be the one bound to the reactor and
> hence picked up by the maven job type's crazy code.
>
> There is the ability to manually archive artifacts in addition to
> those auto-archived by the maven job type (I know this because when I
> was testing the cloudbees rsync-like faster archiving of artifacts
> code I spotted the option). that will give you back the permalinks and
> the file names will be those of the file system.
>
> I see this issue as a problem with your build and Jenkins is doing the
> "right thing" so I don't see the need for a JIRA
>
> On 7 June 2012 10:41, Lewis, Eric wrote:
>> Well, the name is one thing, but the artifacts themselves differ (I create
>> two ZIP files, but only one (and which one?) ends up as Jenkins artifact.
>>
>> I would expect that the Maven job type asks Maven about the job artifacts -
>> but then I'm probably w
AW: Maven build results don't match Jenkins Build Artifacts
Well, according to
http://maven.apache.org/plugins/maven-assembly-plugin/single-mojo.html the ZIP
files are attached automatically ('attach' defaults to true).
I'll archive the ZIP files as artifacts (thanks for the hint), but is there any
way to check what is actually attached to the Maven build?
Best regards,
Eric
-Ursprüngliche Nachricht-
Von: jenkinsci-users@googlegroups.com [mailto:jenkinsci-users@googlegroups.com]
Im Auftrag von Stephen Connolly
Gesendet: Donnerstag, 7. Juni 2012 12:36
An: jenkinsci-users@googlegroups.com
Betreff: Re: Maven build results don't match Jenkins Build Artifacts
I will bet you are not attaching the artifacts to the reactor
correctly, i.e. one/both of the zip files do not have a classifier, in
which case the last zip file will be the one bound to the reactor and
hence picked up by the maven job type's crazy code.
There is the ability to manually archive artifacts in addition to
those auto-archived by the maven job type (I know this because when I
was testing the cloudbees rsync-like faster archiving of artifacts
code I spotted the option). that will give you back the permalinks and
the file names will be those of the file system.
I see this issue as a problem with your build and Jenkins is doing the
"right thing" so I don't see the need for a JIRA
On 7 June 2012 10:41, Lewis, Eric wrote:
> Well, the name is one thing, but the artifacts themselves differ (I create
> two ZIP files, but only one (and which one?) ends up as Jenkins artifact.
>
> I would expect that the Maven job type asks Maven about the job artifacts -
> but then I'm probably wrong ;-)
>
> For the moment I can live with the fact that I have to get artifacts from the
> workspace instead of Jenkins (even though I'll miss the nice permalinks). But
> should I write an issue in the Jenkins JIRA?
>
> Best regards,
> Eric
>
>
>
> Von: jenkinsci-users@googlegroups.com
> [mailto:jenkinsci-users@googlegroups.com] Im Auftrag von Stephen Connolly
> Gesendet: Donnerstag, 7. Juni 2012 10:54
> An: jenkinsci-users@googlegroups.com
> Betreff: Re: Maven build results don't match Jenkins Build Artifacts
>
> Those are what maven considers the artifacts, ie those are the names that
> will end up in the maven repository.
>
> You can manually archive the files if the name is that important to you.
>
> Of course I never use the maven job type as it does things (which make the
> users life initially easier) that are not the maven way. My preference is a
> maven build step in a freestyle project... But what would I know!
>
> One of these days sacha will ok me writing a correct maven job type
> (something which I know how it should be done, but haven't had the time to do
> yet. Btw that fork of jenkins has not done it right either ;-) )
>
> On Thursday, 7 June 2012, Lewis, Eric wrote:
> Hi
>
> Since changing from an old Hudson to Jenkins 1.460 I noticed that Maven's
> build results differ from what Jenkins considers Build Artifacts.
> Specifically it has to do with renaming and using other results of the Maven
> assembly plugin.
>
> For instance, I have a build which repackages some XML schemas in various
> forms.
>
> Here's what it looks like in the workspace:
>
> target/
> |-- schemas.war
> |-- xml-schemas-1.6.0-sources.jar
> |-- xml-schemas-1.6.0.jar
> |-- xml-schemas-application-server-1.6.0.zip
> `-- xml-schemas-public-schema-server-1.6.0.zip
>
> Here's what Jenkins considers build artifacts:
> Build Artifacts
> xml-schemas-1.6.0-sources.jar
> xml-schemas-1.6.0.jar
> xml-schemas-1.6.0.pom
> xml-schemas-1.6.0.war
> xml-schemas-1.6.0.zip
>
> Is this a known bug?
>
> Best regards,
> Eric
AW: Maven build results don't match Jenkins Build Artifacts
Well, the name is one thing, but the artifacts themselves differ (I create two ZIP files, but only one (and which one?) ends up as Jenkins artifact. I would expect that the Maven job type asks Maven about the job artifacts - but then I'm probably wrong ;-) For the moment I can live with the fact that I have to get artifacts from the workspace instead of Jenkins (even though I'll miss the nice permalinks). But should I write an issue in the Jenkins JIRA? Best regards, Eric Von: jenkinsci-users@googlegroups.com [mailto:jenkinsci-users@googlegroups.com] Im Auftrag von Stephen Connolly Gesendet: Donnerstag, 7. Juni 2012 10:54 An: jenkinsci-users@googlegroups.com Betreff: Re: Maven build results don't match Jenkins Build Artifacts Those are what maven considers the artifacts, ie those are the names that will end up in the maven repository. You can manually archive the files if the name is that important to you. Of course I never use the maven job type as it does things (which make the users life initially easier) that are not the maven way. My preference is a maven build step in a freestyle project... But what would I know! One of these days sacha will ok me writing a correct maven job type (something which I know how it should be done, but haven't had the time to do yet. Btw that fork of jenkins has not done it right either ;-) ) On Thursday, 7 June 2012, Lewis, Eric wrote: Hi Since changing from an old Hudson to Jenkins 1.460 I noticed that Maven's build results differ from what Jenkins considers Build Artifacts. Specifically it has to do with renaming and using other results of the Maven assembly plugin. For instance, I have a build which repackages some XML schemas in various forms. Here's what it looks like in the workspace: target/ |-- schemas.war |-- xml-schemas-1.6.0-sources.jar |-- xml-schemas-1.6.0.jar |-- xml-schemas-application-server-1.6.0.zip `-- xml-schemas-public-schema-server-1.6.0.zip Here's what Jenkins considers build artifacts: Build Artifacts xml-schemas-1.6.0-sources.jar xml-schemas-1.6.0.jar xml-schemas-1.6.0.pom xml-schemas-1.6.0.war xml-schemas-1.6.0.zip Is this a known bug? Best regards, Eric
Maven build results don't match Jenkins Build Artifacts
Hi Since changing from an old Hudson to Jenkins 1.460 I noticed that Maven's build results differ from what Jenkins considers Build Artifacts. Specifically it has to do with renaming and using other results of the Maven assembly plugin. For instance, I have a build which repackages some XML schemas in various forms. Here's what it looks like in the workspace: target/ |-- schemas.war |-- xml-schemas-1.6.0-sources.jar |-- xml-schemas-1.6.0.jar |-- xml-schemas-application-server-1.6.0.zip `-- xml-schemas-public-schema-server-1.6.0.zip Here's what Jenkins considers build artifacts: Build Artifacts xml-schemas-1.6.0-sources.jar xml-schemas-1.6.0.jar xml-schemas-1.6.0.pom xml-schemas-1.6.0.war xml-schemas-1.6.0.zip Is this a known bug? Best regards, Eric
Jenkins CLI user gets locked in Active Directory
Hi We have a user called Service_Build which is used for issuing Jenkins CLI commands (either in bash or in Jenkins). This user is defined in Active Directory, which is what we use for authentication. So normally, I can log in as this user and I have administrator rights in Jenkins. I followed the documentation in the Jenkins wiki and (with help from Rob Mandeville) managed to authenticate the Service_Build user with public/private key credentials. So that part works well. However, it looks like Jenkins is still trying to authenticate that user with Active Directory, because the user is locked in Active Directory after a number of CLI commands (eight in our case). Should I have created the private key using the Active Directory password? Or how can I prevent that Active Directory locking? Best regards, Eric
AW: Dummy's guide to Jenkins CLI with authentication
Thanks, it worked now, looks like the key got mangled in the UI... Best regards, Eric -Ursprüngliche Nachricht- Von: jenkinsci-users@googlegroups.com [mailto:jenkinsci-users@googlegroups.com] Im Auftrag von Mandeville, Rob Gesendet: Freitag, 1. Juni 2012 17:47 An: 'jenkinsci-users@googlegroups.com' Betreff: RE: Dummy's guide to Jenkins CLI with authentication Correct. The Linux user is completely irrelevant. Jenkins ties a Jenkins account to a public key, and anyone using the matching private key to connect to Jenkins _is_ that Jenkins user, just like if they presented the proper username and password. --Rob -Original Message- From: jenkinsci-users@googlegroups.com [mailto:jenkinsci-users@googlegroups.com] On Behalf Of Lewis, Eric Sent: Friday, June 01, 2012 11:45 AM To: jenkinsci-users@googlegroups.com Subject: AW: Dummy's guide to Jenkins CLI with authentication So the user with which I'm creating the keys is totally irrelevant? Best regards, Eric -Ursprüngliche Nachricht- Von: jenkinsci-users@googlegroups.com [mailto:jenkinsci-users@googlegroups.com] Im Auftrag von Mandeville, Rob Gesendet: Donnerstag, 31. Mai 2012 15:53 An: jenkinsci-users@googlegroups.com Betreff: RE: Dummy's guide to Jenkins CLI with authentication If you're not doing so already, try running the command line with "-i ~/.ssh/id_rsa". Your _private_ key should be passed in with the "-i" argument. Also, double-check the "SSH Public Keys" field in your user config. For example, my public key listing looks like ssh-dss B3NzaC1kc3MAAACBAJPyRLf7S/L859k4T8KHhipHBVd/ltB1LarT9bNjzir7KByz7AdU695JKESNUCq7J+pY8lDR+XDyJfqKoHeAyKUaO1CIC1A9Y8x/8O5KzNCcXv1o6jXvUavStU+0cnqBvUqDN6IuD8AmZvVes0hiTgC13GWqr4I1TGkMKYfF+w6rFQDMf2dxqCozcc+tphCnaZZEjr6TgQAAAIAX8cZOidtaom026qEzjd2PD8CjlaHc2XtwdistKKAFUZG/6APNa3JW1PeJIYqB0HTIgXPCItODzHSeiQ4l4J+ZjviV4lDIJkUTjJdYtpw3MU2Exj53xo5SH4Q41L/HYnsq2P+mEuM8CuooEQKcAUXLRCAqGQENRKU0duZDjC2ovgAAAIBOLI6heodoIFB+/yQNw8dpsUBbgFzz2cryU5/79wzTAu9v6SXxnfwnPapzPekp+eBehFeA8XdoGsm9xCvonWWkH7LrLVzfRQ5e3km4zTxw78dcN6tLoGIXOkuVIgfW2iT6j78FAfBLhOVfXsyVWQeMPoXUtoLFO1wZH+amOnnERQ== rmandevi@L-rmandevi-ws490 If there are any lines decorating it, it may well fail. Note that on my page, "ssh-dss" does not show up as its own line (as it may in the email depending on line breaking rules). --Rob -Original Message- From: jenkinsci-users@googlegroups.com [mailto:jenkinsci-users@googlegroups.com] On Behalf Of Lewis, Eric Sent: Thursday, May 31, 2012 9:25 AM To: jenkinsci-users@googlegroups.com Subject: Dummy's guide to Jenkins CLI with authentication Hi I'm trying to use the Jenkins CLI, but I'm getting nowhere... We're using 1.460, and I did read https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+CLI but the crucial part about how to generate an SSH key pair is missing. My problem is that we have two different users: - The Linux user under which Jenkins is running - A build user which should have the right to run Jenkins CLI commands We use Active Directory and thus the AD plugin to authenticate. The build user exists in AD, but the Linux user doesn't. I tried to generate an SSH key pair using ssh-keygen, and it wrote the two key files into the ~/.ssh directory, but of course for the Linux user. I then logged in with the build user and set the public key of the Linux user into the text area (that's the content of the file ~/.ssh/id_rsa.pub, right?) But then I always get "Failed to authenticate with your SSH keys." I'm probably doing something terribly wrong :-) but I have no clue. Does anyone care to explain in simple steps what to do? Thanks & best regards, Eric The information in this message is for the intended recipient(s) only and may be the proprietary and/or confidential property of Litle & Co., LLC, and thus protected from disclosure. If you are not the intended recipient(s), or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any use, dissemination, distribution or copying of this communication is prohibited. If you have received this communication in error, please notify Litle & Co. immediately by replying to this message and then promptly deleting it and your reply permanently from your computer.
AW: Dummy's guide to Jenkins CLI with authentication
Thanks for the hint: I read the page, but I'm none the wiser... sorry! It points to https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+CLI and "working with credentials", which I already read and got stuck... Best regards, Eric -Ursprüngliche Nachricht- Von: jenkinsci-users@googlegroups.com [mailto:jenkinsci-users@googlegroups.com] Im Auftrag von Sami Tikka Gesendet: Donnerstag, 31. Mai 2012 19:29 An: jenkinsci-users@googlegroups.com Betreff: Re: Dummy's guide to Jenkins CLI with authentication Did you read https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+SSH ? It should describe what you need to do. -- Sami Lewis, Eric kirjoitti 31.5.2012 kello 16.24: > Hi > > I'm trying to use the Jenkins CLI, but I'm getting nowhere... > We're using 1.460, and I did read > https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+CLI but the crucial part > about how to generate an SSH key pair is missing. > > My problem is that we have two different users: > - The Linux user under which Jenkins is running > - A build user which should have the right to run Jenkins CLI commands > > We use Active Directory and thus the AD plugin to authenticate. The build > user exists in AD, but the Linux user doesn't. > I tried to generate an SSH key pair using ssh-keygen, and it wrote the two > key files into the ~/.ssh directory, but of course for the Linux user. > I then logged in with the build user and set the public key of the Linux user > into the text area (that's the content of the file ~/.ssh/id_rsa.pub, right?) > > But then I always get "Failed to authenticate with your SSH keys." > > I'm probably doing something terribly wrong :-) but I have no clue. > > Does anyone care to explain in simple steps what to do? > > Thanks & best regards, > Eric
AW: Dummy's guide to Jenkins CLI with authentication
So the user with which I'm creating the keys is totally irrelevant? Best regards, Eric -Ursprüngliche Nachricht- Von: jenkinsci-users@googlegroups.com [mailto:jenkinsci-users@googlegroups.com] Im Auftrag von Mandeville, Rob Gesendet: Donnerstag, 31. Mai 2012 15:53 An: jenkinsci-users@googlegroups.com Betreff: RE: Dummy's guide to Jenkins CLI with authentication If you're not doing so already, try running the command line with "-i ~/.ssh/id_rsa". Your _private_ key should be passed in with the "-i" argument. Also, double-check the "SSH Public Keys" field in your user config. For example, my public key listing looks like ssh-dss B3NzaC1kc3MAAACBAJPyRLf7S/L859k4T8KHhipHBVd/ltB1LarT9bNjzir7KByz7AdU695JKESNUCq7J+pY8lDR+XDyJfqKoHeAyKUaO1CIC1A9Y8x/8O5KzNCcXv1o6jXvUavStU+0cnqBvUqDN6IuD8AmZvVes0hiTgC13GWqr4I1TGkMKYfF+w6rFQDMf2dxqCozcc+tphCnaZZEjr6TgQAAAIAX8cZOidtaom026qEzjd2PD8CjlaHc2XtwdistKKAFUZG/6APNa3JW1PeJIYqB0HTIgXPCItODzHSeiQ4l4J+ZjviV4lDIJkUTjJdYtpw3MU2Exj53xo5SH4Q41L/HYnsq2P+mEuM8CuooEQKcAUXLRCAqGQENRKU0duZDjC2ovgAAAIBOLI6heodoIFB+/yQNw8dpsUBbgFzz2cryU5/79wzTAu9v6SXxnfwnPapzPekp+eBehFeA8XdoGsm9xCvonWWkH7LrLVzfRQ5e3km4zTxw78dcN6tLoGIXOkuVIgfW2iT6j78FAfBLhOVfXsyVWQeMPoXUtoLFO1wZH+amOnnERQ== rmandevi@L-rmandevi-ws490 If there are any lines decorating it, it may well fail. Note that on my page, "ssh-dss" does not show up as its own line (as it may in the email depending on line breaking rules). --Rob -Original Message- From: jenkinsci-users@googlegroups.com [mailto:jenkinsci-users@googlegroups.com] On Behalf Of Lewis, Eric Sent: Thursday, May 31, 2012 9:25 AM To: jenkinsci-users@googlegroups.com Subject: Dummy's guide to Jenkins CLI with authentication Hi I'm trying to use the Jenkins CLI, but I'm getting nowhere... We're using 1.460, and I did read https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+CLI but the crucial part about how to generate an SSH key pair is missing. My problem is that we have two different users: - The Linux user under which Jenkins is running - A build user which should have the right to run Jenkins CLI commands We use Active Directory and thus the AD plugin to authenticate. The build user exists in AD, but the Linux user doesn't. I tried to generate an SSH key pair using ssh-keygen, and it wrote the two key files into the ~/.ssh directory, but of course for the Linux user. I then logged in with the build user and set the public key of the Linux user into the text area (that's the content of the file ~/.ssh/id_rsa.pub, right?) But then I always get "Failed to authenticate with your SSH keys." I'm probably doing something terribly wrong :-) but I have no clue. Does anyone care to explain in simple steps what to do? Thanks & best regards, Eric The information in this message is for the intended recipient(s) only and may be the proprietary and/or confidential property of Litle & Co., LLC, and thus protected from disclosure. If you are not the intended recipient(s), or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any use, dissemination, distribution or copying of this communication is prohibited. If you have received this communication in error, please notify Litle & Co. immediately by replying to this message and then promptly deleting it and your reply permanently from your computer.
Dummy's guide to Jenkins CLI with authentication
Hi I'm trying to use the Jenkins CLI, but I'm getting nowhere... We're using 1.460, and I did read https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+CLI but the crucial part about how to generate an SSH key pair is missing. My problem is that we have two different users: - The Linux user under which Jenkins is running - A build user which should have the right to run Jenkins CLI commands We use Active Directory and thus the AD plugin to authenticate. The build user exists in AD, but the Linux user doesn't. I tried to generate an SSH key pair using ssh-keygen, and it wrote the two key files into the ~/.ssh directory, but of course for the Linux user. I then logged in with the build user and set the public key of the Linux user into the text area (that's the content of the file ~/.ssh/id_rsa.pub, right?) But then I always get "Failed to authenticate with your SSH keys." I'm probably doing something terribly wrong :-) but I have no clue. Does anyone care to explain in simple steps what to do? Thanks & best regards, Eric
AW: AW: AW: Findbugs Plugin doesn't find report
Ok, with this POM modification it works, thanks!
I also filed the issue https://issues.jenkins-ci.org/browse/JENKINS-12853
Best regards,
Eric
-Ursprüngliche Nachricht-
Von: jenkinsci-users@googlegroups.com [mailto:jenkinsci-users@googlegroups.com]
Im Auftrag von Ullrich Hafner
Gesendet: Mittwoch, 22. Februar 2012 11:34
An: jenkinsci-users@googlegroups.com
Betreff: Re: AW: AW: Findbugs Plugin doesn't find report
Ah, you are using the maven job type.
Here, Jenkins detects automatically which file is created. Since you did
not specify
true
my plug-in thinks that only the old findbugs.xml file is created. Can
you please add that to your pom and retry?
Also, please file an issue in our Jira. I need to improve the detecting
of the correct file when using findbugs-maven-plugin 2.4.0 .
Ulli
On 02/22/2012 09:59 AM, Lewis, Eric wrote:
> Hm... I'm using the Maven2/3 job type, and I can't configure it.
> Do I have to use the freestyle build and lose the nice features of the
> Maven2/3 job type?
>
> Best regards,
> Eric
>
> -Ursprüngliche Nachricht-
> Von: jenkinsci-users@googlegroups.com
> [mailto:jenkinsci-users@googlegroups.com] Im Auftrag von Ullrich Hafner
> Gesendet: Dienstag, 21. Februar 2012 21:53
> An: jenkinsci-users@googlegroups.com
> Betreff: Re: AW: Findbugs Plugin doesn't find report
>
> You need to set the pattern to
>
> **/findbugsXml.xml
>
> Ulli
>
> On 02/21/2012 04:28 PM, Lewis, Eric wrote:
>> Here's my configuration (the version is defined in pluginManagement):
>>
>>
>> org.codehaus.mojo
>> findbugs-maven-plugin
>>
>>
>> package
>>
>> findbugs
>>
>>
>>
>>
>> true
>> Max
>>
>> ${build.home}findbugs/findbugs-exclude.xml
>> false
>> ${file.encoding}
>>
>>
>>
>> As for the configuration you mention, according to
>> http://mojo.codehaus.org/findbugs-maven-plugin-2.4.0/findbugs-mojo.html
>> findbugsXmlOutput is deprecated and defaults to true
>> findbugsXmlWithMessages doesn't exist
>>
>> The files I have in my target directory are:
>> findbugs.xml
>> findbugs-exclude.xml
>> findbugsXml.xml
>>
>> Best regards,
>> Eric
>>
>> -Ursprüngliche Nachricht-
>> Von: jenkinsci-users@googlegroups.com
>> [mailto:jenkinsci-users@googlegroups.com] Im Auftrag von Ullrich Hafner
>> Gesendet: Dienstag, 21. Februar 2012 16:16
>> An: jenkinsci-users@googlegroups.com
>> Betreff: Re: Findbugs Plugin doesn't find report
>>
>> Seems that the report is found, but the warnings are not reported...
>>
>> [FINDBUGS] Successfully parsed file
>> /ige/jenkins/work/jobs/base/workspace/base-impl/target/findbugs.xml of
>> module Implementation of Base Services with 0 warnings.
>>
>>
>> What looks suspicious is the filename, did you use the following options?
>>
>> true
>> true
>> true
>>
>>
>> Normally the filename is findbugsXml.xml when used with maven...
>>
>> Ulli
>>
>> On 02/21/2012 03:53 PM, Lewis, Eric wrote:
>>> Hi
>>>
>>> I'm migrating our old build to the latest and greatest of everything,
>>> including Maven 3.0.4, the latest Maven plugins (Findbugs 2.4.0), Jenkins
>>> 1.451 and Jenkins Findbugs plugin 4.33
>>>
>>> Now, while the Checkstyle and PMD reports are found, the Jenkins Findbugs
>>> plugin doesn't see its report.
>>>
>>> Here's my log:
>>> [INFO] --- findbugs-maven-plugin:2.4.0:findbugs (default) @ base-impl ---
>>> [INFO] Fork Value is true
>>> [java] Warnings generated: 4
>>> [INFO] Done FindBugs Analysis
>>> [FINDBUGS] Parsing 1 files in
>>> /ige/jenkins/work/jobs/base/workspace/base-impl/target
>>> [FINDBUGS] Successfully parsed file
>>> /ige/jenkins/work/jobs/base/workspace/base-impl/target/findbugs.xml of
>>> module Implementation of Base Services with 0 warnings.
>>> [FINDBUGS] Ignore new warnings since this is the first valid build
>>> [FINDBUGS] Not changing build status, since no threshold has been exceeded
>>> [FINDBUGS] Computing warning deltas based on reference build #2
>>>
>>> The findbugs.xml looks like this:
>>>
>>> >> classname=
AW: AW: Findbugs Plugin doesn't find report
Hm... I'm using the Maven2/3 job type, and I can't configure it.
Do I have to use the freestyle build and lose the nice features of the Maven2/3
job type?
Best regards,
Eric
-Ursprüngliche Nachricht-
Von: jenkinsci-users@googlegroups.com [mailto:jenkinsci-users@googlegroups.com]
Im Auftrag von Ullrich Hafner
Gesendet: Dienstag, 21. Februar 2012 21:53
An: jenkinsci-users@googlegroups.com
Betreff: Re: AW: Findbugs Plugin doesn't find report
You need to set the pattern to
**/findbugsXml.xml
Ulli
On 02/21/2012 04:28 PM, Lewis, Eric wrote:
> Here's my configuration (the version is defined in pluginManagement):
>
>
> org.codehaus.mojo
> findbugs-maven-plugin
>
>
> package
>
> findbugs
>
>
>
>
> true
> Max
>
> ${build.home}findbugs/findbugs-exclude.xml
> false
> ${file.encoding}
>
>
>
> As for the configuration you mention, according to
> http://mojo.codehaus.org/findbugs-maven-plugin-2.4.0/findbugs-mojo.html
> findbugsXmlOutput is deprecated and defaults to true
> findbugsXmlWithMessages doesn't exist
>
> The files I have in my target directory are:
> findbugs.xml
> findbugs-exclude.xml
> findbugsXml.xml
>
> Best regards,
> Eric
>
> -Ursprüngliche Nachricht-
> Von: jenkinsci-users@googlegroups.com
> [mailto:jenkinsci-users@googlegroups.com] Im Auftrag von Ullrich Hafner
> Gesendet: Dienstag, 21. Februar 2012 16:16
> An: jenkinsci-users@googlegroups.com
> Betreff: Re: Findbugs Plugin doesn't find report
>
> Seems that the report is found, but the warnings are not reported...
>
> [FINDBUGS] Successfully parsed file
> /ige/jenkins/work/jobs/base/workspace/base-impl/target/findbugs.xml of module
> Implementation of Base Services with 0 warnings.
>
>
> What looks suspicious is the filename, did you use the following options?
>
> true
> true
> true
>
>
> Normally the filename is findbugsXml.xml when used with maven...
>
> Ulli
>
> On 02/21/2012 03:53 PM, Lewis, Eric wrote:
>> Hi
>>
>> I'm migrating our old build to the latest and greatest of everything,
>> including Maven 3.0.4, the latest Maven plugins (Findbugs 2.4.0), Jenkins
>> 1.451 and Jenkins Findbugs plugin 4.33
>>
>> Now, while the Checkstyle and PMD reports are found, the Jenkins Findbugs
>> plugin doesn't see its report.
>>
>> Here's my log:
>> [INFO] --- findbugs-maven-plugin:2.4.0:findbugs (default) @ base-impl ---
>> [INFO] Fork Value is true
>> [java] Warnings generated: 4
>> [INFO] Done FindBugs Analysis
>> [FINDBUGS] Parsing 1 files in
>> /ige/jenkins/work/jobs/base/workspace/base-impl/target
>> [FINDBUGS] Successfully parsed file
>> /ige/jenkins/work/jobs/base/workspace/base-impl/target/findbugs.xml of
>> module Implementation of Base Services with 0 warnings.
>> [FINDBUGS] Ignore new warnings since this is the first valid build
>> [FINDBUGS] Not changing build status, since no threshold has been exceeded
>> [FINDBUGS] Computing warning deltas based on reference build #2
>>
>> The findbugs.xml looks like this:
>>
>> > classname='ch.ipi.esv.base.impl.mgmt.MgmtServiceBean$RunTestsCallable'>> type='SIC_INNER_SHOULD_BE_STATIC' priority='Normal' category='PERFORMANCE'
>> message='Should ch.ipi.esv.base.impl.mgmt.MgmtServiceBean$RunTestsCallable
>> be a _static_ inner class?' lineNumber='1'/>> classname='ch.ipi.esv.base.impl.mgmt.jmx.MailManagementService$SendTestMailCall'>> type='DM_DEFAULT_ENCODING' priority='High' category='I18N' message='Found
>> reliance on default encoding in
>> ch.ipi.esv.base.impl.mgmt.jmx.MailManagementService$SendTestMailCall.call():
>> new java.io.PrintStream(OutputStream)' lineNumber='149'/>> type='DM_DEFAULT_ENCODING' priority='High' category='I18N' message='Found
>> reliance on default encoding in
>> ch.ipi.esv.base.impl.mgmt.jmx.MailManagementService$SendTestMailCall.call():
>> new java.io.PrintStream(OutputStream)' lineNumber='155'/>> classname='ch.ipi.esv.base.persistence.api.entity.BaseClass'>> type='EQ_UNUSUAL' priority='Normal' category='STYLE'
>> message='ch.ipi.esv.base.persistence.api.entity.BaseClass.equals(Object) is
>> unusual'
>> lineNumber='50'/>/ige/jenkins/work/jobs/base/workspace/base-impl/src/main/java/ige/jenkins/work/jobs/base/workspace/base-impl/src/main/aspect/ige/jenkins/work/jobs/base/workspace/base-impl/src/main/aspect/ige/jenkins/work/jobs/base/workspace/base-impl/src/test/java/ige/jenkins/work/jobs/base/workspace/base-impl/src/test/aspect/ige/jenkins/work/jobs/base/workspace/base-impl/src/test/aspect
>>
>> What am I doing wrong?
>>
>> Best regards,
>> Eric
>
AW: Findbugs Plugin doesn't find report
Here's my configuration (the version is defined in pluginManagement):
org.codehaus.mojo
findbugs-maven-plugin
package
findbugs
true
Max
${build.home}findbugs/findbugs-exclude.xml
false
${file.encoding}
As for the configuration you mention, according to
http://mojo.codehaus.org/findbugs-maven-plugin-2.4.0/findbugs-mojo.html
findbugsXmlOutput is deprecated and defaults to true
findbugsXmlWithMessages doesn't exist
The files I have in my target directory are:
findbugs.xml
findbugs-exclude.xml
findbugsXml.xml
Best regards,
Eric
-Ursprüngliche Nachricht-
Von: jenkinsci-users@googlegroups.com [mailto:jenkinsci-users@googlegroups.com]
Im Auftrag von Ullrich Hafner
Gesendet: Dienstag, 21. Februar 2012 16:16
An: jenkinsci-users@googlegroups.com
Betreff: Re: Findbugs Plugin doesn't find report
Seems that the report is found, but the warnings are not reported...
[FINDBUGS] Successfully parsed file
/ige/jenkins/work/jobs/base/workspace/base-impl/target/findbugs.xml of module
Implementation of Base Services with 0 warnings.
What looks suspicious is the filename, did you use the following options?
true
true
true
Normally the filename is findbugsXml.xml when used with maven...
Ulli
On 02/21/2012 03:53 PM, Lewis, Eric wrote:
> Hi
>
> I'm migrating our old build to the latest and greatest of everything,
> including Maven 3.0.4, the latest Maven plugins (Findbugs 2.4.0), Jenkins
> 1.451 and Jenkins Findbugs plugin 4.33
>
> Now, while the Checkstyle and PMD reports are found, the Jenkins Findbugs
> plugin doesn't see its report.
>
> Here's my log:
> [INFO] --- findbugs-maven-plugin:2.4.0:findbugs (default) @ base-impl ---
> [INFO] Fork Value is true
> [java] Warnings generated: 4
> [INFO] Done FindBugs Analysis
> [FINDBUGS] Parsing 1 files in
> /ige/jenkins/work/jobs/base/workspace/base-impl/target
> [FINDBUGS] Successfully parsed file
> /ige/jenkins/work/jobs/base/workspace/base-impl/target/findbugs.xml of module
> Implementation of Base Services with 0 warnings.
> [FINDBUGS] Ignore new warnings since this is the first valid build
> [FINDBUGS] Not changing build status, since no threshold has been exceeded
> [FINDBUGS] Computing warning deltas based on reference build #2
>
> The findbugs.xml looks like this:
>
> classname='ch.ipi.esv.base.impl.mgmt.MgmtServiceBean$RunTestsCallable'> type='SIC_INNER_SHOULD_BE_STATIC' priority='Normal' category='PERFORMANCE'
> message='Should ch.ipi.esv.base.impl.mgmt.MgmtServiceBean$RunTestsCallable be
> a _static_ inner class?' lineNumber='1'/> classname='ch.ipi.esv.base.impl.mgmt.jmx.MailManagementService$SendTestMailCall'> type='DM_DEFAULT_ENCODING' priority='High' category='I18N' message='Found
> reliance on default encoding in
> ch.ipi.esv.base.impl.mgmt.jmx.MailManagementService$SendTestMailCall.call():
> new java.io.PrintStream(OutputStream)' lineNumber='149'/> type='DM_DEFAULT_ENCODING' priority='High' category='I18N' message='Found
> reliance on default encoding in
> ch.ipi.esv.base.impl.mgmt.jmx.MailManagementService$SendTestMailCall.call():
> new java.io.PrintStream(OutputStream)' lineNumber='155'/> classname='ch.ipi.esv.base.persistence.api.entity.BaseClass'> type='EQ_UNUSUAL' priority='Normal' category='STYLE'
> message='ch.ipi.esv.base.persistence.api.entity.BaseClass.equals(Object) is
> unusual'
> lineNumber='50'/>/ige/jenkins/work/jobs/base/workspace/base-impl/src/main/java/ige/jenkins/work/jobs/base/workspace/base-impl/src/main/aspect/ige/jenkins/work/jobs/base/workspace/base-impl/src/main/aspect/ige/jenkins/work/jobs/base/workspace/base-impl/src/test/java/ige/jenkins/work/jobs/base/workspace/base-impl/src/test/aspect/ige/jenkins/work/jobs/base/workspace/base-impl/src/test/aspect
>
> What am I doing wrong?
>
> Best regards,
> Eric
Findbugs Plugin doesn't find report
Hi I'm migrating our old build to the latest and greatest of everything, including Maven 3.0.4, the latest Maven plugins (Findbugs 2.4.0), Jenkins 1.451 and Jenkins Findbugs plugin 4.33 Now, while the Checkstyle and PMD reports are found, the Jenkins Findbugs plugin doesn't see its report. Here's my log: [INFO] --- findbugs-maven-plugin:2.4.0:findbugs (default) @ base-impl --- [INFO] Fork Value is true [java] Warnings generated: 4 [INFO] Done FindBugs Analysis [FINDBUGS] Parsing 1 files in /ige/jenkins/work/jobs/base/workspace/base-impl/target [FINDBUGS] Successfully parsed file /ige/jenkins/work/jobs/base/workspace/base-impl/target/findbugs.xml of module Implementation of Base Services with 0 warnings. [FINDBUGS] Ignore new warnings since this is the first valid build [FINDBUGS] Not changing build status, since no threshold has been exceeded [FINDBUGS] Computing warning deltas based on reference build #2 The findbugs.xml looks like this: /ige/jenkins/work/jobs/base/workspace/base-impl/src/main/java/ige/jenkins/work/jobs/base/workspace/base-impl/src/main/aspect/ige/jenkins/work/jobs/base/workspace/base-impl/src/main/aspect/ige/jenkins/work/jobs/base/workspace/base-impl/src/test/java/ige/jenkins/work/jobs/base/workspace/base-impl/src/test/aspect/ige/jenkins/work/jobs/base/workspace/base-impl/src/test/aspect What am I doing wrong? Best regards, Eric
