public
/
nixpkgs
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
nixpkgs/pkgs/development/tools/continuous-integration/jenkins/default.nix

21 lines
555 B
Nix
Raw Normal View History

Add jenkins continuous integration server and user. By default the jenkins server is executed under the user "jenkins". Which can be configured using users.jenkins.* options. If a different user is requested by changing services.jenkins.user then none of the users.jenkins options apply. This patch does not include jenkins slave configuration. Some config options will probably change when this is implemented. Aspects like the user and environment are typically identical between slave and master. The service configs are different. The design is for users.jenkins to cover the shared aspects while services.jenkins and services.jenkins-slave cover the master and slave specific aspects, respectively. Another option would be to place everything under services.jenkins and have a config that selects master vs slave.
2014-02-10 12:07:12 -08:00
{ stdenv, fetchurl }:
stdenv.mkDerivation rec {
jenkins: expression cleanup * Include version number in package name * Remove trailing dot in meta.description * Simplify meta by using "with stdenv.lib;"
2014-09-08 08:05:15 -07:00
name = "jenkins-${version}";
jenkins: 1.594 -> 1.631
2015-09-30 08:25:39 -07:00
version = "1.631";
Add jenkins continuous integration server and user. By default the jenkins server is executed under the user "jenkins". Which can be configured using users.jenkins.* options. If a different user is requested by changing services.jenkins.user then none of the users.jenkins options apply. This patch does not include jenkins slave configuration. Some config options will probably change when this is implemented. Aspects like the user and environment are typically identical between slave and master. The service configs are different. The design is for users.jenkins to cover the shared aspects while services.jenkins and services.jenkins-slave cover the master and slave specific aspects, respectively. Another option would be to place everything under services.jenkins and have a config that selects master vs slave.
2014-02-10 12:07:12 -08:00
src = fetchurl {
url = "http://mirrors.jenkins-ci.org/war/${version}/jenkins.war";
jenkins: 1.594 -> 1.631
2015-09-30 08:25:39 -07:00
sha256 = "0bfh5gv3yk9awkzf660jxf9vzzdcr6qa9hl0hkivaj4gmp5f9sp8";
Add jenkins continuous integration server and user. By default the jenkins server is executed under the user "jenkins". Which can be configured using users.jenkins.* options. If a different user is requested by changing services.jenkins.user then none of the users.jenkins options apply. This patch does not include jenkins slave configuration. Some config options will probably change when this is implemented. Aspects like the user and environment are typically identical between slave and master. The service configs are different. The design is for users.jenkins to cover the shared aspects while services.jenkins and services.jenkins-slave cover the master and slave specific aspects, respectively. Another option would be to place everything under services.jenkins and have a config that selects master vs slave.
2014-02-10 12:07:12 -08:00
};
jenkins: expression cleanup * Include version number in package name * Remove trailing dot in meta.description * Simplify meta by using "with stdenv.lib;"
2014-09-08 08:05:15 -07:00
meta = with stdenv.lib; {
description = "An extendable open source continuous integration server";
Add jenkins continuous integration server and user. By default the jenkins server is executed under the user "jenkins". Which can be configured using users.jenkins.* options. If a different user is requested by changing services.jenkins.user then none of the users.jenkins options apply. This patch does not include jenkins slave configuration. Some config options will probably change when this is implemented. Aspects like the user and environment are typically identical between slave and master. The service configs are different. The design is for users.jenkins to cover the shared aspects while services.jenkins and services.jenkins-slave cover the master and slave specific aspects, respectively. Another option would be to place everything under services.jenkins and have a config that selects master vs slave.
2014-02-10 12:07:12 -08:00
homepage = http://jenkins-ci.org;
jenkins: expression cleanup * Include version number in package name * Remove trailing dot in meta.description * Simplify meta by using "with stdenv.lib;"
2014-09-08 08:05:15 -07:00
license = licenses.mit;
platforms = platforms.all;
maintainers = [ maintainers.coconnor ];
Add jenkins continuous integration server and user. By default the jenkins server is executed under the user "jenkins". Which can be configured using users.jenkins.* options. If a different user is requested by changing services.jenkins.user then none of the users.jenkins options apply. This patch does not include jenkins slave configuration. Some config options will probably change when this is implemented. Aspects like the user and environment are typically identical between slave and master. The service configs are different. The design is for users.jenkins to cover the shared aspects while services.jenkins and services.jenkins-slave cover the master and slave specific aspects, respectively. Another option would be to place everything under services.jenkins and have a config that selects master vs slave.
2014-02-10 12:07:12 -08:00
};
buildCommand = "ln -s $src $out";
}