Add additional endpoints for editing RFDs (#150)

* First pass on reservations

* Content update fixes. CLI output for RFD reservation

* Extend conenction timeout limit

* Add index

* More cli help messages

* Add discuss and publish endpoints

* Help text fixes

* Fmt

* License fix

* Fix test context

* Update example config files

* Add local dev login for testing

* Fmt

* Add job immediately after performing updates

* Example config and field fixes

* Start on setup doc

* Link endpoint

* Extend timeout

* Start display_name support for Google

* Fix primary field

* Use display names as opposed to caller ids in commit messages

* More Google auth fixes

* More sha typing

* Filter out providers that do not have a display name

* Update local dev feature

* Fix Google redirect test

Author: augustuswm

.github/workflows/build.yml

@@ -15,6 +15,4 @@ jobs:
       - uses: actions-rs/cargo@844f36862e911db73fe0815f00a4a2602c279505 # v1
         with:
           command: build
-          args: --release
-        env:
-          RUSTFLAGS: "--cfg tracing_unstable"
+          args: --release --all-features

Cargo.lock

@@ -95,7 +95,7 @@ determining the RFD number to update. Instead they use the numeric portion of th
 
 ### Revisions
 
-Every revision is tied to a commit* against an RFD readme file. There is no guarantee though that
+Every revision is tied to a commit* against a RFD readme file. There is no guarantee though that
 there exists a revision though for every commit. While the RFD API will attempt to create a revision
 for every commit, outages, missing webhooks, or internal errors can result in missing revisions.
 Currently the background periodic processor does not attempt to backfill missing revisions, it only
@@ -111,7 +111,7 @@ as a separate action. Currently the supported actions are:
 
 | Action                 | Purpose |
 |------------------------|------------
-| copy_images_to_storage | Copies images and static files associated with an RFD to cloud storage
+| copy_images_to_storage | Copies images and static files associated with a RFD to cloud storage
 | create_pull_request    | Create a PR for the RFD if it does not have one and the RFD is in discussion
 | ensure_default_state   | Checks that RFDs on the default branch have appropriate states
 | ensure_pr_state        | Updates the state attribute for RFDs not on the default branch as needed
@@ -123,16 +123,16 @@ as a separate action. Currently the supported actions are:
 ### Content Updates
 
 RFD processing manipulates both internally stored state as well as the source content document of
-the RFD it is processing. The two cases where the processor will update the contents of an RFD are:
+the RFD it is processing. The two cases where the processor will update the contents of a RFD are:
 
-1. An RFD has an incorrect discussion url
-2. An RFD is in an incorrect state
+1. a RFD has an incorrect discussion url
+2. a RFD is in an incorrect state
 
 The first update is the easier of the two. For any RFD that has an open discussion PR, the processor
 will check that the `discussion` attribute in the RFD document matches the url of the discussion PR.
 Note though that there is a bug here currently related to the order in which revisions may be processed.
 
-State checking is a bit more complex. For an RFD that has an open discussion PR, the processor will
+State checking is a bit more complex. For a RFD that has an open discussion PR, the processor will
 ensure that the RFD state is set to `discussion`. For RFDs that are merged to the default branch
 though, there is not a good determination as to which of the final states to assign them. Instead
 the processor will emit a warning when it encounters such a case.

README.md

@@ -0,0 +1,93 @@
+# rfd-api
+
+Backend services and tools for processing and managing RFDs
+
+## Setup
+
+To start with there are few dependencies for running the RFD API. Notably the RFD API is broken up
+in to two applications, the `rfd-api` and the `rfd-processor`. See [README.md] for more information
+on the distinctions.
+
+### Dependencies
+
+General
+ * Rust 1.77
+ * Postgres 14
+
+Processor
+ * Asciidoctor 2.0.16
+ * Node 20.11.0
+ * NPM Packages:
+ * Ruby 3.0.2
+ * Ruby Gems:
+   * asciidoctor-mermaid 0.4.1
+   * asciidoctor-pdf 2.3.10
+   * mmdc 10.6.1
+   * rouge 4.2.0
+
+Optional
+ * Meilisearch (if search is to be supported)
+
+### Build
+
+Run `cargo build --release` to build all of the project binaries. Two binaries will be generated and
+emitted at:
+
+* `target/release/rfd-api`
+* `target/release/rfd-processor`
+
+### Installation
+
+Once all of the dependencies have been installed, database migrations will need to be run to prepare
+the database tables. These can be run using the [`diesel` cli ](https://diesel.rs/guides/getting-started).
+
+To run them:
+
+```sh
+cd rfd-model
+DATABASE_URL=<database-url> diesel migration run
+```
+
+Replace `<database-url>` with the url to the Postgres instance that the API and processor will be
+configured to run against.
+
+### Configuration
+
+Each part (the api and processor) has its own configuration file, and the respective application
+directories have example files called `config.example.toml`. Where possible the define either
+default values, or disabled options.
+
+#### API
+
+The two sections in the API configuration to pay attention to are the `[[keys]]` and `[[authn]]`
+configurations.
+
+`[[keys]]` define the key pairs used to sign API keys and session tokens. Two sources are supported
+for keys, either local or GCP Cloud KMS. Placeholder configurations are provided for both sources as
+examples. During local development it is recommended to generate a new RSA key pair locally for use.
+
+`[[authn]]` is a list of authentication providers that should be enabled. Google and GitHub are the
+only authentication providers supported currently and placeholders are available in the API example
+configuration.
+
+For local development remote authentication can be bypassed by using the `local-dev` feature.
+Instead of using a remote authentication provider, the API can be run via:
+
+```sh
+cargo run -p rfd-api --features local-dev
+```
+
+This will run the API with a [`POST /login/local`](rfd-api/src/endpoints/login/local/mod.rs) endpoint
+exposed. This endpoint allows for logging in with an arbitrary email and user supplied unique
+identifier. To use this with the CLI, the `local-dev` feature will need to be passed to the CLI
+build.
+
+```sh
+cargo run -p rfd-cli --features local-dev
+```
+
+#### Processor
+
+The processor has multiple jobs that are able to be run, and configuration is only required for
+jobs that are going to be run. The `actions` key defines the jobs that should be run. By default
+all jobs are disabled. In this this mode the processor will only construct a database of RFDs.