Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 453658 - dev-util/jenkins - application that monitors executions of repeated jobs, such as building a software project or jobs run by cron.
Summary: dev-util/jenkins - application that monitors executions of repeated jobs, suc...
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: Normal enhancement with 2 votes (vote)
Assignee: Default Assignee for New Packages
URL: http://jenkins-ci.org/
Whiteboard:
Keywords: EBUILD
Depends on: 157550 needsMaven
Blocks:
  Show dependency tree
 
Reported: 2013-01-23 11:38 UTC by Christian Strahl
Modified: 2019-06-23 11:10 UTC (History)
7 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
jenkins-bin-1.466.2-r1.ebuild (jenkins-bin-1.466.2-r1.ebuild,959 bytes, text/plain)
2013-01-28 17:40 UTC, Christian Strahl
Details
file/conf (conf,853 bytes, text/plain)
2013-01-28 17:40 UTC, Christian Strahl
Details
files/init.sh (init.sh,1.83 KB, text/plain)
2013-01-28 17:41 UTC, Christian Strahl
Details
jenkins-bin-1.527.ebuild (jenkins-bin-1.527.ebuild,1023 bytes, text/plain)
2013-08-15 23:12 UTC, Bertrand Jacquin
Details
jenkins-bin-1.509.2.ebuild (jenkins-bin-1.509.2.ebuild,1.00 KB, text/plain)
2013-08-15 23:12 UTC, Bertrand Jacquin
Details
files/jenkins.initd (jenkins.initd,2.04 KB, text/plain)
2013-08-15 23:13 UTC, Bertrand Jacquin
Details
files/jenkins.confd (jenkins.confd,841 bytes, text/plain)
2013-08-15 23:14 UTC, Bertrand Jacquin
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Strahl 2013-01-23 11:38:35 UTC
Jenkins is an application that monitors executions of repeated jobs, such as building a software project or jobs run by cron. Among those things, current Jenkins focuses on the following two jobs:

1. Building/testing software projects continuously (continuous integration)
2. Monitoring executions of externally-run jobs

Reproducible: Always




Here you can find an ebuild for jenkins:
https://code.google.com/p/godin-gentoo-repository/source/browse/trunk/repository/dev-util/jenkins-bin/
Comment 1 Christian Strahl 2013-01-28 17:40:11 UTC
Created attachment 337128 [details]
jenkins-bin-1.466.2-r1.ebuild

works for me
Comment 2 Christian Strahl 2013-01-28 17:40:39 UTC
Created attachment 337130 [details]
file/conf
Comment 3 Christian Strahl 2013-01-28 17:41:08 UTC
Created attachment 337132 [details]
files/init.sh
Comment 4 Bertrand Jacquin 2013-08-15 23:12:06 UTC
Created attachment 356130 [details]
jenkins-bin-1.527.ebuild

Version bump for current release, add a USE=standalone when using tomcat as a frontend
Comment 5 Bertrand Jacquin 2013-08-15 23:12:26 UTC
Created attachment 356132 [details]
jenkins-bin-1.509.2.ebuild

Version bump for LTS release, add a USE=standalone when using tomcat as a frontend
Comment 6 Bertrand Jacquin 2013-08-15 23:13:28 UTC
Created attachment 356136 [details]
files/jenkins.initd

Rewrite of original init.d to support /run and construct init inspired from tomcat init script
Comment 7 Bertrand Jacquin 2013-08-15 23:14:11 UTC
Created attachment 356138 [details]
files/jenkins.confd

Updated files/jenkins.confd according to previous files/jenkins.initd
Comment 8 Bertrand Jacquin 2013-08-15 23:14:43 UTC
All this work can be followed at http://git.meleeweb.net/cgit.cgi/distros/gentoo/portage.git/log/dev-util/jenkins-bin
Comment 9 Tom Wijsman (TomWij) (RETIRED) gentoo-dev 2013-08-18 08:43:30 UTC
For Java packages we prefer them to be build from source when they can, as well as to unbundle any dependencies that may arise.

