3.2 KiB
Release process
- Run
git pull upstream main - Run
cargo test - Run
cargo clean && cargo clippy - Remove the
-prefromversionin all*/Cargo.toml, and from theversion = ..in any references between packages. - Update the link to
docker-compose.ymlinREADME.mdto refer to the new version. - Update the docker image in
docker-compose.ymlto refer to the new version. - Run
cargo semver-checks(https://crates.io/crates/cargo-semver-checks) - Run
cargo build --release - Commit the changes (Cargo.lock will change too) with comment
vX.Y.Z. - Run
git tag vX.Y.Z - Run
git push upstream - Run
git push upstream --tag vX.Y.Z - Run
cargo publish -p taskchampion-sync-server-core - Run
cargo publish -p taskchampion-sync-server-storage-sqlite(and add any other new published packages here) - Bump the patch version in
*/Cargo.tomland add the-presuffix. This allowscargo-semver-checksto check for changes not accounted for in the version delta. - Run
cargo build --releaseagain to updateCargo.lock - Commit that change with comment "Bump to -pre version".
- Run
git push upstream - 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, 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:
$ docker container inspect $CONTAINER | jq '.[0].Config.Volumes'
{
"/var/lib/task-champion-sync-server/data": {}
}
Next, find the server data, in a .sqlite3 file:
$ 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:
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.