Request for feedback: the first Jenkins build

[Kohsuke Kawaguchi]

I posted the first bits of Jenkins and its packages at
http://jenkins-ci.org/rc/ I'd appreciate if people would try those and
let us know if there's anything wrong that should be fixed for the first
release of Jenkins.

The release is a drop-in replacement to Hudson. For those who are using
native packages, note the following renames:

*.deb:
/etc/default/hudson -> /etc/default/jenkins

*.rpm
/etc/sysconfig/hudson -> /etc/sysconfig/jenkins

For data compatibility, this release continues to use the 'hudson' user
and /var/lib/hudson to store data. I wonder if we should try to rename
those in coming releases --- your feedback would be appreciated.

In this release, we'd like to mostly rename Jelly files and help html
files, and leave parts that can affect compatibility, such as:

- system property names, environment variable names.
- names visible in URLs

While Andrew made a significant dent in the renaming in [1], he told me
there are more to be done. So if you know how to hack code and are
willing to lend some hands on renaming files, we could really use your help.

[1]
https://github.com/hudson/hudson/commit/bb991ada6d53c054fb5aff697532115c22538488
--
Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/

[Dean Yu]

For the sake of people that maintain private forks that track the community release, I ask the renaming be limited to what’s legally required. The opinion of some people before “The Event” was that class names and package names would not have to change. I hope this is true.

  -- Dean

[Kohsuke Kawaguchi]

On 01/30/2011 10:33 PM, Dean Yu wrote:
> For the sake of people that maintain private forks that track the
> community release, I ask the renaming be limited to what's legally
> required. The opinion of some people before "The Event" was that class
> names and package names would not have to change. I hope this is true.

You are right. I guess that was so obvious to me that I didn't mention
them in the list. I don't want to change those either, and certainly not
planning to do so any time soon.

[Monty Taylor]

On 01/30/2011 10:17 PM, Kohsuke Kawaguchi wrote:
>
> I posted the first bits of Jenkins and its packages at
> http://jenkins-ci.org/rc/ I'd appreciate if people would try those and
> let us know if there's anything wrong that should be fixed for the first
> release of Jenkins.
>
> The release is a drop-in replacement to Hudson. For those who are using
> native packages, note the following renames:
>
> *.deb:
> /etc/default/hudson -> /etc/default/jenkins
>
> *.rpm
> /etc/sysconfig/hudson -> /etc/sysconfig/jenkins
>
>
> For data compatibility, this release continues to use the 'hudson' user
> and /var/lib/hudson to store data. I wonder if we should try to rename
> those in coming releases --- your feedback would be appreciated.

I do think we should do this - and should add Conflicts: markers in the
control file and do renames in the preinst/postinst script. Alternately,
we could have jenkins Provides: hudson ... but I think it will be
cleaner to have the packages do renames.

I can do a little work on that for debian and see about submitting a
pull request...

[Kohsuke Kawaguchi]

And a question for those who speak Finnish.

There was a word "Hudsonista" in the Finnish translation, which
presumably mean "Hudson's". What's the equivalent for Jenkins? Jenkinsista?

On 01/30/2011 10:17 PM, Kohsuke Kawaguchi wrote:
>

[Juha Heimonen]

On Mon, Jan 31, 2011 at 10:15 AM, Kohsuke Kawaguchi
<kkawa...@cloudbees.com> wrote:
>
> And a question for those who speak Finnish.
>
> There was a word "Hudsonista" in the Finnish translation, which presumably
> mean "Hudson's". What's the equivalent for Jenkins? Jenkinsista?

I'd say "Jenkinsistä", so pretty close really :)

[Kohsuke Kawaguchi]

