blog: gitea-release post (#160)
This commit is contained in:
GitHub
parent
a5d22e3ec8
commit
fff4a234a4
|
|
@ -0,0 +1,202 @@
|
||||||
|
---
|
||||||
|
title: "gitea-release Tool Announcement"
|
||||||
|
date: "2020-05-31"
|
||||||
|
tags:
|
||||||
|
- gitea
|
||||||
|
- rust
|
||||||
|
- release
|
||||||
|
---
|
||||||
|
|
||||||
|
# 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`](https://tulpa.dev/cadey/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](https://tulpa.dev).
|
||||||
|
|
||||||
|
`gitea-release` is a spiritual clone of the tool [`github-release`][ghrelease],
|
||||||
|
but optimized for my workflow. The biggest changes are that it works on
|
||||||
|
[gitea][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`.
|
||||||
|
|
||||||
|
[ghrelease]: https://github.com/github-release/github-release
|
||||||
|
[gitea]: https://gitea.io
|
||||||
|
|
||||||
|
## CHANGELOG.md and VERSION files
|
||||||
|
|
||||||
|
The `CHANGELOG.md` file is based on the [Keep a Changelog][kacl] format, but
|
||||||
|
modified slightly to make it easier for this tool. Here is an example changelog
|
||||||
|
that this tool accepts:
|
||||||
|
|
||||||
|
[kacl]: https://keepachangelog.com/en/1.0.0/
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
# 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][semver] string. This allows the `VERSION`
|
||||||
|
file to be the ultimate source of truth for software version data with this
|
||||||
|
tool.
|
||||||
|
|
||||||
|
[semver]: https://semver.org/spec/v2.0.0.html
|
||||||
|
|
||||||
|
## 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][drone] as a CI/CD tool for my gitea
|
||||||
|
repos. Drone has a very convenient and simple to use [plugin
|
||||||
|
system][droneplugin] that was easy to integrate with [structopt][structopt].
|
||||||
|
|
||||||
|
[drone]: https://drone.io
|
||||||
|
[droneplugin]: https://docs.drone.io/plugins/overview/
|
||||||
|
[structopt]: https://crates.io/crates/structopt
|
||||||
|
|
||||||
|
I created a drone plugin at `xena/gitea-release` that can be configured as a
|
||||||
|
pipeline step in your `.drone.yml` like this:
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
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](https://drone.tulpa.dev/cadey/gitea-release). You can also how the
|
||||||
|
`CHANGELOG.md` file grows with the [CHANGELOG of
|
||||||
|
gitea-release](https://tulpa.dev/cadey/gitea-release/src/branch/master/CHANGELOG.md).
|
||||||
|
|
||||||
|
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:
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
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](https://nixos.org/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](/contact). If you want to contribute directly to the project, please
|
||||||
|
feel free to create [issues](https://tulpa.dev/cadey/gitea-release/issues) or
|
||||||
|
[pull requests](https://tulpa.dev/cadey/gitea-release/pulls). 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.
|
||||||
Loading…
Reference in New Issue