For Jenkins, we will again have to work with snapshotting to do this; we can basically capture a snapshot of https://ci.jenkins-ci.org/view/Jenkins%20core/job/jenkins_main_trunk/ws/ (using zip link at the bottom) and then work on getting that compiled.

A very first step would then be to run `mvn ant:ant` to obtain a build.xml file which can be placed in the files directory, then from java_prepare (not src_prepare!) that file can be copied to ${S}, after which you include java-ant-2; from there on the rest of http://www.gentoo.org/proj/en/java/java-devel.xml can be followed.

Bin packages usually are a product of compiling them our own and hosting our compilation results; there are some exceptions in the tree, but they merely are based on the high need for those packages and the complexity of doing it our own.

It might be the case that jenkins needs to split up in multiple packages; as you can see, most of the directories contain their own file, so we would for example have jenkins-core, jenkins-plugin and so on...

But after all, it doesn't look too complex to package.
Comment 10 Julian Ospald 2013-08-18 10:51:40 UTC
I accept precompiled java bloat in sunrise since java sucks anyway and there is almost zero gain.
Comment 11 Tom Wijsman (TomWij) (RETIRED) gentoo-dev 2013-08-18 11:14:23 UTC
From the .git directory I found that there are source code releases available:

https://github.com/jenkinsci/jenkins/releases
Comment 12 Tom Wijsman (TomWij) (RETIRED) gentoo-dev 2013-08-18 11:38:59 UTC
We first need to add hudson from bug #157550.
Comment 13 Christian Strahl 2013-08-20 16:54:52 UTC
(In reply to Tom Wijsman (TomWij) from comment #12)
> We first need to add hudson from bug #157550.

Why this bug should depend on hudson?
From the time of the fork, the two are independent?
Comment 14 Tom Wijsman (TomWij) (RETIRED) gentoo-dev 2013-08-20 17:23:51 UTC
(In reply to Christian Strahl from comment #13)
> (In reply to Tom Wijsman (TomWij) from comment #12)
> > We first need to add hudson from bug #157550.
> 
> Why this bug should depend on hudson?
> From the time of the fork, the two are independent?

Thanks for the question and detail, let's me explain and look close:

It fails to build because hudson is missing; so, it seems to be necessary.

Small excerpt listing some from /var/tmp/portage/dev-java/jenkins-core-1.527/work/jenkins-jenkins-1.527/core/pom.xml:

    ...
    <dependency>
      <groupId>org.jvnet.hudson</groupId>
      <artifactId>jtidy</artifactId>
      <version>4aug2000r7-dev-hudson-1</version>
      <exclusions>
        <exclusion>
          <groupId>jdom</groupId>
          <artifactId>jdom</artifactId>
        </exclusion>
      </exclusions>
    </dependency>
    ...
    <dependency>
      <groupId>org.jvnet.hudson</groupId>
      <artifactId>task-reactor</artifactId>
      <version>1.2</version>
    </dependency>
    ...
    <dependency>
      <groupId>org.jvnet.hudson</groupId>
      <artifactId>activation</artifactId>
      <version>1.1.1-hudson-1</version>
    </dependency>
    ...

Small excerpt from the build log:

    [javac] /var/tmp/portage/dev-java/jenkins-core-1.527/work/jenkins-jenkins-1.527/core/src/main/java/jenkins/model/Jenkins.java:34: error: cannot find symbol
    [javac] import hudson.model.Messages;
    [javac]                    ^
    [javac]   symbol:   class Messages
    [javac]   location: package hudson.model

On a second look:

There however are some parts of hudson present, actually the above class does appear to be there under the form of ./work/jenkins-jenkins-1.527/core/src/main/resources/hudson/model/Messages.properties; so, this might also be the consequence of building with Ant instead of Maven. Because as long as there is no source build Maven in the tree, we cannot build it that way...

The structure indeed seems to fork but it does more than that and actually wrap around the code; so, it is a source bundled library. To end up with sane ebuilds, we will need to separately package this under the form of something like jenkins-hudson-*. Packaging hudson on its own will come as a benefit; as what we achieve there, can easily be reused to package this source bundled library. Especially since the recursive logic appears to be missing here.
Comment 15 Bertrand Jacquin 2013-08-21 00:05:50 UTC
(In reply to Tom Wijsman (TomWij) from comment #9)
> For Java packages we prefer them to be build from source when they can, as
> well as to unbundle any dependencies that may arise.
> 
> For Jenkins, we will again have to work with snapshotting to do this; we can
> basically capture a snapshot of
> https://ci.jenkins-ci.org/view/Jenkins%20core/job/jenkins_main_trunk/ws/
> (using zip link at the bottom) and then work on getting that compiled.

All the instruction to build Jenkins from sources is available at https://wiki.jenkins-ci.org/display/JENKINS/Building+Jenkins

This need mvn that is provided by dev-java/maven-bin which itself is not compiled from source in portage tree. Maven is pretty fat bloat if I'm not wrong (but probably) and bring a lot of dependencies (even dev-java/osgi-core-api with fetch RESTRICT). Anyway I'm trying to make it compile from source with your recommendation.

> It might be the case that jenkins needs to split up in multiple packages; as
> you can see, most of the directories contain their own file, so we would for
> example have jenkins-core, jenkins-plugin and so on...

Good idea. On the way to do this.
Comment 16 Samuel Damashek (RETIRED) gentoo-dev 2014-01-19 23:34:07 UTC
What's the status on this?
Comment 17 Bertrand Jacquin 2014-01-20 14:09:37 UTC
(In reply to Samuel Damashek from comment #16)
> What's the status on this?

I continue to maintain binary ebuild as mvn usage is a bit huge for my current needs.
Comment 18 Samuel Damashek (RETIRED) gentoo-dev 2014-01-20 14:41:21 UTC
(In reply to Bertrand Jacquin from comment #17)
> I continue to maintain binary ebuild as mvn usage is a bit huge for my
> current needs.

I don't see an issue with adding an mvn ebuild; we have a lot of other huge packages in the tree as well. That's off topic though, does that prevent us from adding a jenkins ebuild?
Comment 19 Bertrand Jacquin 2014-01-20 16:20:15 UTC
(In reply to Samuel Damashek from comment #18)
> (In reply to Bertrand Jacquin from comment #17)
> > I continue to maintain binary ebuild as mvn usage is a bit huge for my
> > current needs.
> 
> I don't see an issue with adding an mvn ebuild; we have a lot of other huge
> packages in the tree as well. That's off topic though, does that prevent us
> from adding a jenkins ebuild?

Not at all. The point is that building jenkins from source with mvn is a huge work while binary packages provided by jenkins-ci are fine for me.
Comment 20 Jeroen Roovers (RETIRED) gentoo-dev 2014-10-21 07:53:05 UTC
*** Bug 526166 has been marked as a duplicate of this bug. ***
Comment 21 Christian Strahl 2014-12-31 13:24:15 UTC
Jenkins is now in portage: dev-util/jenkins-bin
This bug can be closed.
Comment 22 Patrice Clement gentoo-dev 2014-12-31 13:31:58 UTC
Indeed Christian so I'm gonna go ahead and close to bug so that it clears up a bit the bugzilla queue. Please reopen in case of problems.
Comment 23 Manuel Rüger (RETIRED) gentoo-dev 2014-12-31 13:42:12 UTC
No, it is not fixed yet, as jenkins-bin is just a binary package.
This is a bad workaround for packages, that you cannot compile from source easily.
Please check if dev-utils/jenkins is added to the tree, before marking this bug as resolved.