On 01/31/2011 12:15 AM, Monty Taylor wrote:
> On 01/30/2011 10:17 PM, Kohsuke Kawaguchi wrote:
>>
>> I posted the first bits of Jenkins and its packages at
>> http://jenkins-ci.org/rc/ I'd appreciate if people would try those and
>> let us know if there's anything wrong that should be fixed for the first
>> release of Jenkins.
>>
>> The release is a drop-in replacement to Hudson. For those who are using
>> native packages, note the following renames:
>>
>> *.deb:
>> /etc/default/hudson -> /etc/default/jenkins
>>
>> *.rpm
>> /etc/sysconfig/hudson -> /etc/sysconfig/jenkins
>>
>>
>> For data compatibility, this release continues to use the 'hudson' user
>> and /var/lib/hudson to store data. I wonder if we should try to rename
>> those in coming releases --- your feedback would be appreciated.
>
> I do think we should do this - and should add Conflicts: markers in the
> control file and do renames in the preinst/postinst script. Alternately,
> we could have jenkins Provides: hudson ... but I think it will be
> cleaner to have the packages do renames.

Conflicts tag is already added.

> I can do a little work on that for debian and see about submitting a
> pull request...

Cool! Looking forward to seeing this.

>
>> In this release, we'd like to mostly rename Jelly files and help html
>> files, and leave parts that can affect compatibility, such as:
>>
>> - system property names, environment variable names.
>> - names visible in URLs
>>
>> While Andrew made a significant dent in the renaming in [1], he told me
>> there are more to be done. So if you know how to hack code and are
>> willing to lend some hands on renaming files, we could really use your
>> help.
>>
>> [1]
>> https://github.com/hudson/hudson/commit/bb991ada6d53c054fb5aff697532115c22538488
>>
>
>

[henrik]

On Jan 31, 7:17 am, Kohsuke Kawaguchi <kkawagu...@cloudbees.com>
wrote:
> I posted the first bits of Jenkins and its packages athttp://jenkins-ci.org/rc/  I'd appreciate if people would try those and

> let us know if there's anything wrong that should be fixed for the first
> release of Jenkins.

I just upgraded our Hudson server to Jenkins with the Debian build. I
had to edit /etc/default/jenkins to match the previous configuration,
as you wrote, other than that there were no problems at all.

Great work!

Henrik

[Manuel Doninger]

Install as Windows Service doesn't work, i got the following exception:

java.io.IOException: Cannot run program
"N:\Jedi\Hudson_Working_Dir\hudson.exe" (in directory
"N:\Jedi\Hudson_Working_Dir"): CreateProcess error=2, The system
cannot find the file specified
at java.lang.ProcessBuilder.start(Unknown Source)
at hudson.Proc$LocalProc.(Proc.java:192)
at hudson.Proc$LocalProc.(Proc.java:164)
at hudson.Launcher$LocalLauncher.launch(Launcher.java:638)
at hudson.Launcher$ProcStarter.start(Launcher.java:273)
at hudson.Launcher$ProcStarter.join(Launcher.java:280)
at hudson.lifecycle.WindowsSlaveInstaller.runElevated(WindowsSlaveInstaller.java:107)
at hudson.lifecycle.WindowsInstallerLink.doDoInstall(WindowsInstallerLink.java:129)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:282)
at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:149)
at org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:88)
at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:102)

Manuel

[Wei-ju Wu]

Hi,

I would like to help with the renaming. What would be the best way to
start, so I won't
work on something that's already been done ?

Wei-ju

On Jan 30, 10:17 pm, Kohsuke Kawaguchi <kkawagu...@cloudbees.com>
wrote:
...

> While Andrew made a significant dent in the renaming in [1], he told me
> there are more to be done. So if you know how to hack code and are
> willing to lend some hands on renaming files, we could really use your help.
>

> [1]https://github.com/hudson/hudson/commit/bb991ada6d53c054fb5aff6975321...

[Andrew Bayer]

Test the release candidate first and foremost, I'd say - I think we've gotten most of the obvious places to change the name, but I'm just as sure we've missed some. If you find places it needs to be fixed, fork on Github, make the needed changes, and send in a pull request.

A.

[Wei-ju Wu]

Will do that.

Thanks, Wei-ju

[Wei-ju Wu]

Hi,

used the RC as a drop-in replacement on Tomcat 6/Mac OS X and it works
just fine
(I am not running it as a service though, so I can't tell if that
would break).

Question: Would the plugin update site which is

http://updates.hudson-labs.org/update-center.json

have to be renamed or does this fall under "names visible in URLs" ?

Wei-ju

[Kohsuke Kawaguchi]

