Commit graph

21 commits

Author SHA1 Message Date
William Carroll
fcd02d75aa Disable lint-emacs step from CI pipeline
Most of the errors at the moment are related to line-lengths exceeding my 80
character limit. While these are valid, the linter doesn't currently support
disabling these checks, which means that my Elisp code always fails this CI
step. This creates too much noise and conditions me to care less about CI
failures.

When the Elisp linter support this feature, I will gladly re-enable this step.
2021-01-22 11:22:03 +00:00
William Carroll
71e57700d6 Debug false-negative reports for init-emacs CI step
Problem: `(bufferp "*Warnings*")` always returns `nil` because it expects a
buffer object. Thankfully I wrote a function called `buffer-exists?`, which is a
more DWIM alternative of `bufferp`.

Hopefully now CI should fail!
2020-09-02 14:47:34 +01:00
William Carroll
8806604d40 Increase assertiveness of init-emacs script.el
TL;DR:
- Assert that the path to the init.el exists
- Check *Errors* buffer in case an error is uncaught but logged
- Log a message when Emacs successfully initializes
2020-09-02 14:18:50 +01:00
William Carroll
6961948da5 Allow Elisp linting to run concurrently with Emacs init
No reason for init-emacs to block lint-elisp.
2020-09-01 16:50:12 +01:00
William Carroll
fd804c7b6f Path relative path to Elisp code for elisp-lint
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.
2020-08-31 12:37:31 +01:00
William Carroll
e166e74c2c Allow configurable BRIEFCASE env var for CI
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.
2020-08-31 01:16:31 +01:00
William Carroll
8f46684c23 Attempting to avoid buildkite parse error
For more information, see here:
https://github.com/buildkite/agent/issues/584
2020-08-31 00:58:30 +01:00
William Carroll
f3047cffc1 Surround subshell in 2x-quotes
This wasn't a bug; it's just good practice.
2020-08-31 00:48:30 +01:00
William Carroll
78172233f8 Add build, lint Emacs steps to post-receive pipeline
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!
2020-08-27 18:29:48 +01:00
William Carroll
7ab86f5423 Abandon the pre-receive hook
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 23:27:44 +01:00
William Carroll
4241339963 Define Buildkite pipelines corresponding to git server hooks
I think maintaining a 1:1 correspondence with the git server hook makes sense
right now. Let's try it out!
2020-08-22 23:27:44 +01:00
William Carroll
098ca0da15 Ensure that the build step "depends on" the lint step
This way, if the lint step fails, the build step doesn't run. Nice!
2020-08-22 23:27:44 +01:00
William Carroll
3f9352b118 Remove --add-provider step from briefcase lint
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 23:27:44 +01:00
William Carroll
92fa785e75 Call --add-provider during lint stage
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 23:27:44 +01:00
William Carroll
aeeaed605e Log git information during briefcase's lint stage
I would like to find out what the state of the repo is during pre-receive hook.
2020-08-22 23:27:44 +01:00
William Carroll
fa645acf5c Prefer :nix: emoji
Buildkite support language extensions as emojis!
2020-08-21 14:00:11 +01:00
William Carroll
36399df006 Use emojis for build, lint steps
Y'know... the important stuff
2020-08-21 13:51:47 +01:00
William Carroll
fd626d907e Remove debugging information
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 12:31:03 +01:00
William Carroll
56e4d9f9b5 Debugging briefcase pipeline
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 11:25:16 +01:00
William Carroll
f53b08e4a0 Call --scan-history
My current pipeline is succeeding with a false-positive. After this change, it
should return a true-negative.
2020-08-21 11:22:52 +01:00
William Carroll
3f3cba7c32 Define BuildKite pipelines in Nix
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-21 11:12:57 +01:00