This is really cool! I use gitea already but am yet to explore CI/CD with drone. When I do, I’ll check this one out!
I hope it will work well for you! It works without using drone for what it’s worth. You can create tags and releases manually with this:
$ gitea-release release -o Xe -r quickserv
This will automagically read the VERSION and CHANGELOG.md files and create the release/tag. Internally the drone.io integration code calls the release function.
Even cooler, thanks for the clarification! Definitely gonna use it soon then, working on a new project (aren’t we always?)
No problem! If you run into any issues, please feel free to let me know so I can help fix them. I’m very happy to make this tool easier and more streamlined, and feedback is the best way to do it.
Thanks for this. This might make me start keeping CHANGELOGs finally. I have had issues with uploading files for gitea releases though, which has kept me from using the feature.
Gitea release assistant
-h, --help Prints help information
-V, --version Prints version information
delete Delete a given release from Gitea
download Downloads release artifacts
drone-plugin Runs the release process as a drone plugin
edit Edits a release's description, name and other flags
help Prints this message or the help of the given subcommand(s)
info Gets release info
release Create a new tag and release on Gitea
upload Uploads release artifacts to Gitea
This lets you upload gitea release artifacts too. There’s a weird filesize limit though, you may need to edit your config to compensate.
I love using Rust for parts of my infrastructure toolchain like this! For a recent work project I wrote a configuration builder that took configuration templates repos and constantly updated running servers with the current configs, and writing it in Rust was a breeze. Tools like this could be written in Python or Shell, but I like the type-level safety that Rust provides here.
It looks like the “changes” from the original “keep a changelog” format is to remove the date string from the version line? Can someone explain to me why that would be necessary?
Given that the changelog format has the version in it, why is it necessary to also have a VERSION file? Surely the top version from the changelog is the version?
Is there a reason to make this gitea specific (and thus having the same problem that the mentioned github-release tool has) rather than having it be called.. I dunno. git-release, and just use an option (or config file, if you prefer) to specify the type of “system”?
The VERSION file mostly comes from processes I use at work. It’s probably redundant, but this allows version bumping to be part of the things being reviewed.
I’m pretty sure I’m gonna generalize it though.