GothenburgBitFactory/taskchampion-sync-server
1
0
Fork 0
mirror of https://github.com/GothenburgBitFactory/taskchampion-sync-server.git synced 2025-07-31 07:53:27 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions 7
taskchampion-sync-server/RELEASING.md
Dustin J. Mitchell 309abce339
Add taskchampion-sync-server-storage-postgres 
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.
2025-07-14 12:37:50 -04:00

3.3 KiB
Raw Blame History

Release process

  1. Run git pull upstream main
  2. Run cargo test
  3. Run cargo clean && cargo clippy
  4. Remove the -pre from version in all */Cargo.toml, and from the version = .. in any references between packages.
  5. Update the link to docker-compose.yml in README.md to refer to the new version.
  6. Update the docker image in docker-compose.yml to refer to the new version.
  7. Run cargo semver-checks (https://crates.io/crates/cargo-semver-checks)
  8. Run cargo build --release
  9. Commit the changes (Cargo.lock will change too) with comment vX.Y.Z.
  10. Run git tag vX.Y.Z
  11. Run git push upstream
  12. Run git push upstream --tag vX.Y.Z
  13. Run cargo publish -p taskchampion-sync-server-core
  14. Run cargo publish -p taskchampion-sync-server-storage-sqlite (and add any other new published packages here)
  15. 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.
  16. Run cargo build --release again to update Cargo.lock
  17. Commit that change with comment "Bump to -pre version".
  18. Run git push upstream
  19. 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:

$ 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.