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.
