| Age | Commit message (Collapse) | Author |
|
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.
|
|
This adds the execution of the embedded migrations and adds a suitable
unit test.
|
|
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.
|
|
This is the SQLite3 backend for the database/sql standard library
package which should be used to store persistent data.
|
|
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.
|
|
This makes clear this is not a release.
|
|
This release allows to get started with packaging and deployment in a
very early stage.
All features can be added incrementally.
|
|
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.
|
|
|
|
This is required to properly use Semantic Versioning.
|
|
Many logging systems provide timestamps on their own. To avoid
duplication it is disabled by default.
|
|
|
|
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.
|
|
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.
|
|
This file can be used to package for systemd-based Linux distribution.
It creates the `finserv` system user which runs the server.
|
|
This explains the users the current state of this project.
|
|
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.
|
|
This enables the use of simple.css as CSS framework.
|
|
This allows to easily run the server with a single `meson compile -C
build run` during development.
|
|
This is the CSS framework which should be used for this repository.
|
|
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.
|
|
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.
|
|
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.
|
|
This makes the Hugo-built static website part of site hosted by Go which
also contains the dynamic API under /api.
|
|
These two files are the starting point for the front end.
|
|
Hugo produces files which should not be committed.
|
|
Hugo by default generates output files which are not yet needed.
|
|
This is the starting point of a Hugo[1] based web frontend.
[1]: https://gohugo.io/
|
|
The old /version endpoint was moved. It should be part of the API and it
is intended that everything not part of /api/* is a static web site
which is also served by the Go server.
|
|
This was just for demonstration purposes.
|
|
One line per argument makes the code more readable and also diffs in
case arguments are changed.
|
|
|
|
This makes the run() function compared to main() useful at all since all
parameters can be changed to test e.g. with unit tests.
|
|
This keeps the HTTP handlers in a separate file which registers the
routes in an init() function.
The main execution flow is still maintained in a now minimal main.go.
|
|
This improves readability.
|
|
This makes the used *mux.Router from github.com/gorilla/mux a global
variable.
A new router is created in the line where the global variable is
created. Handlers can be added across the code base in init() functions.
|
|
|
|
|
|
|
|
This demonstrates the HTTP server is working.
|
|
This should be used for the HTTP routing.
|
|
|
|
This function should be called by main but can also be called by a unit
test to run a server which might have different arguments which will
likely be added.
|
|
This is a starting point to build the server.
|
|
This makes the repository a Go module which is required to fetch
dependencies.
|
|
This explains the purpose of the project.
|
|
|