This option allows to define (declarative) Jenkins jobs, using Jenkins
Job Builder (JJB) as backend.
Example:
services.jenkins = {
enable = true;
jobBuilder = {
enable = true;
yamlJobs = ''
- job:
name: jenkins-job-test
builders:
- shell: echo 'Hello world!'
'';
};
};
Jobs can be defined using YAML, JSON and Nix.
Note that it really is declarative configuration; if you remove a
previously defined job, the module will remove the jobdir under
$JENKINS_HOME.
Jobs managed through the Jenkins WebUI (or by other means) are not
touched by this module.
Changes v1 -> v2:
* add nixJobs
* let jsonJobs take a list of strings (allows merge)
* 4 space indent in shell code
Regression introduced by b21fd5d066.
The initialScript is only executed whenever there is a .first-startup in
the dataDir, so silently dropping the file essentially breaks
initialScript functionality.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Since commits 89e9837 and 5b8dae8 the manual no longer depends on
evaluation of any packages from nixpkgs, so all errors of the form
"Package 'foo' is not supported on 'armv7l-linux'" are gone.
I needed to add sdhci_acpi and mmc_block to my initrd modules in order to boot
my Chromebook. Looking under /sys/class/mmc_host/*/device/driver/module will
give us the sdhci_acpi dependency.
This makes the firmware available (or would, if someone switched off
enableAllFirmware). Corresponding kernel module should get auto-loaded.
See #9948. Close#9971.
Option aliases/deprecations can now be declared in any NixOS module,
not just in nixos/modules/rename.nix. This is more modular (since it
allows for example grub-related aliases to be declared in the grub
module), and allows aliases outside of NixOS (e.g. in NixOps modules).
The syntax is a bit funky. Ideally we'd have something like:
options = {
foo.bar.newOption = mkOption { ... };
foo.bar.oldOption = mkAliasOption [ "foo" "bar" "newOption" ];
};
but that's not possible because options cannot define values in
*other* options - you need to have a "config" for that. So instead we
have functions that return a *module*: mkRemovedOptionModule,
mkRenamedOptionModule and mkAliasOptionModule. These can be used via
"imports", e.g.
imports = [
(mkAliasOptionModule [ "foo" "bar" "oldOption" ] [ "foo" "bar" "newOption" ]);
];
As an added bonus, deprecation warnings now show the file name of the
offending module.
Fixes#10385.
I doubt that ordering non-sysvinit services after network.target ever
makes sense. In this case, CopyConsole requires DNS lookups and fails
if these are not yet possible.
Synergy seems to get more and more unstable in recent versions, so we
might want to debug this properly. However, it makes sense to restart
the service nevertheless, because synergy is about keyboard and mouse
sharing and it's quite annoying to either SSH in to restart the service
or even needing to unplug the keyboard and plug in into the machine with
the failing service.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Trigger a restart of the post-resume.target on resume.
That allows other systemd services to receive the restart signal
after resume by becoming 'partOf' the post-resume.target.
Jenkins gets (by default) an additional environment of
{ NIX_REMOTE = "daemon"; }
This has the following problems:
1. NIX_REMOTE disappears when users specify additional environment
variables, because defaults have low merge priority.
2. nix cannot be used without additional NIX_PATH envvar, which is
currently missing.
3. If you try to use HTTPS, you'll see that jenkins lacks
SSL_CERT_FILE envvar, causing it to fail.
This commit adds config.environment.sessionVariables and NIX_REMOTE to
the set of variables that are always there for jenkins, making nix and
HTTPS work out of the box.
services.jenkins.environment is now empty by default.
Commit 9bfe92ecee ("docker: Minor improvements, fix failing test") added
the services.docker.storageDriver option, made it mandatory but didn't
give it a default value. This results in an ugly traceback when users
enable docker, if they don't pay enough attention to also set the
storageDriver option. (An attempt was made to add an assertion, but it
didn't work, possibly because of how "mkMerge" works.)
The arguments against a default value were that the optimal value
depends on the filesystem on the host. This is, AFAICT, only in part
true. (It seems some backends are filesystem agnostic.) Also, docker
itself uses a default storage driver, "devicemapper", when no
--storage-driver=x options are given. Hence, we use the same value as
default.
Add a FIXME comment that 'devicemapper' breaks NixOS VM tests (for yet
unknown reasons), so we still run those with the 'overlay' driver.
Closes#10100 and #10217.
When using the ZFS storagedriver in docker, it shells out for the ZFS
commands. The path configuration for the systemd task does not include
ZFS, so if the driver is set to ZFS, add ZFS utilities to the PATH.
This will resolve https://github.com/NixOS/nixpkgs/issues/10127
[Bjørn: prefix commit message with "nixos/docker:", remove extra space
before ';']
based on @eldostra feedback:
* remove user and group configuration, because it is probably
unnecessary
* remove libraryDir default
* capitalize and shorten service description
Configuration option for setting up virtual WLAN interfaces.
If the hardware NIC supports it, then multiple virtual WLAN interfaces can be
configured through the options of the new 'networking.wlanInterfaces' module.
For example, the following configuration transforms the device with the persistent
udev name 'wlp6s0' into a managed and a ad hoc device with the device names
'wlan-managed0' and 'wlan-adhoc0', respectively:
networking.wlanInterfaces = {
"wlan-managed0" = {
type = "managed";
device = "wlp6s0";
};
"wlan-adhoc0" = {
type = "ibss";
device = "wlp6s0";
};
};
Internally, a udev rule is created that matches wlp6s0 and runs a script which adds
the missing virtual interfaces and re-configures the wlp6s0 interface accordingly.
Once the new interfaces are created by the Linux kernel, the configuration of the
interfaces is managed by udev and systemd in the usual way.
If nixos-install is run on a machine with `nix.distributedBuilds = true`
the installation will fail at some point like this:
Died at /nix/store/4frhrl31cl7iahlz6vyvysy5dmr6xnh3-nix-1.10/libexec/nix/build-remote.pl line 115, <STDIN> line 1.
This is due to `nix.distributedBuilds` setting
NIX_BUILD_HOOK=/nix/store/.../build-remote.pl in the global environment,
which then gets confused in the minimal chroot created by nixos-install.
To avoid these kinds of issues with build hooks, just disable them in
the chroot.
Adding the configuration option 'systemd.generators' to
specify systemd system-generators. The option allows to
either add new system-generators to systemd, or to over-
ride or disable the system-generators provided by systemd.
Internally, the configuration option 'systemd.generators'
maps onto the 'environment.etc' configuration option.
Having a convenience wrapper around 'environment.etc' helps
to group the systemd system-generator configuration more
easily with other 'systemd...' configurations.
This prevents seeing lots of warnings about missing hashes/sizes in the
database when running "nix-store --verify --check-contents" for the
first time.
The EBS and S3 (instance-store) AMIs are now created from the same
image. HVM instance-store AMIs are also generated.
Disk image generation has been factored out into a function
(nixos/lib/make-disk-image.nix) that can be used to build other kinds
of images.
This fixes#10077 because after some debugging it turns out that by
default we don't have a font which is able to display Chinese symbols.
Thanks to @anderspapitto, @kmicu and hyper_ch on IRC to help debugging
this issue, see log at:
http://nixos.org/irc/logs/log.20150926 starting at 19:46
With unifont we have a reasonable fallback font to ensure that every
written language is rendered correctly and thus less surprise for new
users who keep their font settings at the default.
Reported-by: Anders Papitto <anderspapitto@gmail.com>
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Since 74209a4 we have initial support for the "vboxsf" (VirtualBox
shared folder) file system support. This will be cherry-picked to
release-15.09 so we need to notice people about the change.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
There were quite a few configuration options which were tagged via
<literal/>, so in order to keep consistency with other docbook manuals
in the source tree, let's use <option/> here.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
I'm not quite sure why the official Hydra gets a kernel panic in one of
two VMs using the exact same kernels:
https://hydra.nixos.org/build/26339384
Because the kernel panic happens before stage 1, let's wait for the
first VM to boot up and after the bootup is done, start the second one
in hope that it won't trigger the panic.
Oddly enough, whenever I run the test on my own Hydra and on my local
machines, I don't get anything like that.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
I forgot to do this in da0e642. It shouldn't be a big problem but it's
more clean to destroy the VM once we're done testing.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
We previously had 1024 MB of memory to fit a VirtualBox VM with 512 MB
plus the memory needed of the VirtualBox host VM. That obviously won't
work for two VirtualBox VMs, which are used for testing networking
between two VirtualBox guests.
Now, we have 2048 MB on the qemu guest (the VirtualBox host) and 768 MB
for each VirtualBox guest. That should be enough to fit in two
VirtualBox guests (I hope).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The default options for all file systems currently are
"defaults.relatime", which works well on file systems which support the
relatime option.
Unfortunately, this is not the case for the VirtualBox shared folder
filesystem, so until now, you need to set something like:
fileSystems."/foo" = {
device = "foo";
fsType = "vboxsf";
options = "defaults";
};
Otherwise mounting the file system would fail.
Now, we provide only the "defaults" option to the "vboxsf" file system,
so something like this is enough:
fileSystems."/foo" = {
device = "foo";
fsType = "vboxsf";
};
An alternative to that could be to document that you need to set default
options, but we really should do what users expect instead of forcing
them to look up the documentation as to why this has failed.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Unfortunately, we can't test whether USB is really working, but we can
make sure that VirtualBox has access to the USB devices.
This is essentially testing #9736, which I haven't yet been able to
reproduce though, but it makes sense to test it so it won't happen in
future releases.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
