Warn users when they configure a relative path. We want to encourage
using absolute paths and env variables.
Signed-off-by: Austin Horstman <khaneliman12@gmail.com>
We currently only need the tests covered by test-chunks in CI. We will
migrate more tests into the buildbot CI, as we are able to flesh them
out more.
Signed-off-by: Austin Horstman <khaneliman12@gmail.com>
We have lots of tests and would like to add more. However, adding more
testing coverage comes at the cost of a slower CI when we run them
sequentially. This adds test outputs that are chunked however we'd like
to tune for batch sizes. Allowing us to create a parallelized CI
workflow.
Signed-off-by: Austin Horstman <khaneliman12@gmail.com>
Previously, a stateVersion check for 20.03 determined whether or not the input to
`programs.zsh.history.path` would be prepended with `$HOME`. However, this was not
communicated in the documentation, which stated the version check determined whether
the default histfile location would be in `programs.zsh.dotDir` or
`home.homeDirectory`.
The current change simplifies matters and brings path handling in-line with that of
the preceding work on dotDir path handling. If a relative path is provided, it is
parsed as being relative to `home.homeDirectory`. Both absolute and relative paths
are supported, and are cleaned before being passed to other functions.
Tests have been rewritten for the new logic, with case handling for reusability.
Signed-off-by: Austin Horstman <khaneliman12@gmail.com>
Previously, `config.programs.zsh.dotDir` prepended strings with `$HOME`.
This caused issues like nix-community#5100, where `$HOME` is
inconsistently resolved in time for the evaluation of the option. The handling
of this variable is also inconsistent with how paths are handled elsewhere,
including within the same module, where `config.programs.zsh.history.path`
does not mutate the supplied string.
To preserve backwards compatibility, this change prepends
`config.home.homeDirectory` to relative paths, while assigning absolute paths
unchanged. Tests for both cases are added.
Signed-off-by: Austin Horstman <khaneliman12@gmail.com>
- Automatically include "$schema": "https://opencode.ai/config.json" in the generated
opencode config.json file
- Update documentation to mention the added schema property
- Add corresponding "$schema" entry in test config.json file for validation purposes
Closes#7506
- Introduce `rules` option to provide global custom instructions for opencode
- Write `rules` content to `~/.config/opencode/AGENTS.md` if non-empty
- Update tests to cover presence and absence of `AGENTS.md` file with rules content
This commit deprecates profile management from the activation script.
The profile management is instead the responsibility of the driving
software, for example, the `home-manager` tool in the case of
standalone installs.
The legacy behavior is still available for backwards compatibility but
may be removed in the future.
The new behavior resolves (or moves us closer to resolving) a number
of long standing open issues:
- `home-manager switch --rollback`, which performs a rollback to the
previous Home Manager generation before activating. While it was
previously possible to accomplish this by activating an old
generation, it did always create a new profile generation.
This option has been implemented as part of this commit.
- `home-manager switch --specialisation NAME`, which switches to the
named specialisation. While it was previously possible to accomplish
this by manually running the specialisation activate script, it did
always create a new profile generation.
This option has been implemented as part of this commit.
- `home-manager switch --test`, which activates the configuration but
does not create a new profile generation.
This option has _not_ been implemented here since it relies on the
current configuration being activated on login, which we do not
currently do.
- When using the "Home Manager as a NixOS module" installation method
we previously created an odd `home-manager` per-user "shadow
profile" for the user. This is no longer necessary.
This has been implemented as part of this commit.
Fixes#3450
These were removed as part of dead code removal, but they are actually
needed in the integration tests for comparing with the configuration
generated by the installation.
This adds support for generating ordered children and nodes with
attributes and/or properties but no children. These are both needed to
generate zellij keybinding configuration.
VS Code 1.102 separates MCP configuration from `settings.json` to a profile-specific `mcp.json`. VS Code automatically performs this separation if MCP configuration is detected inside `settings.json` which conflicts with the immutability of the settings.json that home-manager supplies.
We can now customize a lot more in the gtk module. Test more scenarios
to ensure a user has more control over what gets generated.
Signed-off-by: Austin Horstman <khaneliman12@gmail.com>
Adds extension permissions as suggested in
https://github.com/nix-community/home-manager/issues/7001.
Adds the 'profiles.<name>.extensions.settings.<name>.permissions' to Firefox
derivatives. If set, this option adds an assertion that fails if an extension
package requests permissions that weren't added to the permissions option. In
order to not require 'profiles.<name>.extensions.force' to be set when only
permissions, but no extension settings were defined, the relevant assertions
were changed. They now check whether any 'extensions.settings.<name>.settings'
was set instead of checking whether 'extensions.settings' was set.
---------
Co-authored-by: Robert Helgesson <robert@rycee.net>
Co-authored-by: awwpotato <awwpotato@voidq.com>
