Git-Mirrors/xmr-btc-swap
1
0
Fork 0
mirror of https://github.com/comit-network/xmr-btc-swap.git synced 2024-12-23 22:49:41 -05:00
Code Issues Packages Projects Releases Wiki Activity

Add workflow documentation

Browse Source
This commit is contained in:
Thomas Eizinger 2021-03-24 15:12:15 +11:00
parent d8e2e7beeb
commit b84a1626bd
No known key found for this signature in database
GPG Key ID: 651AC83A6C6C8B96
1 changed files with 47 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

47
.github/workflows/README.md vendored Normal file
View File

@ -0,0 +1,47 @@
# Workflow documentation
## `ci.yml`
Defines the Continuous Integration workflow for merging into the `master` branch.
## Releases
The workflows in this repository automate various things around releases.
The functionality is composed in such a way that a human can easily start the workflow at various points, i.e. instead of being an all-or-nothing automation, we can step in where necessary.
### Preview release
We have a rolling tag `preview` that always points to HEAD of `master`.
The [preview-release.yml](./preview-release.yml) workflow moves this tag to latest HEAD every time a PR gets merged.
It also creates a corresponding GitHub "pre-release".
### Building release binaries and attaching changelog
Whenever a new release is created, the [build-release-binaries.yml](build-release-binaries.yml) workflow will build the `swap` and `asb` binaries in release mode and attach them to the release as artifacts.
Because this workflow is triggered on every release, it works for:
- automatically created `preview` releases
- releases created through the GitHub web interface
- releases created by merging release branches into `master`
### Making a new release
To create a new release, one has to:
- Create a new branch
- Update the version in the [swap/Cargo.toml](../../swap/Cargo.toml) manifest file
- Update the Changelog (convert `Unreleased` section to a release)
- Make a commit
- Open and merge a PR
- Create a release from the resulting merge commit
To avoid errors in this process, we can automate it.
The [draft-new-release.yml](./draft-new-release.yml) workflow allows the user specify the desired version and the workflow will then open a PR that automates the above.
The created branch will follow the naming of `release/X.Y.Z` for the given version.
Any time a PR with such a branch name is merged, the [create-release.yml](./create-release.yml) workflow kicks in and creates a new release based on the resulting merge commit.
Because these two workflows are de-coupled, a user is free to create a release branch themselves if they wish to do so.
They may also side-step both of these workflows by creating a release manually using the Github web interface.