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 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.
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.
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.
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
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.
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.
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.
