While I would like my CI build to closely resemble a non-CI build, supporting
the `all-the-icons-install-fonts` call is a low priority with a medium amount of
work required.
After my CI build for Emacs failed because the .local/share/wallpaper directory
was missing I had two options:
A. include .local/share/wallpaper in default.nix, which is cumbersome
B. drop support for managing system wallpaper from Emacs
I chose option B.
I'm starting to prefer the `inherit (builtins) path` pattern in my Nix
expressions. I know this is idiomatic, so even if I don't like it, I am trying
to learn to like it.
These were hard-coded as $HOME/BRIEFCASE, which won't work in CI, since CI runs
as the user buildkite-agent-socrates, whose $HOME directory doesn't exist.
Instead of manually maintaining the list of directories that I expose to
readTree, I'm using `builtins.readDir` to get a list of all non-hidden top-level
directories.
TL;DR:
- Define runEmacsScript to emacs/default.nix for ci/pipelines/post-receive
- Write script.el to call (load init.el) and catch any errors
- Lint Elisp with gonewest818/elisp-lint
Also nice how Buildkite supports :gnu: emojis!
- Prefer prepending wpcDir, vendorDir to EMACSLOADPATH instead of using the
--directory flag
- Remove --load ${wpcPackageEl} because init.el calls (require 'wpc-package)
- Surround $@ in 2x-quotes
Following the advice of Domen's nix.dev anti-patterns, I'm preferring something
like...
```nix
builtins.path { path = /path/to/some.where; name = "some.where"; }
```
...to
```nix
/path/to/some/where
```
While the former is more verbose, it will fail to build when the path doesn't
exist, which I prefer.
I would prefer to define constants/briefcase in terms of `(getenv "BRIEFCASE")`
and assert that `(f-exists? (getenv "BRIEFCASE"))`, in one location:
constants.el
TL;DR:
- Prefer `(getenv "BRIEFCASE")` to `(f-expand "~/briefcase")`. I should audit my
Emacs for references to ~/briefcase and replace those calls with `getenv`.
- Remove calls setting <nixpkgs> and <depot> and rely exclusively on <briefcase>
- Prefer ~/nixpkgs-channels to ~/nixpkgs.
Notes:
- I need a better way of calling `home-manager switch` that resides within my
briefcase
I wanted Gitea to call Buildkite's pre-receive pipeline and either accept or
reject the incoming code depending on the outcome. The problem is that I can
only *create* builds from Gitea's pre-receive hook.
Now I'm left with two options:
1. run the lint-secrets step in post-receive
2. run `/nix/store/<hash>/git-secrets --scan-history $REPO_PATH` in Gitea
As far as I can tell, I cannot define Gitea hooks in Nix, which is unfortunate;
otherwise, option 2 would appeal more.
I'm doing option one for now.
So it turns out that I was wrong and that .git/config is stateful. Multiple
calls to --add-provider will append the same provider each time...
Instead I'm defining secret-patterns.txt and version-controlling it.
Then:
- dev-side: I'm adding `providers = cat ci/secret-patterns.txt` to .git/config
- ci-side: I'm adding `providers = cat ci/secret-patterns.txt` to .git/config
Unfortunately this is ad-hoc configuration ci-side, which I would like to
avoid. The good news is that my pre-commit hooks and failures from git-secrets
should now align with my CI, since they're both reading from
secret-patterns.txt. One step backwards... two steps forwards?
