Age | Commit message (Collapse) | Author | Files | Lines |
|
- Prefer dash instead of forward-slash
- Remove stale TODOs
- Add Version, Package-Requires
|
|
CI is reporting a false negative because $@ is empty. This change should cause
elisp-lint to run on all of the Elisp in the wpc/ directory.
|
|
1. I don't use this.
2. This is breaking CI because google-java-format cannot be found.
|
|
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.
|
|
I'd like to stabilize on using solarized-light.
|
|
This prevents the prompt, which blocks my CI build.
|
|
I don't use neotree anymore.
|
|
For two reasons:
1. I don't use these keybindings.
2. I'm trying to centralize all keybinding logic in keybindings.el.
|
|
Create a top-level flag encoding whether or not Emacs is running in CI.
|
|
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.
|
|
My CI failed after a call to xset resulted in a "file-missing Searching for
program" error.
|
|
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.
|
|
Cleaning things up...
|
|
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.
|
|
For more information, see here:
https://github.com/buildkite/agent/issues/584
|
|
vterm.el has a bug because it uses `(window-body-height)` to compute the number
of lines it can render, but it doesn't account for `line-spacing`.
|
|
This wasn't a bug; it's just good practice.
|
|
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.
|
|
Remap "l" -> "L"
|
|
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
|
|
wpcarros-emacs no longer depends on this being set.
|
|
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.
|
|
Trimming more fat.
|
|
Since depot now support cs.tvl.fyi, I don't need this, and that is a *massive*
upgrade.
|
|
I would prefer to define constants/briefcase in terms of `(getenv "BRIEFCASE")`
and assert that `(f-exists? (getenv "BRIEFCASE"))`, in one location:
constants.el
|
|
Feels more natural...
|
|
I'm trying to tidy things up, so I'm trying to apply some of the principles from
"Essentialism" to my Emacs configuration.
|
|
The Nix expression that builds `wpcarros-emacs` sets BRIEFCASE, so the .envrc
isn't relied on.
|
|
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
|
|
This version avoids installed all of the custom `cl-defmethods` for a
`'monorepo` type and instead uses the existing `'transient`.
|
|
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.
|
|
I think maintaining a 1:1 correspondence with the git server hook makes sense
right now. Let's try it out!
|
|
This way, if the lint step fails, the build step doesn't run. Nice!
|
|
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?
|
|
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.
|
|
I would like to find out what the state of the repo is during pre-receive hook.
|
|
Changed pipelines = new badge.
|
|
Buildkite support language extensions as emojis!
|
|
Y'know... the important stuff
|
|
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.
|
|
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.
|
|
My current pipeline is succeeding with a false-positive. After this change, it
should return a true-negative.
|
|
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!
|
|
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!
|
|
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.
|
|
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.
|
|
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
```
|
|
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...
|
|
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.
|