|
4 | 4 | 1. Run `cargo test` |
5 | 5 | 1. Run `cargo clean && cargo clippy` |
6 | 6 | 1. Remove the `-pre` from `version` in all `*/Cargo.toml`, and from the `version = ..` in any references between packages. |
7 | | -1. Update the link to `docker-compose.yml` in `README.md` to refer to the new version. |
| 7 | +1. Update the link to `docker-compose.yml` in `docs/src/usage/docker-compose.md` to refer to the new version. |
8 | 8 | 1. Update the docker image in `docker-compose.yml` to refer to the new version. |
9 | 9 | 1. Run `cargo semver-checks` (https://crates.io/crates/cargo-semver-checks) |
10 | 10 | 1. Run `cargo build --release` |
|
19 | 19 | 1. Commit that change with comment "Bump to -pre version". |
20 | 20 | 1. Run `git push upstream` |
21 | 21 | 1. Navigate to the tag in the GitHub releases UI and create a release with general comments about the changes in the release |
22 | | - |
23 | | ---- |
24 | | - |
25 | | -For the next release, |
26 | | - |
27 | | -- remove postgres from the exclusion list in `.github/workflows/checks.yml` after the release |
28 | | - |
29 | | -- include the folowing in the release notes: |
30 | | - |
31 | | -Running the Docker image for this server without specifying DATA_DIR |
32 | | -defaulted to storing the server data in |
33 | | -`/var/lib/taskchampion-sync-server`. However, the Dockerfile only |
34 | | -specifies that the subdirectory `/var/lib/taskchampion-sync-server/data` |
35 | | -is a VOLUME. This change fixes the default to match the VOLUME, putting |
36 | | -the server data on an ephemeral volume or, if a `--volume |
37 | | -$NAME:/var/lib/taskchampion-sync-server/data` argument is provided to |
38 | | -`docker run`, in a named volume. |
39 | | - |
40 | | -Before this commit, with default settings the server data is stored in |
41 | | -the container's ephemeral writeable layer. When the container is killed, |
42 | | -the data is lost. This issue does not affect deployments with `docker |
43 | | -compose`, as the compose configuration specifies a correct `DATA_DIR`. |
44 | | - |
45 | | -You can determine if your deployment is affected as follows. First, |
46 | | -determine the ID of the running server container, `$CONTAINER`. Examine |
47 | | -the volumes for that container: |
48 | | - |
49 | | -```shell |
50 | | -$ docker container inspect $CONTAINER | jq '.[0].Config.Volumes' |
51 | | -{ |
52 | | - "/var/lib/task-champion-sync-server/data": {} |
53 | | -} |
54 | | -``` |
55 | | - |
56 | | -Next, find the server data, in a `.sqlite3` file: |
57 | | - |
58 | | -```shell |
59 | | -$ docker exec $CONTAINER find /var/lib/taskchampion-sync-server |
60 | | -/var/lib/taskchampion-sync-server |
61 | | -/var/lib/taskchampion-sync-server/data |
62 | | -/var/lib/taskchampion-sync-server/taskchampion-sync-server.sqlite3 |
63 | | -``` |
64 | | - |
65 | | -If the data is not in a directory mounted as a volume, then it is |
66 | | -ephemeral. To copy the data out of the container: |
67 | | - |
68 | | -```shell |
69 | | -docker cp $CONTAINER:/var/lib/taskchampion-sync-server/taskchampion-sync-server.sqlite3 /tmp |
70 | | -``` |
71 | | - |
72 | | -You may then upgrade the image and use `docker cp` to copy the data back |
73 | | -to the correct location, `/var/lib/taskchampion-sync-server/data`. |
74 | | - |
75 | | -Note that, as long as all replicas are fully synced, the TaskChampion |
76 | | -sync protocol is resilient to loss of server data, so even if the server |
77 | | -data has been lost, `task sync` may continue to work. |
0 commit comments