about summary refs log tree commit diff
AgeCommit message (Collapse)AuthorFilesLines
2020-08-27 Clean up emacs/default.nixWilliam Carroll1-5/+2
- 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
2020-08-27 Remove exported DEPOT env var from wpcarros-emacsWilliam Carroll1-3/+0
wpcarros-emacs no longer depends on this being set.
2020-08-27 Prefer builtins.pathWilliam Carroll2-6/+32
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.
2020-08-26 Delete unused parts of bookmark.elWilliam Carroll1-44/+1
Trimming more fat.
2020-08-25 Remove bookmark for <depot>William Carroll1-3/+0
Since depot now support cs.tvl.fyi, I don't need this, and that is a *massive* upgrade.
2020-08-25 Replace calls to (getenv "BRIEFCASE") with constants/briefcaseWilliam Carroll4-10/+17
I would prefer to define constants/briefcase in terms of `(getenv "BRIEFCASE")` and assert that `(f-exists? (getenv "BRIEFCASE"))`, in one location: constants.el
2020-08-25 Prefer <leader>jb to <leader>jd for searching all of briefcaseWilliam Carroll1-1/+1
Feels more natural...
2020-08-25 Delete org-helpersWilliam Carroll4-35/+0
I'm trying to tidy things up, so I'm trying to apply some of the principles from "Essentialism" to my Emacs configuration.
2020-08-25 Remove unnecessary TODOWilliam Carroll1-2/+0
The Nix expression that builds `wpcarros-emacs` sets BRIEFCASE, so the .envrc isn't relied on.
2020-08-25 Remove unnecessary code from wpc-nix.elWilliam Carroll1-5/+2
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
2020-08-24 Prefer simpler, more idiomatic project-find-functionWilliam Carroll1-24/+5
This version avoids installed all of the custom `cl-defmethods` for a `'monorepo` type and instead uses the existing `'transient`.
2020-08-22 Abandon the pre-receive hookWilliam Carroll2-11/+6
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.
2020-08-22 Define Buildkite pipelines corresponding to git server hooksWilliam Carroll3-19/+20
I think maintaining a 1:1 correspondence with the git server hook makes sense right now. Let's try it out!
2020-08-22 Ensure that the build step "depends on" the lint stepWilliam Carroll1-0/+3
This way, if the lint step fails, the build step doesn't run. Nice!
2020-08-22 Remove --add-provider step from briefcase lintWilliam Carroll2-18/+10
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?
2020-08-22 Call --add-provider during lint stageWilliam Carroll1-3/+16
I'm also `cat .git/config` because I think the Buildkite destroys the .git/config file for each build, but I want to verify that. If it does, I prefer that because it seems to share the spirit of the "Destroy Your Darlings" essay.
2020-08-22 Log git information during briefcase's lint stageWilliam Carroll1-1/+5
I would like to find out what the state of the repo is during pre-receive hook.
2020-08-22 Replace build badgeWilliam Carroll1-1/+1
Changed pipelines = new badge.
2020-08-21 Prefer :nix: emojiWilliam Carroll2-2/+2
Buildkite support language extensions as emojis!
2020-08-21 Use emojis for build, lint stepsWilliam Carroll2-3/+3
Y'know... the important stuff
2020-08-21 Remove debugging informationWilliam Carroll1-6/+1
Problem: my dev machine returns a different value for `git config --get-all secrets.patterns` than my CI machine... I ran `git-secrets --register-aws` to get additional coverage, but it's still not the same. I created an issue on the git-secrets GH repo to get better troubleshooting advice, but I don't need the logging info. anymore, so I'm removing it.
2020-08-21 Debugging briefcase pipelineWilliam Carroll1-1/+6
Somehow `git-secrets --scan-history` is exiting non-zero, when I don't think it should. Logging some environment information to get a better idea of what's going on.
2020-08-21 Call --scan-historyWilliam Carroll1-1/+1
My current pipeline is succeeding with a false-positive. After this change, it should return a true-negative.
2020-08-21 Define BuildKite pipelines in NixWilliam Carroll6-18/+33
After a handful of failed attempts to run lint-secrets.sh due to a missing `git-secrets` executable on my git server, I decided that now was a good time to use Nix to define my BuildKite pipelines. TL;DR: - Delete ci/scripts directory - Define ci/pipelines/{briefcase,socrates}.nix Outside of this repository: - I logged into my admin account at git.wpcarro.dev and changed my Gitea post-receive hook to trigger the briefcase pipeline - I logged into my BuildKite account, deleted my build-briefcase pipeline, created a new briefcase pipeline that called: ```shell nix-build -A ci.pipelines.briefcase -o briefcase.yaml buildkite-agent pipeline upload briefcase.yaml ``` One day I will audit all of my ad-hoc, non-mono-repo activity (like the steps I listed above) and attempt to fit everything herein... one step at a time, though!
2020-08-20 Testing new CI lint-secrets stepWilliam Carroll1-0/+3
Adding a fake secret to test to the new CI build step. I'm not sure I expect this to fail the step because it relies on a pattern that I defined in .git/config... let's see!
2020-08-20 Call `git secret hide` whenever //secrets.json is savedWilliam Carroll1-0/+6
Having `git secret hide` as a pre-commit hook doesn't make much sense to me. I will detail why when/if I write a blog post on briefcase's secret mgt setup. The problem is, if I change secrets.json and then run `git status`, I won't see any pending changes. This is because secrets.json is gitignore'd. If I run `git secret hide` everytime I save secrets.json, I can rest assured that my `git status` will be consistent with any updates to secrets.json.
2020-08-20 Prefer reading secrets.json to using pass showWilliam Carroll5-8/+14
I'm attempting to maintain a top-level secrets.json that defines all of the sensitive data that I'd like to version-control without exposing everything in cleartext to the world. To that end, I'm using `git secret`, which will use `gpg` to encrypt secrets.json everytime I call `git secret hide` and decrypt everytime I call `git secret reveal`. I'm going to try this until I don't like it anymore... if that day comes... I should write a blog post about my setup to solicit useful feedback and share my ideas with others.
2020-08-20 Testing git-secretWilliam Carroll3-0/+2
Adding a dummy, top-level secrets.json file using `git-secret`. It might be nice to have a mono-secrets file in json because then I can use it with `jq` like: ```shell $ jq '.secret' --join-output < ~/briefcase/secrets.json ```
2020-08-20 Remove 2x-newlines from .gitignoreWilliam Carroll1-5/+0
I saw an issue on GitHub that claims that git-secret doesn't like 2x-newlines in .gitignore files. Let's see if that helps...
2020-08-20 Setup git-secretWilliam Carroll5-0/+2
This morning I'm attempting to secure my monorepo. How? - `git secret`: DONE: To version-control sensitive data - `git secrets`: TODO: Lint code for sensitive data I will probably update the CI to call `git secrets --scan` or some similar command to fail when that exists non-zero. I have much to learn, but doing is the best way to learn it.
2020-08-20 Simplify EXWM init hookWilliam Carroll1-31/+1
Anytime something before or during window-manager.el fails to evaluate, I lose the ability to type, but I *can* still click. @tazjin recommended that I use the mouse to cycle to the *Warnings* buffer, which led me to another bug in a series of bugs that I'm uncovering: ~/briefcase/org didn't exist. A simple mistake like this should break my WM startup, so I decided to remove most of my init hook logic.
2020-08-20 Add XMODIFIERS=emacsWilliam Carroll1-1/+2
This fixes the latest segfault I encountered after /usr/bin/{google-emacs,emacs} was updated...
2020-08-20 Debug evil-want-keybindings issueWilliam Carroll1-1/+1
Problem: dependency loading order I originally assumed that keybindings.el was the first module to `require 'evil` because init.el shows: ```elisp (require 'keybindings) (require 'window-manager) ``` The problem is that keybindings.el calls `require 'window-manager` and window-manager.el requires evil! I admit, I've created a bit of a birds nest for myself. A few thoughts: - keybindings.el doesn't need to `require 'window-manager`. Fixed! - window-manager.el shouldn't need to `require 'evil`. TODO...
2020-08-20 Drop use-package in keybindings.elWilliam Carroll1-79/+63
I'm attempting to kill that zombie bug about evil-want-keybinding...
2020-08-20 Add missing dependencies to emacs/default.nixWilliam Carroll1-0/+2
While debugging some broken Emacs config, I ran Emacs in X, where for some reason my PATH doesn't have my nix-env dependencies... because of this, when I call `~/.nix-profile/bin/wpcarros-emacs` to start my Emacs, I saw warnings about missing packages that I hadn't seen before. Nice!
2020-08-20 Drop support for wpc-keybindingsWilliam Carroll3-191/+121
In favor of keybindings.el! Now I have: - kbd.el: There are no keybindings in this file. It's just a library for working with keybindings in Emacs. - keybindings.el: (hopefully) all of my keybindings for EXWM, evil, etc.
2020-08-20 Remove unused kbd/install-kbds?William Carroll1-8/+0
In another refactor, I'd like to move all ad-hoc keybindings out of individual modules and into keybindings.el.
2020-08-20 Centralize <SPC> in normal mode KBDsWilliam Carroll2-45/+28
Merging keybinding and wpc-keybindings step-by-step...
2020-08-20 Delete unused KBDsWilliam Carroll1-9/+0
Now that everything is in my monorepo, it's easy for me to use <SPC>jd to search for these files.
2020-08-20 Add --no-out-link to ci/scriptsWilliam Carroll2-1/+2
I don't need the ./result symlinks...
2020-08-20 Remove <unstable> from briefcaseWilliam Carroll2-7/+2
I don't use this anywhere, so it's time to shed more weight.
2020-08-20 Move scratch/brilliant into //assessmentsWilliam Carroll10-0/+0
Where it belongs...
2020-08-20 Drop support for dir-locals.nix, <nixpkgs>, etc.William Carroll55-118/+102
In the spirit of Marie Kondo, I'm tidying up! TL;DR: - Prefer .envrc `use_nix` and delete all dir-locals.nix files - Remove ~all references to <nixpkgs>, <unstable>, <depot> and prefer referencing each with briefcase.third_party.{pkgs,unstable,depot} - Delete nixBufferFromShell function since I was only using that in dir-locals.nix files
2020-08-20 Move /home/wpcarro/nixpkgs-channels to /var/libWilliam Carroll2-2/+2
My builds are still failing. This time with... ``` error: getting status of /home/wpcarro/nixpkgs-channels: Permission denied ``` ...what confused me was the following: ```shell $ sudo -u buildkite-agent-socrates stat /home/wpcarro/nixpkgs-channels permission denied ``` But `ls -al /home/wpcarro | grep nixpkgs-channels` showed `r-w` for all users... Thankfully @riking on ##tvl told me that I should check the permissions for /home/wpcarro and /home... After running `ls -al /home`, I saw `---` for all user... I then reproduced the error by running: ```shell $ sudo -u buildkite-agent-socrates stat /home permission denied ``` Great! So then I moved nixpkgs-channels to /var/lib/buildkite-agent-socrates. @edef recommended that I read more about DynamicUser= setting for systemd, which looks relevant after I took a cursory glance. I'll also want a more declarative way to manager this, but I'm making small improvements every day.
2020-08-20 Move buildkite's SSH key out of /home/wpcarro into /etc/sshWilliam Carroll1-0/+1
After enabling buildkite-agent using NixOS, it runs as its own user, buildkite-agent-socrates, which does not have its own home directory. I moved the SSH key that I made when running buildkite-agent as wpcarro into /etc/ssh and `chown`'d it for buildkite-agent-socrates.
2020-08-20 Enable services.buildkite-agentsWilliam Carroll1-7/+7
Instead of enabling `buildkite-agent` ad hoc, use NixOS to configure it.
2020-08-20 Add CI build status badge to top-level READMEWilliam Carroll1-0/+2
Wahoo!
2020-08-20 Support build-briefcase.shWilliam Carroll3-2/+7
For now, I'm supporting two CI pipelines: - build-socrates - build-briefcase Conceptually, build-briefcase should cover what build-socrates does now, but eventually I would like build-socrates to call `switch-to-configuration` so that all of my websites, etc. stay fresh.
2020-08-20 Disable failing goals/default.nixWilliam Carroll4-7/+2
Disabling failing packages until I can get a working CI build.
2020-08-20 Revise previous opinions about absolute paths GT <bracket-notation>William Carroll11-21/+12
Unforeseen problem: `buildkite-agent` runs its builds in a separate directory, so if I want the `nix-build` command to build the newly checked out code, I need to set <briefcase> to the CWD.
generated by cgit-pink 1.4.1 (git 2.44.2) at 2024-09-22T03·28+0000