1. 26

  2. 5

    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!

    1. 3

      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.

      1. 2

        Even cooler, thanks for the clarification! Definitely gonna use it soon then, working on a new project (aren’t we always?)

        1. 1

          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.

        2. 1

          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.

          1. 1
            $ ./target/release/gitea-release
            gitea-release 0.2.6
            Gitea release assistant
                gitea-release <SUBCOMMAND>
                -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.

      2. 1

        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.

        1. 1

          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”?

          1. 1

            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.