Thanks. Fixed now.

[Kohsuke Kawaguchi]

Fixed this as well.

I pushed a new version that fixes all the problems reported thus far.

[Adam Purkiss]

So the question I have is should I rename the LinkedIn Group I maintain to

Hudson/Jenkins - Extensible continuous integration engine
Jenkins formally known as Hudson - Extensible continuous integration engine
or just
Jenkins - Extensible continuous integration engine

:)

Oh and is there a corrected logo? I can figure out Facebook another time as they dont allow renames so it would be a case of making a new group :)

[Mykola Nikishov]

On 31.01.11 21:09, Adam Purkiss wrote:

> Oh and is there a corrected logo? I can figure out Facebook another time as they dont allow renames so it would be a case of making a new group :)

https://github.com/hudson/hudson/blob/master/war/src/main/webapp/images/title.png
https://github.com/hudson/hudson/blob/master/war/src/main/webapp/images/title.svg
https://github.com/hudson/hudson/blob/master/war/src/main/webapp/images/title.xcf

[Richard Bywater]

I would say that you'll probably need to go with Jenkins otherwise
you'll probably fall foul of Oracle's Trademark I'm assuming...

Richard.

[Adam Purkiss]

So much for keeping it friendly :D

Will give things a little more time then make the change I guess

> Date: Tue, 1 Feb 2011 08:35:32 +1300
> Subject: Re: Hudson/Jenkins LinkedIn Group
> From: rbyw...@gmail.com
> To: hudso...@googlegroups.com

[Adam Purkiss]

Was hoping for one with the face on it unless we cannot use that now :)

> Date: Mon, 31 Jan 2011 21:32:08 +0200
> From: m...@mn.com.ua
> To: hudso...@googlegroups.com
> Subject: Logo, was Re: Hudson/Jenkins LinkedIn Group

[Vojtech Juranek]

These plugins
* build_publisher
* disk_usage
* groovy
works fine with given RC.
I also tried install jenkins from rpm and works fine for me as well

[Kohsuke Kawaguchi]

Great. Thanks for double checking.

[vtintillier]

Running as a service still does not work for me.

I get

D:\jenkins>net start jenkins
The jenkins service is starting.
The jenkins service could not be started.

A system error has occurred.

System error 1067 has occurred.

The process terminated unexpectedly.

And I see that in the Event viewer:

Child process [912 - java -Xrs -Xmx256m -Dhudson.lifecycle=hudson.lifecycle.WindowsServiceLifecycle -jar "D:\jenkins\.\jenkins.war" --httpPort=8080] terminated with 1


I downloaded the war this morning (around 9am GMT+1). When I start the java -Xrs ... command directly, it works.

I run on Windows 2003 server 32 bits with Sun JVM 1.6.0u22

Thanks

Vivien

[Jesper Skov]

On Jan 31, 7:17 am, Kohsuke Kawaguchi <kkawagu...@cloudbees.com>
wrote:

> I posted the first bits of Jenkins and its packages athttp://jenkins-ci.org/rc/  I'd appreciate if people would try those and

> let us know if there's anything wrong that should be fixed for the first
> release of Jenkins.

We use headless slaves that fetch the slave.jar via JavaWS.

I see that the slave.jar is still signed with "Hudson Project" (http://
hudson.dev.java.net) certificate. Should this not be changed?

Also, I have been manually accepting these certificates in the past,
but I would very much like to install them directly on the slave
before I run JavaWS.
Could you post the public part of the signing certificate somewhere,
so I (and others) can get at it, and add them to the trusted certs on
the slaves?

Cheers,
Jesper

[henrik]

On Jan 31, 7:17 am, Kohsuke Kawaguchi <kkawagu...@cloudbees.com>
wrote:

> I posted the first bits of Jenkins and its packages athttp://jenkins-ci.org/rc/  I'd appreciate if people would try those and

> let us know if there's anything wrong that should be fixed for the first
> release of Jenkins.

I found one problem after upgrading to Jenkins. When I try to save a
job that uses Clover, I get a 500 page with this stack trace:

