The empty configuration string is some kind of an error, but I'm not
sure where and how to handle it. It should be treated as a soft error,
where I fall back to some hardcoded defaults.
There's a logic hole at the moment: The error I'm actually getting right
now is "NoSuchTable" because the "[all]" table doesn't exist. For a
totally empty config file, the above response should be used. But what
about a non-empty conf file? Is a missing "[all]" valid or not? For now,
assert the loader returns *an* error and leave behind a TODO for later.
I like being able to chain methods instead of using a temporary variable
in between, so I've made one single function like I'm doing the builder
pattern.
But not really because there's nothing to build or finalize and such.
Don't repeat yourself. These property reading routines are actually
methods on the PartialConfig struct, so make them *actually* methods.
Because the table doesn't know it's own name, the path-specific config
needs to be updated with that external knowledge.
The `lconf()` function will eventually load the whole file, but for now
it reads in only the "[all]" table.
That "[all]" table will be used as the global fallback when per-project
settings are left unspecified.
The unit test "passes" but only because I've discarded those per-project
configs from the expected result. This is just so I can see clearly that
the all-table is loading properly.
The get_property function needs to say that there is no property so that
the caller can respond appropriately. I'm going to need to frequently
respond to the "no such property" path by treating it as *not* an error.
If the config file doesn't specify a property, that's not an error, it's
just not specified and the default should be used instead. This util fn
makes that a bit more ergonomic.
I don't want to remember to construct a `String` every single time I
want to call this function with a string literal. So I won't.
Make the functions generic over anything that implements the ToString
trait.
I don't know for sure if the string-ified version of a Release struct is
being printed to the terminal. As such, I don't know if the user wants,
does not want, or has mixed intentions for the stringification of this
thing.
No Display impl, instead just a `colorized()` method.
Itertools already has an intersperse method for me. Why would I build my
own when I can do this? There's even a `fold()` over the units that come
out of the print routine.
The result list has the newest item first, but I want to print them the
other way around. This way the newest (and presumably most interesting)
release is always the visible item, regardless of how many others have
printed and scrolled off screen.
I'm not certain what info I want to present when listing the Releases.
The idea is that the release version is the most important, and that it
matches the git-tag associated with the release. I'll print that first.
Next, the name of the release followed by the body text. The list of
releases will become quite large for some projects, and the body text
may include a changelog. Both of these will cause the output to become
quite large. I will need to create a size limiter, but I'm ignoring that
for now.
Who created the release and when may be useful when searching for a
release, so I've included that as the final section.
I think I got the names from the Go source code, but the API emits JSON
that has these names instead. The api/swagger guide even says as much.
This caused the super fun quirk that the upload actually succeedes, but
the program reports an error condition because of the deserialization
failure. Time to bump a minor revision!
The function `std::fs::exists(...)` was stabilized in Rust 1.81, which
means it can't be used in the Debian Bookworm build. This patch swaps to
a compatible implementation leaning on the std::path::Path struct.
I'm both "upstreaming" a Debian-specific patch I had to make for the
package, and fixing the additional usage now in `main.rs`. There doesn't
seem to be any compelling reason to avoid using this function, so I
figure I should merge it into the base release.
The Attachment struct exists, but this makes it glaringly obvious that
I've made a bad interface. The create_release_attachment should only
accept one file at a time and the loop over all files should happen in
main.rs
I've changed the signature, removed the loops, and wired in the newer
error handling routines. Needs fixing at call sites.
I can't meaningfully unit test these things like this. I'll explore creating a tarball of a known Gitea configuration and using Docker to test against that. For now, just... kinda keep the test building.
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.
