| Commit message (Collapse) | Author | Files | Lines |
|---|
|
Store the name of the subsystem in a constant, add some comments on
where to find the list.
|
|
|
|
Add a Makefile to install the binary in GOPATH and the unit file for the
service. When the binary is installed, systemd is reloaded and the
service is also started.
|
|
As I want the scrobbler to be started automatically when I log into my
session, the easiest way to do this is by having a systemd unit file
that I run for my own user.
The unit expects that the binary for the scrobbler is under my $GOPATH,
which is hard coded for now. We also ensure that the binary exists
before starting the unit.
We harness the service with a number of directives.
|
|
If the status of the player is "stop", we don't have a new song to
handle. In this case, if there's a current song, let's update the status
and clear our state.
Closes #1.
|
|
Add a column `playtime` to the records table to keep track of how long a
song was played.
With this information, in the future, we will be able to sum up how long
we listen to music, but also which songs were skipped.
|
|
The program needs two arguments: the mpd host and port, which can be
passed as flags (default is to use the local instance of mpd).
We store the database in `XDG_CONFIG_HOME/mpd-scrobbler`, and we create
the path if needed.
|
|
To compare the current attributes with the current record, we can use
the helper `EqualAttrs` which will tell us if we need to create a new
record or not.
|
|
|
|
When creating a scrobbler, we provide the path to the database. The
scrobbler then get a handler to the database.
When a new record is created, we persist it to the database using the
`save` function.
|
|
When we create a new record, let's capture when this was created.
|
|
We want to persist the records in a database, so we can extract
statistics and an history.
The module for the database is straightforward: it opens the database if
it exists and return an handler to it. If the database does not exists,
we create it and we create the only table we need (records).
|
|
|
|
Add a new function to create a scrobbler. The function takes care of
creating the mpd client.
Add a function to run the scrobbler, which takes care of creating a new
record when needed.
This will simplify the interface for the caller, as all they really care
about is: create the scrobbler, close it when we're done, and collect
songs information while we listen to our music.
|
|
|
|
Let's close both the watcher and the client, instead of leaking this
interface to the user.
|
|
|
|
When we receive an event from the player, we look if the song is
different from the previous one, and we create a new record if that's
the case. If the song is similar, there's nothing to do.
|
|
Define the type for a log record and add an helper function to create a
new record.
|
|
We create a module "mpd" to interact with our MPD instance. For now we
only have a single function to create a new client, which creates an
actual client for mpd (and we ping the instance every 30 seconds), and
a watcher to receive new events.
The tool "scrobbler" then wait for new events and display songs
information.
|
|
Describe what is being collected.
|
|
|
|
|
|
I do not use drone anymore, no need to keep this around.
Change-Id: I8f9564747939a6d1a2b95bcfe8e2c70e46d8bc1e
Reviewed-on: https://cl.fcuny.net/c/world/+/411
Tested-by: CI
Reviewed-by: Franck Cuny <franck@fcuny.net>
|
|
I don't need tags in this repository. There's no need to create them
after a deploy.
Before stopping the fly.io agent, checks that we're in the CI
environment.
Change-Id: I6208b70023c6ae74d58e535e24b44221956dbe63
Reviewed-on: https://cl.fcuny.net/c/world/+/408
Tested-by: CI
Reviewed-by: Franck Cuny <franck@fcuny.net>
|
|
The buildKite agents need this information in order to vote after a
build.
Change-Id: If03ba51d55f4d1155c6b7fdadace3b4643480258
Reviewed-on: https://cl.fcuny.net/c/world/+/342
Reviewed-by: Franck Cuny <franck@fcuny.net>
|
|
buildKite can call specific hooks at various stages ([1]). We add a hook
to run after each command. For now we only care if the label of the
command is `:hammer:', since this is what we've defined for our pipeline.
After a successful build, the agent will post a review with +1 if it's a
success, or -1 if the build results in failure.
[1] https://buildkite.com/docs/agent/v3/hooks#job-lifecycle-hooks
Change-Id: I6b2b886c13e6f23ddbc96fd3e865f0d50d625446
Reviewed-on: https://cl.fcuny.net/c/world/+/305
Reviewed-by: Franck Cuny <franck@fcuny.net>
|
|
Change-Id: Id9da12e3a42d42d67cb9962b1ad0b7d27e860663
Reviewed-on: https://cl.fcuny.net/c/world/+/201
Reviewed-by: Franck Cuny <franck@fcuny.net>
|
|
When a patchset is created, gerrit will call this tool with a number of
arguments.
This hook triggers a build with buildKite for the given patchset, and
add a comment to gerrit with a link to the build.
We do not wait for the build to be successful to update gerrit. This
will be done by another hook which the buildKite agents will call once
they are done with the build.
Change-Id: Iaa221765f3c52875ec37c5d282ba0557291eb5a4
Reviewed-on: https://cl.fcuny.net/c/world/+/171
Reviewed-by: Franck Cuny <franck@fcuny.net>
|
|
Change-Id: Ib2792fa8c3f861d290f2495a10672cdfd11c48d9
|
|
These files are not needed in the monorepo.
Change-Id: I742316d7a6fae817bedbcd2e1f91963bc24c91b7
|
|
Integrate properly the tool `dnsupdate` with flake.nix, by adding a
default.nix inside its directory.
Having all the tools under a directory named `tools` is easier to reason
about. I don't need a go.mod at the top level directory either, each
tool will have its own.
|
|
|
|
|
|
Remove the target from the Makefile, add a target to the flake
configuration.
|
|
|
|
|
|
|
|
|
|
The version was evaluated before the deploy was done, we need to get
that information after running `flyctl deploy`.
Annotate the tag since we're doing a release.
Remove the argument `IMAGE_REF` since it's being ignored.
|
|
|
|
|
|
Prior to this change, the size of the image was about 300MB:
```
; docker images|grep fcuny/golang|grep days
fcuny/golang.fcuny.net d07add42f21a69e2c057eae8492bbd599dc50082 9fd284c5d8ee 2 days ago 313MB
fcuny/golang.fcuny.net ca3dd083f8d6642821781ce03829713524322bbe 8104afadfd1f 2 days ago 313MB
```
With this change, we're reducing the image to less than 10MB:
```
fcuny/golang.fcuny.net 19b3dccc1ff31534df3636d4d7d6a28c0ae1e189 c9ae35574f8e 24 seconds ago 9.09MB
```
Since there's storage and bandwidth involved in this process, there's no
point in not going for a smaller image.
|
|
|
|
Don't deploy to Google App anymore, but use fly.io instead.
Add steps to the Makefile to build a docker image, and to deploy the
application to fly.io.
|
|
The repository for `homelab` is not ready yet.
|
|
Rewrite the program to use external templates and load the configuration
from an external source.
We don't want to blindly send all the requests to some SCM since we want
to support only some modules / program that way.
There's two templates, one for requests coming from a browser, which
list all the supported modules, and one for the `go get` command.
For requests coming from `go get`, we generate a template that indicates
where the repository is.
The external configuration is in YAML, and list all the supported
repositories, and the URL of the repository. It assumes a default VCS
for all the modules (git in our case).
|
|
|
|
Add a target to open the console.
|
|
|
