It all falls into place! I had been dreading doing this bit, but after
updating the usage guide I realized the CLI args should be split, too.
Which finally means that I can just glue on the PWD name as a final
fallback for the repo name.
Try the args, then the config file(s), then PWD. If nothing works, the
user is in a world of hurt. Bail out.
Load the configuration for the current directory. The project guessing
mechanism isn't here, yet, so this will have to do.
First take the properties set via Args. This will also capture the
values set through environment variables. For anything that's missing,
try to fill it with the info from the configuration files. In the event
that there isn't enough information, new error types have been added to
signal mis-use.
I've been putting this off because I don't want to have many small
formatting commits, and I don't have any kind of pre-commit hook to do
it for me. So here it is :v
This thing only needs to exist so Serde can decode the response JSON
properly. I'll either get a success, a missing token, *no body at all
which doesnt' make sense*, or some other ApiError text. In all cases,
the crate::Result is returned. This thing doesn't need to be public.
Obviously the Gitea API can return errors, which are also JSON strings.
Theres a new error response struct to collect these, and an enum for
Serde to unpack which ever variant happens to come back.
The API token is read from the environment variable `RELEASE_KEY_GITEA`.
"GITEA" is on the end because Gitea itself will refuse to allow users to
configure Act variables starting with the name "GITEA_".
All information about the release is hard-coded right now. I just needed
to see it hit the API and appear on the Gitea page. Hooking up the extra
options is up next.
