mirror of
https://github.com/GothenburgBitFactory/taskchampion-sync-server.git
synced 2026-04-05 17:20:35 +00:00
v0.7.0
This commit is contained in:
61
RELEASING.md
61
RELEASING.md
@ -4,7 +4,7 @@
|
||||
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 link to `docker-compose.yml` in `docs/src/usage/docker-compose.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`
|
||||
@ -13,65 +13,10 @@
|
||||
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. Run `cargo publish -p taskchampion-sync-server-storage-sqlite`
|
||||
1. Run `cargo publish -p taskchampion-sync-server-storage-postgres` (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.
|
||||
|
||||
Reference in New Issue
Block a user