Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
Instead of symlinking, just set the local git config.
|
|
|
|
This is basically building on top of bild's analysis, which is great becuase it
means that bild is becoming a useful tool rather than a monolithic do-everything
job runner. The eventual goal is for the bild analysis to be much more useful,
maybe even provide data to remote repls or language-server or whatever.
|
|
This means my call to ghc-pkg will look at the full package set from Hoogle.
|
|
|
|
|
|
|
|
Rebuilt email server, started wireguard setup.
|
|
This also makes some changes to the build tooling to clean up the environment a
bit, and get us closer to 'bild -s'.
|
|
|
|
|
|
This makes it explicit that we are using GitHub vs some other OAuth args. The
idea is that we should be making a new type for every service, this allows us to
have type safety in the implementation but a common set or pattern of names for
the environment variables and record fields.
Also using 'notset' instead of 'mempty' is really helpful for debugging when
this breaks, as I found out.
|
|
|
|
Still todo: add authentication. But that can wait.
In re-implementing this, I was able to figure out how to get the Go.mult working
properly as well. The problem is that a tap from a mult channel does not remove
the message from the original channel. I'm not sure if that should be a core
feature or not; for now I'm just draining the channel when it's received in the
Que HTTP handler. (Also, this would be a good place to put persistence: have a
background job read from the original channel, and write the msg to disk via
acid-state; this would obviate the need for a flush to nowhere.)
Also, streaming is working now. The problem was that Scotty closes the
connection after it sees a newline in the body, or something, so streaming over
Scotty doesn't actually work. It's fine, Servant is better anyway.
|
|
|
|
|
|
|
|
|
|
|
|
Getting me closer to the latest GHC. This release also includes my own packages
that I submitted some time ago.
GHCJS is not present in 21.05 for some reason, but I think it's back in master,
so I might do another upgrade soon, but for now I just disabled my GHCJS
support. I'm not really using it anyway.
I also had to bring it string-quote, update nixos-mailserver, and a few other
things.
|
|
|
|
|
|
Also I need more repos...
|
|
This way I can develop on nixpkgs directly, and directly send patches upstream,
instead of trying to copy files back and forth and work with overlays.
Of course with private stuff that I will never publish, I should use overlays,
but that will probably not be very many things, I imagine.
|
|
|
|
|
|
I also upstreamed this to nixpkgs-dev
|
|
|
|
This allows us to use nix-build as a check that bild is working.
I think bild sometimes hangs because it doesn't get input from nix-build? I'm
not sure, but one workaround is to run nix-build on the target, and then bild
will just get the cached build.
|
|
|
|
|
|
|
|
No build should take longer than 5 minutes; if it does then something is wrong
so let's just die and start over.
|
|
|
|
|
|
Eventually I'll just upstream these to nixpkgs-dev. I also want to make z into a
gemini-compatible zettlekasten. All in due time.
|
|
|
|
|
|
|
|
|
|
- structured log messages
- compact logs rewrite the line on bild completion
- using conduit for streaming output (although I think this isn't working quite
right)
- new Proc type for running subprocesses
- general code cleanup and refactoring
|
|
|
|
|
|
Part of a larger effort, but doing this iteratively in smaller chunks.
|
|
This makes scanning logs *much* easier. I figure keep it as simple as possible,
just red, yellow, and green.
I also added two spaces between labels in the log messages. It would be nice to
have a more structured logging system, but for now this works.
|
|
|
|
This argument will run the tests for an output after building. It's active in
'ci' so running that will ensure tests are passing. This way testing a
namespace and building a namespace are as close together as possible, so
presumably it will be that much easier to write good tests.
|