mirror of
https://github.com/GothenburgBitFactory/taskchampion-sync-server.git
synced 2025-08-01 02:13:27 +02:00

This is built to be more robust than the SQLite storage, and to integrate with other applications. The idea is that for example a web application might interact with the same DB to create and delete clients as customers come and go.
77 lines
3.3 KiB
Markdown
77 lines
3.3 KiB
Markdown
# Release process
|
|
|
|
1. Run `git pull upstream main`
|
|
1. Run `cargo test`
|
|
1. Run `cargo clean && cargo clippy`
|
|
1. Remove the `-pre` from `version` in all `*/Cargo.toml`, and from the `version = ..` in any references between packages.
|
|
1. Update the link to `docker-compose.yml` in `README.md` to refer to the new version.
|
|
1. Update the docker image in `docker-compose.yml` to refer to the new version.
|
|
1. Run `cargo semver-checks` (https://crates.io/crates/cargo-semver-checks)
|
|
1. Run `cargo build --release`
|
|
1. Commit the changes (Cargo.lock will change too) with comment `vX.Y.Z`.
|
|
1. Run `git tag vX.Y.Z`
|
|
1. Run `git push upstream`
|
|
1. Run `git push upstream --tag vX.Y.Z`
|
|
1. Run `cargo publish -p taskchampion-sync-server-core`
|
|
1. Run `cargo publish -p taskchampion-sync-server-storage-sqlite` (and add any other new published packages here)
|
|
1. Bump the patch version in `*/Cargo.toml` and add the `-pre` suffix. This allows `cargo-semver-checks` to check for changes not accounted for in the version delta.
|
|
1. Run `cargo build --release` again to update `Cargo.lock`
|
|
1. Commit that change with comment "Bump to -pre version".
|
|
1. Run `git push upstream`
|
|
1. Navigate to the tag in the GitHub releases UI and create a release with general comments about the changes in the release
|
|
|
|
---
|
|
|
|
For the next release,
|
|
|
|
- remove postgres from the exclusion list in `.github/workflows/checks.yml` after the release
|
|
|
|
- include the folowing in the release notes:
|
|
|
|
Running the Docker image for this server without specifying DATA_DIR
|
|
defaulted to storing the server data in
|
|
`/var/lib/taskchampion-sync-server`. However, the Dockerfile only
|
|
specifies that the subdirectory `/var/lib/taskchampion-sync-server/data`
|
|
is a VOLUME. This change fixes the default to match the VOLUME, putting
|
|
the server data on an ephemeral volume or, if a `--volume
|
|
$NAME:/var/lib/taskchampion-sync-server/data` argument is provided to
|
|
`docker run`, in a named volume.
|
|
|
|
Before this commit, with default settings the server data is stored in
|
|
the container's ephemeral writeable layer. When the container is killed,
|
|
the data is lost. This issue does not affect deployments with `docker
|
|
compose`, as the compose configuration specifies a correct `DATA_DIR`.
|
|
|
|
You can determine if your deployment is affected as follows. First,
|
|
determine the ID of the running server container, `$CONTAINER`. Examine
|
|
the volumes for that container:
|
|
|
|
```shell
|
|
$ docker container inspect $CONTAINER | jq '.[0].Config.Volumes'
|
|
{
|
|
"/var/lib/task-champion-sync-server/data": {}
|
|
}
|
|
```
|
|
|
|
Next, find the server data, in a `.sqlite3` file:
|
|
|
|
```shell
|
|
$ docker exec $CONTAINER find /var/lib/taskchampion-sync-server
|
|
/var/lib/taskchampion-sync-server
|
|
/var/lib/taskchampion-sync-server/data
|
|
/var/lib/taskchampion-sync-server/taskchampion-sync-server.sqlite3
|
|
```
|
|
|
|
If the data is not in a directory mounted as a volume, then it is
|
|
ephemeral. To copy the data out of the container:
|
|
|
|
```shell
|
|
docker cp $CONTAINER:/var/lib/taskchampion-sync-server/taskchampion-sync-server.sqlite3 /tmp
|
|
```
|
|
|
|
You may then upgrade the image and use `docker cp` to copy the data back
|
|
to the correct location, `/var/lib/taskchampion-sync-server/data`.
|
|
|
|
Note that, as long as all replicas are fully synced, the TaskChampion
|
|
sync protocol is resilient to loss of server data, so even if the server
|
|
data has been lost, `task sync` may continue to work.
|