Rename the machine configuration along with its directory

Found by the deployment to vm4006: the move renames the directory and
leaves the file inside it alone, so the machine configuration ended up at
`.git/werkator/.gittally.yml` — a pair of names the lookup did not
expect, because it pairs directory and file name. The instance resolved
empty credentials, no public URL and none of the host's build
definitions, and said nothing about it. That is the exact failure this
change exists to prevent, produced by the change itself.

`StateDirMigration` now renames the configuration with the directory,
unless one under the current name is already there. `ConfigFiles` carries
`.git/werkator/.gittally.yml` as a third candidate as well, for a
directory somebody moved by hand, where the migration never runs and so
can rename nothing.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
mhoennig
2026-08-31 09:10:16 +02:00
co-authored by Claude Opus 5
parent 8499bb7a53
commit 39dac4b51b
6 changed files with 91 additions and 4 deletions
+4 -1
View File
@@ -170,7 +170,10 @@ tar xzf ~/werkator-runtime-linux-x64.tar.gz -C ~/opt
# 4. artifact root: a move on the same filesystem, instant in both directions
mv ~/.local/state/gittally ~/.local/state/werkator
# 5. let the state directory move itself, and read what it says
# 5. let the state directory move itself, and read what it says.
# Check the output: publicBaseUrl, git.account and the host's build
# definitions must be there. Empty ones mean the machine configuration
# was not found — nothing fails on its own in that case.
cd ~/hs.hsadmin.ng
~/opt/werkator/jre/bin/java -jar ~/opt/werkator/lib/werkator.jar config:print --full