org.kohsuke.stapler.NoStaplerConstructorException: There's no
@DataBoundConstructor on any constructor of class
hudson.plugins.clover.CloverPublisher
at
org.kohsuke.stapler.RequestImpl.loadConstructorParamNames(RequestImpl.java:
496)
at org.kohsuke.stapler.RequestImpl.bindParameters(RequestImpl.java:
314)
at org.kohsuke.stapler.RequestImpl.bindParameters(RequestImpl.java:
310)
at hudson.plugins.clover.CloverPublisher
$DescriptorImpl.newInstance(CloverPublisher.java:331)
at hudson.plugins.clover.CloverPublisher
$DescriptorImpl.newInstance(CloverPublisher.java:307)
at hudson.util.DescribableList.rebuild(DescribableList.java:146)
at hudson.maven.MavenModuleSet.submit(MavenModuleSet.java:818)
at hudson.model.Job.doConfigSubmit(Job.java:961)
at hudson.model.AbstractProject.doConfigSubmit(AbstractProject.java:
620)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
39)
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:
282)
...

Is this Jenkins' fault?

Henrik

[Jesper Skov]

On Feb 1, 12:13 pm, Jesper Skov <jskovjyskeban...@gmail.com> wrote:
> Also, I have been manually accepting these certificates in the past,
> but I would very much like to install them directly on the slave
> before I run JavaWS.

I figured this part out myself:

o Run Java WebStart once, load the Hudson slave and accept the
certificate.
o Open the Java Control Panel. On the Security pane, export the
Hudson certificate.
o Use keytool to import the certificate on slave machines
(to the keystore "c:\Documents and Settings\<username>\Application
Data\Sun\Java\Deployment\security\trusted.certs",
password 'changeit')

Hope it saves someone else some time :)

Thanks,
Jesper

[Mirko Friedenhagen]

My previous try got me a bounce as the reply to for the group was
still referencing the old group name :-)

---------- Forwarded message ----------
From: Mirko Friedenhagen <mfried...@gmail.com>
Date: Tue, Feb 1, 2011 at 10:00 PM
Subject: Re: Logo, was Re: Hudson/Jenkins LinkedIn Group
To: hudso...@googlegroups.com

Hopefully we did not blew up the repositories while transitioning:
https://github.com/jenkinsci/jenkins/blob/master/war/src/main/webapp/images/title.png
does exist, however following the link:
however the links states:
hudson / war / src / main / webapp / images / title.png
and the raw file is not accessible.
https://github.com/hudson/hudson/raw/dc7e05a4c33f709e3cafd095b1789c0e37bfd4cd/war/src/main/webapp/images/title.png

Replacing hudson with jenkins manually does work, however. Maybe some
caches must be reset.

https://github.com/jenkinsci/jenkins/raw/dc7e05a4c33f709e3cafd095b1789c0e37bfd4cd/war/src/main/webapp/images/title.png

Regards
Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/
https://bitbucket.org/mfriedenhagen/

--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/
https://bitbucket.org/mfriedenhagen/

[Mirko Friedenhagen]

Well, I had to reconfigure some parts, e.g. the audit plugin pointed
to /var/log/hudson/audit.log and in my special setup I had put the m2
repository and jobs beneath /home/hudson as /var was to small. Other
than that, things seem to work without a problem.

See: http://huschteguzzel.de/hudson/

[Olivier Lamy]

Works fine here (now used on my corp prod env)

2011/2/1 Mirko Friedenhagen <mfried...@gmail.com>

--
Olivier
http://twitter.com/olamy
http://fr.linkedin.com/in/olamy
http://www.viadeo.com/fr/profile/olivier.lamy7

[Kohsuke Kawaguchi]

On 02/01/2011 03:13 AM, Jesper Skov wrote:
> On Jan 31, 7:17 am, Kohsuke Kawaguchi<kkawagu...@cloudbees.com>
> wrote:
>> I posted the first bits of Jenkins and its packages athttp://jenkins-ci.org/rc/ I'd appreciate if people would try those and
>> let us know if there's anything wrong that should be fixed for the first
>> release of Jenkins.
>
> We use headless slaves that fetch the slave.jar via JavaWS.
>
> I see that the slave.jar is still signed with "Hudson Project" (http://
> hudson.dev.java.net) certificate. Should this not be changed?

