I only dealt with the scenario where I get back an Err(_) value. This is
not what happens when the file is missing, it's what happens when there
was some other problem interacting with the file. Instead, an Ok(bool)
is returned to indicate positive identification of the presence or
absence of the file.
Something should be done about the std::io::error::Error that gets
handed back. Since I'm not expecting to see it very often, nor to really
do anything about it, I'm just emitting an error message and panicking.
There's a check in the create_release_attachment() function to ensure
the files exist before attempting to read them. Clearly, it isn't
working correctly.
I've dropped the `#[should_panic]` annotation and added a better Result
unpacking routine. It will report specific messages based on the result.
I'm not sure I want this code path to panic, actually... It should
probably return some error result so the app can print an error
diagonstic.
Oh well. That's a future problem. The end result is functionally
identical.
I was about to copy-paste the entire body of the attach_file_exists test
function into the attach_file_missing function. The only difference is
the file that they upload -- or don't, in the second case. I could make
a try-file-upload function and pass it many different files, but I don't
think I need that. Instead, I'll separate the test setup from the test
sequence itself.
I need some kind of automated testing, and Cargo has a test framework
built-in. This isn't the smartest test and depends upon another
test-less function.
Building a mocking environment is possible but means I'm trying to
emulate some behavior I don't fully understand -- that's why I need
tests in the first place. That path leads to tests for my tests and
that's stupid.
Instead, I'm having the test read config from the environment and hit a
real Gitea server. It's up to the user to ensure they have one.
I never got around to implementing the create-and-upload behavior for
the file attachment command. I'll do it later, but for now I'm disabling
the code to quiet down the compiler warnings.
Releases in a "pre-release" state are... weird. I'm not going to deal
with their oddities right now, so instead I'm dropping the command
option and hard-coding a `false` at it's usage site.
These arguments don't accept a value, they *are* the value. Presence or
absence tells the program everything it needs, so there's no point in
setting a default.
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.
Now that all API functions are the new versions using my gt_tools::Error
type natively, I don't need to map from the reqwest::Error into the
wrapped variant.
For whatever reason, releases and release attachments are separate modules in the Gitea codebase. I'm going to continue mirroring that structure for now.
I think this is the interface I want for uploading release files. There is an extra option to create the release ahead of the upload just in case it doesn't exist. One *should* create it with the create command or through the Gitea GUI so that everything can be properly written into the release info.
Owner and repo are combined into one string the same way Go dependencies or GitHub Actions are named. `<owner>/<repo>`
Each will be fetched from a matching environment variable if not specified on the command line.
