You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Beatnik Controller is a web-based remote control for your [Snapcast](https://github.com/badaix/snapcast) multi-room audio server. It allows you to easily manage and control audio streams from any device with a web browser. The application can also be compiled for Android and iOS.
5
+
Beatnik Controller is a web-based remote control for your [Beatnik Pi](https://github.com/byrdsandbytes/beatnik-pi) or [Snapcast](https://github.com/badaix/snapcast) multi-room audio server. It allows you to easily manage and control audio streams from any device with a web browser. The application can also be compiled for Android and iOS and is available in the App- & Play Store.
6
+
7
+
6
8
7
9
## Features
8
10
@@ -20,10 +22,16 @@ To run Beatnik Controller, you will need:
20
22
21
23
## Installation & Usage
22
24
23
-
Getting started with Beatnik Controller is simple with Docker.
24
-
If you have trouble setting up docker compose check our guide: [DOCKER_INSTALLATION.md](./docs/DOCKER_INSTALLATION.md)
25
+
There are two ways to get Beatnik Controller running:
26
+
27
+
1.**Run with Docker (Recommended):** This is the easiest way to get started. It uses the pre-built Docker image from our registry and requires no local setup.
28
+
2.**Build from Source:** This is for developers who want to modify the code or contribute to the project.
29
+
30
+
### Method 1: Run with Docker (Recommended)
25
31
26
-
### 1. Get the Code
32
+
This method uses Docker to run the application without needing to build it yourself.
By default, the application will try to connect to a Snapcast server at `beatnik-server.local`. If your server is at a different address, you can configure it in two ways:
43
+
#### 2. Configure the Beatnik Pi or Snapcast Server (Optional)
38
44
39
-
-**During Setup (Optional):** Edit `src/environments/environment.prod.ts` and change `snapcastServerUrl` to your server's hostname or IP address.
40
-
-**In-App Settings:** Once the application is running, you can go to the settings page and change the Snapcast server address directly in the user interface.
45
+
By default, the application will try to connect to a Snapcast server at `beatnik-server.local`. If your server is at a different address, you can configure it in the in-app settings once the application is running.
41
46
42
-
### 3. Run with Docker
47
+
####3. Run with Docker
43
48
44
-
Once configured, you can build and run the application using Docker Compose:
49
+
You can run the application using Docker Compose:
45
50
46
51
```bash
47
52
docker compose up -d
48
53
```
49
54
50
-
This will build the Docker image and start the application in the background.
55
+
This will pull the latest Docker image and start the application in the background.
51
56
52
-
### 4. Access the Application
57
+
####4. Access the Application
53
58
54
59
Open your web browser and navigate to `http://localhost:8181` or `http://your-hostname.local:8181`. You should now see the Beatnik Controller interface.
55
60
61
+
### Method 2: Build from Source (for Developers)
62
+
63
+
This method is for developers who want to modify the code or contribute to the project.
#### 2. Configure the Beatnik Pi or Snapcast Server (Optional)
75
+
76
+
By default, the application will try to connect to a Snapcast server at `beatnik-server.local`. If your server is at a different address, you can edit `src/environments/environment.ts` and change `snapcastServerUrl` to your server's hostname or IP address.
77
+
78
+
#### 3. Build and Run
79
+
80
+
You have two options for building and running the application locally:
81
+
82
+
##### Build with Docker
83
+
84
+
If you want to build the Docker image from the source code, you can use the provided `docker-compose.build.yml` file. This is useful for testing local changes in a containerized environment.
85
+
86
+
```bash
87
+
docker compose -f docker-compose.build.yml up -d --build
88
+
```
89
+
90
+
This command builds the image and runs it locally. The application will be available at `http://localhost:8181`.
91
+
56
92
## Contributing
57
93
58
-
If you are a developer and want to contribute to the project, build mobile apps, or run the application in a development environment, please see our [CONTRIBUTING.md](CONTRIBUTING.md) file for more information.
94
+
We welcome contributions! If you'd like to help improve Beatnik Controller, please see our [CONTRIBUTING.md](CONTRIBUTING.md) file for more information on how to get started. For details on the automated build pipeline, see [BUILD_PIPELINE.md](./docs/BUILD_PIPELINE.md).
This document outlines the automated build and release process for the Beatnik Controller application, which uses GitHub Actions to create and publish a multi-platform Docker image.
4
+
5
+
## Overview
6
+
7
+
The build pipeline is defined in the `.github/workflows/build-docker.yml` file. Its primary purpose is to build the Beatnik Controller frontend, package it into a Docker image, and publish it to the GitHub Container Registry (GHCR).
8
+
9
+
The pipeline produces a Docker image that supports two different computer architectures:
10
+
11
+
-`linux/amd64`: For standard desktop computers and servers.
12
+
-`linux/arm64`: For ARM-based devices like the Raspberry Pi.
13
+
14
+
This allows you to run the same container on a wide range of hardware.
15
+
16
+
## How It Works
17
+
18
+
The pipeline is triggered in two ways:
19
+
20
+
1.**Manual Trigger:** You can start the build manually from the "Actions" tab in the GitHub repository. This is useful for creating development or test builds. When triggered this way, you can specify a version number.
21
+
2.**Automatic Trigger (on Git Tag):** The build runs automatically whenever a new Git tag matching the pattern `v*` (e.g., `v1.0.0`, `v1.2.3`) is pushed to the repository. This is the standard process for creating a new release.
22
+
23
+
### Build Steps
24
+
25
+
The build process consists of the following steps:
26
+
27
+
1.**Checkout Code:** The workflow begins by checking out the latest source code from the repository.
28
+
2.**Set Up Docker Buildx:** It initializes Docker Buildx, which is a tool that enables multi-platform builds.
29
+
3.**Log in to GHCR:** The workflow logs into the GitHub Container Registry using a temporary token. This step is skipped for pull requests.
30
+
4.**Extract Metadata:** It generates metadata for the Docker image, including tags and labels based on the Git history.
31
+
5.**Determine Version:** The version number for the build is determined:
32
+
- If triggered by a Git tag (e.g., `v1.2.3`), the version is extracted from the tag (`1.2.3`).
33
+
- If triggered manually, it uses the version number provided at the start of the build.
34
+
6.**Build and Push Image:** The workflow builds the Docker image using the `Dockerfile` at the root of the repository. It passes the version number as a build argument and builds for both `linux/amd64` and `linux/arm64` platforms. If the build was not triggered by a pull request, the resulting image is pushed to GHCR.
35
+
36
+
## Published Image
37
+
38
+
The final Docker image is published to the following location:
39
+
40
+
`ghcr.io/byrdsandbytes/beatnik-controller`
41
+
42
+
You can pull and run this image using standard Docker commands. For example, to pull the latest version:
0 commit comments