gitea-release Tool Announcement

I’m a big fan of automating things that can possibly be automated. One of the biggest pains that I’ve consistently had is creating/tagging releases of software. This has been a very manual process for me. I have to write up changelogs, bump versions and then replicate the changelog/versions in the web UI of whatever git forge the project in question is using. This works great at smaller scales, but can quickly become a huge pain in the butt when this needs to be done more often. Today I’ve written a small tool to help me automate this going forward, it is named gitea-release. This is one of my largest Rust projects to date and something I am incredibly happy with. I will be using it going forward for all of my repos on my gitea instance tulpa.dev.

gitea-release is a spiritual clone of the tool github-release, but optimized for my workflow. The biggest changes are that it works on gitea repos instead of github repos, is written in Rust instead of Go and it automatically scrapes release notes from CHANGELOG.md as well as reading the version of the software from VERSION.

CHANGELOG.md and VERSION files

The CHANGELOG.md file is based on the Keep a Changelog format, but modified slightly to make it easier for this tool. Here is an example changelog that this tool accepts:

# Changelog
All notable changes to this project will be documented in this file.

The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).

## 0.1.0

### FIXED

- Refrobnicate the spurious rilkefs

## 0.0.1

First release, proof of concept.

When a release is created for version 0.1.0, this tool will make the description of the release about as follows:

### FIXED

- Refrobnicate the spurious rilkefs

This allows the changelog file to be the ultimate source of truth for release notes with this tool.

The VERSION file plays into this as well. The VERSION file MUST be a single line containing a semantic version string. This allows the VERSION file to be the ultimate source of truth for software version data with this tool.

Release Process

When this tool is run with the release subcommand, the following actions take place:

The VERSION file is read and loaded as the desired tag for the repo
The CHANGELOG.md file is read and the changes for the VERSION are cherry-picked out of the file
The git repo is checked to see if that tag already exists
- If the tag exists, the tool exits and does nothing
If the tag does not exist, it is created (with the changelog fragment as the body of the tag) and pushed to the gitea server using the supplied gitea token
A gitea release is created using the changelog fragment and the release name is generated from the VERSION string

Automation of the Automation

This tool works perfectly well locally, but this doesn’t make it fully automated from the gitea repo. I use drone as a CI/CD tool for my gitea repos. Drone has a very convenient and simple to use plugin system that was easy to integrate with structopt.

I created a drone plugin at xena/gitea-release that can be configured as a pipeline step in your .drone.yml like this:

kind: pipeline
name: ci/release
steps:
  - name: whatever unit testing step
    # ...
  - name: auto-release
    image: xena/gitea-release:0.2.5
    settings:
      auth_username: cadey
      changelog_path: ./CHANGELOG.md
      gitea_server: https://tulpa.dev
      gitea_token:
        from_secret: GITEA_TOKEN
    when:
      event:
        - push
      branch:
        - master

This allows me to bump the VERSION and CHANGELOG.md, then push that commit to git and a new release will automatically be created. You can see an example of this in action with the drone build history of the gitea-release repo. You can also how the CHANGELOG.md file grows with the CHANGELOG of gitea-release.

Once the release is pushed to gitea, you can then use drone to trigger deployment commands. For example here is the deployment pipeline used to automatically update the docker image for the gitea-release tool:

kind: pipeline
name: docker
steps:
  - name: build docker image
    image: "monacoremo/nix:2020-04-05-05f09348-circleci"
    environment:
      USER: root
    commands:
      - cachix use xe
      - nix-build docker.nix
      - cp $(readlink result) /result/docker.tgz
    volumes:
      - name: image
        path: /result
    when:
      event:
        - tag

  - name: push docker image
    image: docker:dind
    volumes:
      - name: image
        path: /result
      - name: dockersock
        path: /var/run/docker.sock
    commands:
      - docker load -i /result/docker.tgz
      - echo $DOCKER_PASSWORD | docker login -u $DOCKER_USERNAME --password-stdin
      - docker push xena/gitea-release
    environment:
      DOCKER_USERNAME:
        from_secret: DOCKER_USERNAME
      DOCKER_PASSWORD:
        from_secret: DOCKER_PASSWORD
    when:
      event:
        - tag

volumes:
  - name: image
    temp: {}
  - name: dockersock
    host:
      path: /var/run/docker.sock

This pipeline will use Nix to build the docker image, load it into a Docker daemon and then log into the Docker Hub and push it. This can then be used to do whatever you want. It may also be a good idea to push a docker image for every commit and then re-label the tagged commits, but this wasn’t implemented in this repo.

I hope this tool will be useful. I will accept feedback over any contact method. If you want to contribute directly to the project, please feel free to create issues or pull requests. If you don’t want to create an account on my git server, get me the issue details or code diffs somehow and I will do everything I can to fix issues and integrate code. I just want to make this tool better however I can.

Be well.

This article was posted on 2020 M5 31. Facts and circumstances may have changed since publication. Please contact me before jumping to conclusions if something seems wrong or unclear.

Tags: #gitea #rust #release