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

25 lines
636 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 20:07:12 +00:00
{ stdenv, fetchurl }:
stdenv.mkDerivation rec {
treewide: name -> pname (easy cases) (#66585) treewide replacement of stdenv.mkDerivation rec { name = "*-${version}"; version = "*"; to pname
2019-08-15 13:41:18 +01:00
pname = "jenkins";
jenkins: 2.176.3 -> 2.190.1
2019-09-26 15:37:15 +01:00
version = "2.190.1";
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 20:07:12 +00:00
src = fetchurl {
jenkins: 2.105 -> 2.89.3 (LTS)
2018-02-14 14:07:08 +00:00
url = "http://mirrors.jenkins.io/war-stable/${version}/jenkins.war";
jenkins: 2.176.3 -> 2.190.1
2019-09-26 15:37:15 +01:00
sha256 = "01bg8g1x0g479k0vz2dxzfkn6a3pp5sdqj6nmmmccgs2v4jivys6";
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 20:07:12 +00:00
};
jenkins: move .war file from $out to $out/lib/jenkins.war Fixes #14137, also known as: $ nix-shell -p jenkins bash: source: /nix/store/ln1yw6c2v8bb2cjqfr1z5aqcssw054wa-jenkins-2.3: cannot execute binary file [nix-shell exited with error] The problem is that jenkins.war is not installed inside the directory $out, but rather _as the file_ $out. Fix it by moving the file to $out/lib/jenkins.war. While at it, move buildCommand so that the "meta" section is at the end of the expression (standard style), and quote shell variables.
2016-07-15 13:45:23 +01:00
buildCommand = ''
jenkins: move $out/{lib => webapps}/jenkins.war As pointed out by @danbst, the tomcat NixOS module expects packages listed in services.tomcat.webapps to either be direct .war file paths or have .war files inside a "webapps" directory. Commit 4075c10a59af455db2012beb313453662f09dad0 ("jenkins: move .war file from $out to $out/lib/jenkins.war") broke jenkins + tomcat. Fix it by moving jenkins.war to $out/webapps/.
2016-07-15 15:57:16 +01:00
mkdir -p "$out/webapps"
cp "$src" "$out/webapps/jenkins.war"
jenkins: move .war file from $out to $out/lib/jenkins.war Fixes #14137, also known as: $ nix-shell -p jenkins bash: source: /nix/store/ln1yw6c2v8bb2cjqfr1z5aqcssw054wa-jenkins-2.3: cannot execute binary file [nix-shell exited with error] The problem is that jenkins.war is not installed inside the directory $out, but rather _as the file_ $out. Fix it by moving the file to $out/lib/jenkins.war. While at it, move buildCommand so that the "meta" section is at the end of the expression (standard style), and quote shell variables.
2016-07-15 13:45:23 +01: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 16:05:15 +01:00
meta = with stdenv.lib; {
description = "An extendable open source continuous integration server";
jenkins: 2.138.2 -> 2.138.3
2018-11-22 12:01:51 +00:00
homepage = https://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 16:05:15 +01:00
license = licenses.mit;
platforms = platforms.all;
jenkins: add earldouglas as a maintainer
2017-11-07 14:56:37 +00:00
maintainers = with maintainers; [ coconnor fpletz earldouglas ];
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 20:07:12 +00:00
};
}
Reference in New Issue Copy Permalink