Yes. Thanks for pointing that out. Fixed.

> Also, I have been manually accepting these certificates in the past,
> but I would very much like to install them directly on the slave
> before I run JavaWS.
> Could you post the public part of the signing certificate somewhere,
> so I (and others) can get at it, and add them to the trusted certs on
> the slaves?

I think the project needs to acquire a real code signing certificate for
releases. The RC bits and all local builds are signed by the same
self-signed certificate, and since anyone can sign anything with these
keys, you don't want to install this into your cacerts.

I believe I've been signing releases with my code signing certificate I
purchased.

>
> Cheers,
> Jesper

[Kohsuke Kawaguchi]

I've tested this with the fresh install and it works for me.

In d:\jenkins you should see a log file that captures stdout and stderr.
Do you see any messages in there?

[Kohsuke Kawaguchi]

My pleasure. Thanks for trying out the RC build.

On 02/01/2011 11:48 PM, henrik wrote:
> It was installed from the plugin database. I saw that there was an
> update now (Clover 3.0.2), which made the problem go away. Thanks for
> looking into this, though.
>
> Cheers,
> Henrik
>
> Den 01.02.11 23.23, skrev Kohsuke Kawaguchi:
>>
>> This is unlikely related to the core. Did you build the plugin from
>> source? Or otherwise it appears to be a genuine bug in the clover plugin.

[Robert Munteanu]

 Certum offer free code signing certificates for open source projects, if you need such a a certificate.

https://www.certum.eu/certum/cert,offer_java_code_signing.xml#

[Kohsuke Kawaguchi]

I suspect audit plugin isn't deferring to $JENKINS_HOME at runtime but
instead capturing it at the point of configuration.

I'm not sure how to "fix" those automatically, so I think I'll proceed
with 1.396 as originally planned.

On 02/01/2011 01:52 PM, Mirko Friedenhagen wrote:
> On Mon, Jan 31, 2011 at 3:01 PM, henrik<henrik....@gmail.com> wrote:
>> On Jan 31, 7:17 am, Kohsuke Kawaguchi<kkawagu...@cloudbees.com>
>> wrote:
>>> I posted the first bits of Jenkins and its packages athttp://jenkins-ci.org/rc/ I'd appreciate if people would try those and
>>> let us know if there's anything wrong that should be fixed for the first
>>> release of Jenkins.
>>
>> I just upgraded our Hudson server to Jenkins with the Debian build. I
>> had to edit /etc/default/jenkins to match the previous configuration,
>> as you wrote, other than that there were no problems at all.
>
> Well, I had to reconfigure some parts, e.g. the audit plugin pointed
> to /var/log/hudson/audit.log and in my special setup I had put the m2
> repository and jobs beneath /home/hudson as /var was to small. Other
> than that, things seem to work without a problem.
>
> See: http://huschteguzzel.de/hudson/
>
> Regards
> Mirko

--

[Kohsuke Kawaguchi]

Nice! I just finished the application. It'll likely take some time
before we get the certificate, but this is great.

Thanks for the information.

--
Kohsuke Kawaguchi http://kohsuke.org/

[vtintillier]

After a filemon analysis, it was a problem of access right to the jenkins.war. Running the service as my own user solved the problem. Sorry for the confusion, everything looks fine now :-)

[Andrew Gray]

I am also running Hudson 1.395 as a Windows Service and am itching to get Jenkins 1.396.

I noted this morning (about 8 hours ago) that the ChangeLog has 1.396 as the latest version.

How long does it take to "replicate" out to the update center.

Am waiting for the Manage Hudson page to say that a new version is available.

Cheers

Andrew

[henrik]

It was installed from the plugin database. I saw that there was an
update now (Clover 3.0.2), which made the problem go away. Thanks for
looking into this, though.

Cheers,
Henrik

Den 01.02.11 23.23, skrev Kohsuke Kawaguchi:
>
> This is unlikely related to the core. Did you build the plugin from
> source? Or otherwise it appears to be a genuine bug in the clover plugin.
>
> On 02/01/2011 03:16 AM, henrik wrote: