finserv, branch mainPersonal finances serverhttps://cgit.xengineering.eu/finserv/atom2026-06-05T19:01:52ZAdd global db variable and open connection to it2026-06-05T19:01:52Zxengineeringme@xengineering.eu2026-06-05T18:59:27Zurn:sha1:3395bc1cd32698897385596022e0c855765b48f2
This allows any handler to access the database via a global variable.
The connection is closed when the run function finishes.
Add TestTransaction2026-06-02T18:27:05Zxengineeringme@xengineering.eu2026-06-02T18:27:05Zurn:sha1:3ad3565c64ed1ce692c0509d8fe5a7530f8fb7e3
This makes sure the assumption is correct that everything inside a
transaction is rolled back if the transaction fails.
Add TestUserVersion2026-06-02T18:20:17Zxengineeringme@xengineering.eu2026-06-02T18:20:17Zurn:sha1:a3009e165c4cdbf94eb23a071d5e6c39425539e8
This is partially redundant to MigrateToLatest. Nevertheless a layered
testing approach is useful to detect low-level problems in test
functions which are simple.
Name tests like functions to test2026-06-02T18:12:53Zxengineeringme@xengineering.eu2026-06-02T18:12:53Zurn:sha1:975349b50e3d2c76564fef686a2a33b01212b6d3
This enforces a similar structure of test functions named `TestFooBar`
if they test the function `FooBar`.
Add MigrateToLatest2026-06-02T17:52:18Zxengineeringme@xengineering.eu2026-06-02T17:52:18Zurn:sha1:a750aa4ecf7ecab519b53d7f3ac082425ba50686
This function will be used most by the production software to update
the database schema to the latest known version.
Remove success logging in tests2026-06-02T17:40:55Zxengineeringme@xengineering.eu2026-06-02T17:40:55Zurn:sha1:bd1ead99fd53ad8c3c016b59d67f5bf58ade5095
In case the test succeeds it is not required to log anything. This only
adds noise to the output.
Add UserVersion()2026-05-31T19:37:16Zxengineeringme@xengineering.eu2026-05-31T19:34:44Zurn:sha1:29ae857b5ca13fa12f1d07d4a30597ff9ce28767
This function gets the user_version SQLite3 field describing which
migration was the last executed one.
A test checking this before applying any migrations and after each
migration is included.
Add migration execution2026-05-31T19:37:13Zxengineeringme@xengineering.eu2026-05-31T19:20:48Zurn:sha1:efb324070827bd1fe713b93f80c601551d246579
This adds the execution of the embedded migrations and adds a suitable
unit test.
Add migration reading2026-05-31T18:48:51Zxengineeringme@xengineering.eu2026-05-31T16:13:15Zurn:sha1:4cb6a5952f341741ef2728fb39acb7f19de61ba9
This prepares the infrastructure to place migration SQL code in the
source repository with paths formatted as `sql/migrations/%04d.sqlite3`.
The numbers need to be counting up from 1.
They are embedded with Go's embed package and are parsed into a slice of
strings where the migration number minus one is the slice index and the
value is the migrations file as string.
This makes handling of migrations in code as easy as possible.
This commit adds also tests for this functionality.
Add github.com/mattn/go-sqlite32026-05-31T15:30:01Zxengineeringme@xengineering.eu2026-05-28T18:32:36Zurn:sha1:6cdf8bb597443be880cd5a9cb6f3ac953749811a
This is the SQLite3 backend for the database/sql standard library
package which should be used to store persistent data.
frontend: simple.css: Use copy of upstream code2026-05-29T14:25:02Zxengineeringme@xengineering.eu2026-05-28T19:05:00Zurn:sha1:fba9bcfc9a422dd3020b5efc2392ddfd71231560
This switches from the use of a Git submodule to a locally committed
copy of the needed file and it's license.
The reason is that `hugo server` needs the CSS file in the same relative
path as `hugo build` which is run in the build tree.
But this is not possible because Meson cannot copy it to the
`build/frontend/simple.css` folder without a `meson.build` in
`source/frontend/simple.css`.
This together with the limitation that symbolic links are not supported
by Hugo makes life pretty difficult. Thus a local copy of simple.css and
an adjacent `meson.build` file is chosen.
VERSION.txt: Add `-dev` suffix2026-05-28T19:08:07Zxengineeringme@xengineering.eu2026-05-28T19:08:07Zurn:sha1:d2e35b764adbc152190f1815d5ba29dd542fc387
This makes clear this is not a release.
Release version 0.1.02026-05-24T09:48:38Zxengineeringme@xengineering.eu2026-05-24T09:48:38Zurn:sha1:d7d46df8c4d019be48f7aa0790aa8a2349e45e20
This release allows to get started with packaging and deployment in a
very early stage.
All features can be added incrementally.
VERSION.txt: Remove `v` prefix2026-05-24T09:46:01Zxengineeringme@xengineering.eu2026-05-24T09:46:01Zurn:sha1:75cf3388c095b7187dd885500e17e0880b270a79
The content of this file should contain the version string of the
software. There is no need to label it with a prefix `v` since this is
redundant.
Add missing `.` to log messages2026-05-24T09:44:01Zxengineeringme@xengineering.eu2026-05-24T09:43:28Zurn:sha1:2b37d7902daa6e2a9c2284fd3dccb19429ecbd11README.md: Add public API declaration2026-05-24T09:41:14Zxengineeringme@xengineering.eu2026-05-24T09:41:14Zurn:sha1:fc6315be199305d21e4fb1b1a18917bec4147f3e
This is required to properly use Semantic Versioning.
Disable log timestamps2026-05-24T09:31:00Zxengineeringme@xengineering.eu2026-05-24T09:31:00Zurn:sha1:1d0f96aaacd7d8853a1aa970b01560c92c4da86b
Many logging systems provide timestamps on their own. To avoid
duplication it is disabled by default.
README.md: Add build instructions2026-05-24T09:29:38Zxengineeringme@xengineering.eu2026-05-24T09:29:38Zurn:sha1:5a0e9472d28961b2a8d598165e05f4221171c1a1systemd: Add finserv.service2026-05-24T08:45:19Zxengineeringme@xengineering.eu2026-05-24T08:45:19Zurn:sha1:57b275d398b14aed86a047a829427c557018b5f8
This file can be used to package for systemd-based Linux distribution.
It creates the finserv system service running the server. That way
automatic startup on system start can be implemented.
systemd: Add finserv.tmpfile.d2026-05-24T08:43:47Zxengineeringme@xengineering.eu2026-05-24T08:43:47Zurn:sha1:bde29ccfbbd33376161bd192637c6c7ac70f5490
This file can be used to package for systemd-based Linux distribution.
I configures the data directory of finserv. This notably includes
setting the proper access permissions to protect the saved data.
systemd: Add sysuser.conf2026-05-24T08:42:50Zxengineeringme@xengineering.eu2026-05-24T08:42:50Zurn:sha1:03c582c3b17b7320bf9317b4a27c572f68cc0fd7
This file can be used to package for systemd-based Linux distribution.
It creates the `finserv` system user which runs the server.
frontend: Add work in progress text to index2026-05-23T22:13:24Zxengineeringme@xengineering.eu2026-05-23T22:13:24Zurn:sha1:d8562450d1c50fdadfb97436b69e74908f97b11d
This explains the users the current state of this project.
frontend: static: Add simple.css symlink2026-05-23T22:10:50Zxengineeringme@xengineering.eu2026-05-23T22:08:27Zurn:sha1:0425f4b8e6e27923e7a43b24a05117eb62ac6786
This allows to develop the frontend with `hugo server` and its built-in
page refresh on file change.
For the actual build the file is copied to the build directory by Meson.
Use simple.css2026-05-23T22:05:40Zxengineeringme@xengineering.eu2026-05-23T22:05:40Zurn:sha1:15be9a62f557d54448cbb932c4d7c4a96843daf2
This enables the use of simple.css as CSS framework.
Add `run` target2026-05-23T21:57:04Zxengineeringme@xengineering.eu2026-05-23T21:56:18Zurn:sha1:cfa648d2b69bdb26bdbb0a9096780d7721c99da3
This allows to easily run the server with a single `meson compile -C
build run` during development.
frontend: Add simple.css submodule2026-05-23T21:55:30Zxengineeringme@xengineering.eu2026-05-23T21:55:30Zurn:sha1:fe8c7a33aeb2124ffb00a6c6be61369e5e344bc3
This is the CSS framework which should be used for this repository.
Add global Meson build system2026-05-23T21:48:15Zxengineeringme@xengineering.eu2026-05-23T21:48:15Zurn:sha1:4db5f4ae91cc5b9139e3f2e1208e2ec032a89ebf
This commit fully introduces Meson as a build system for this
repository. It makes sure the frontend page is built with Hugo before
the Go executable is built and embeds the frontend.
frontend: Add Meson build system2026-05-23T21:42:27Zxengineeringme@xengineering.eu2026-05-23T21:39:01Zurn:sha1:0c2903126aa2df80d1ea40295df6365ea37b7651
This is a first step towards using Meson for the whole repository.
Having one central build system allows many things like ensuring that
the frontend page is build before embedding it into the Go executable
or like transpiling TypeScript to JavaScript before building the
frontend page.
Embed frontend to server executable2026-05-23T20:54:30Zxengineeringme@xengineering.eu2026-05-23T20:54:30Zurn:sha1:a72c0c275a962153a40bc805e5ce3ac7a273f55c
This makes use of the `embed` package of the Go standard library to
embed the full Hugo static website as a global filesystem variable
inside the executable.
This effectively makes all files of the static website part of the Go
executable. That way it is always possible to just copy the server
executable to a host, make it executable and run it without any other
dependencies.
Hook up frontend in Go web server2026-05-23T20:38:40Zxengineeringme@xengineering.eu2026-05-23T20:37:31Zurn:sha1:7bb61037ffa36549661b8a34e305343d40007ca2
This makes the Hugo-built static website part of site hosted by Go which
also contains the dynamic API under /api.