General changes

[steveklabnik]

Hey @jclulow ! Here I have two small commits and two bigger commits. I will preface this PR by saying I understand if you do not want to take these, which is why I am sending them separate from other work.

In short:

• Move some tests out to a file to make it easier for Cargo to not spuriously rebuild
• Turn off unused documentation tests to speed up cargo test
• Reorganize crates under a top-level crates directory
• Rename directories to match the name of various crates

The last two, especially, are pains. But I think the pain is worth it. It has been very tough for me to keep track of names when the directories aren't the same, and to even know where things live, given the hierarchy.

The one concern I have here is that there are a bunch of shell scripts (even though you already have xtask! 😉) which may have paths I didn't discover. Additionally, I am unsure what some of these do; I fixed the script in github-tools to download a new schema properly in github-schema, but I cannot find in the code where this is used? So uh, thoughts and advice about that would be helpful, if you do agree that this move is a good idea.

[jclulow]

Hey. Please pardon my atrocious latency on this one. I've taken a look through it, and:

• I have pulled in the commit that disables documentation tests as 07947409957763b132ef78ae8c50ac4ea2ff8f52 as that was easily all upside.

• I have removed the apparently vestigial GitHub webhook schema stuff (98b928e854977676e5fd54cee8c555a8c4a361d8)! I'm not sure what I had planned to do with it, but I think it was related to an attempt to generate some of the types that are currently hand-coded in github/common/src/hooktypes.rs, but that turned out to be more tedious than I expected.

• I would really rather not move to the flat crate directory layout. I've read through the article you mention, but I think a lot of it is fairly subjective. I know there is not technically a hierarchy of crates in the Rust model, but there is an attempt at hierarchy in the design of the software here. I also use the shell a lot to navigate around, and I find shorter paths are vastly more ergonomic; e.g., I'd rather not have the buildomat- prefix on basically every directory, and I'd rather not have the extra layer of /crates/ to get through.

  I agree that it's unhelpful that there are some parts of the directory hierarchy that don't quite match the crate names, though, so I'm going to do a more minor reshuffling:

  buildomat              /client           rename dir -> /bin
  buildomat-agent        /agent
  buildomat-bunyan       /bunyan
  buildomat-client       /openapi          rename dir -> /client
  buildomat-common       /common
  buildomat-database     /database
  buildomat-server       /server
  buildomat-types        /types
  
  buildomat-factory-aws  /factory/aws
  buildomat-factory-lab  /factory/lab
  
  wollongong-common      /github/common    \
  wollongong-database    /github/database  |
  wollongong-dbtool      /github/dbtool    |--- rename crates:
  wollongong-ghtool      /github/ghtool    | s/wollongong/buildomat-github/
  wollongong-server      /github/server    /
  
  xtask                  /xtask

  I am hopeful this will help with the worst parts of the confusion, with the obvious exception of the CLI program buildomat: this is in a crate with that name because I figured one day it might be more broadly useful and it would be worth publishing it so one could install it with cargo install buildomat.

• I have noticed also that the developer-centric parts of the documentation are pretty out of date. I'll take a pass this week and get that sorted out as well.