Merge karman repo into this one

.github/ISSUE_TEMPLATES/bug_report.md

@@ -0,0 +1,31 @@
+---
+name: Bug report
+about: Create a report to help us improve
+title: ''
+labels: bug
+assignees: ''
+---
+
+### Describe the bug
+A clear and concise description of what the bug is.
+
+### To Reproduce
+Steps to reproduce the behavior:
+1. Go to '...'
+2. Click on '....'
+3. Scroll down to '....'
+4. See error
+
+### Expected behavior
+A clear and concise description of what you expected to happen.
+
+### Screenshots
+If applicable, add screenshots to help explain your problem.
+
+### Client Information
+- Operating System: [e.g. iOS]
+- Browser/Client: [e.g. chrome, curl]
+- Version: [e.g. 22]
+
+### Additional context
+Add any other context about the problem here.

.github/ISSUE_TEMPLATES/config.yml

@@ -0,0 +1 @@
+blank_issues_enabled: true

.github/ISSUE_TEMPLATES/feature-proposal.md

@@ -0,0 +1,27 @@
+---
+name: Feature Proposal
+about: Propose a new feature for Karman
+title: ''
+labels: proposal, status/draft
+assignees: ''
+---
+
+### What feature do you want to propose?
+A clear and concise description of what you want Karman to be able to do.
+
+### Why does Karman need this feature?
+Give one or more reasons why this is a problem that needs to be solved.
+
+### How do users access the feature?
+How or where would this feature be available in the Karman UI or API? When should this feature be triggered automatically (if applicable)?
+
+### Describe alternatives you've considered
+A clear and concise description of any alternative solutions or features you've considered.
+
+### Additional context
+Add any other context or screenshots about the feature request here.
+
+<!--
+### Implementation Considerations
+If this proposal is promising maintainers may add implementation considerations. If you are a contributor you can write something here, too.
+-->

.github/ISSUE_TEMPLATES/question.md

@@ -0,0 +1,16 @@
+---
+name: Question
+about: Ask a Question
+title: ''
+labels: question
+assignees: ''
+---
+
+### Is this a question about Karman or about the code?
+This helps getting the right people to answer your question.
+
+### What is your question?
+Try to be as clear as possible.
+
+### Additional Context
+If applicable add a screenshot or provide more context.

.github/renovate.json

@@ -0,0 +1,4 @@
+{
+  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
+  "extends": ["local>codello/.github:renovate-config"]
+}

.github/workflows/ci.yml

@@ -1,29 +1,40 @@
-on: [push, pull_request]
+name: CI
+on:
+  pull_request:
+  push:
+    branches: [ main ]
+    tags: [ "*" ]
+
+permissions:
+  contents: read
+
 jobs:
   lint:
     name: Lint
-    runs-on: ubuntu-latest
-    steps:
-      - name: Check out code
-        uses: actions/checkout@v3
-      - name: Set up Go
-        uses: actions/setup-go@v4
-      - name: Vet Code
-        run: go vet ./...
-      - name: Check Formatting
-        run: gofmt -l .
-      # TODO: Maybe use more advanced linting via golangci-lint
+    permissions:
+      contents: read
+      pull-requests: read
+    uses: codello/.github/.github/workflows/go-lint.yml@v0
+
   test:
-    name: Run Tests
-    runs-on: ubuntu-latest
-    steps:
-      - name: Check out code
-        uses: actions/checkout@v3
-      - name: Set up Go
-        uses: actions/setup-go@v4
-        with:
-          go-version-file: go.mod
-      - name: Fetch Dependencies
-        run: go mod download
-      - name: Run Tests
-        run: go test ./...
+    name: Test
+    uses: codello/.github/.github/workflows/go-test.yml@v0
+
+  build:
+    name: Build
+    uses: codello/.github/.github/workflows/go-build.yml@v0
+    with:
+      platforms: linux/amd64,linux/arm64,linux/arm,linux/386
+      ldflags: -w -s -X "main.Version=${{ github.ref_type == 'tag' && github.ref_name || '' }}"
+
+  publish:
+    name: Publish
+    if: ${{ github.event_name == 'push' }}
+    needs: [ test, build ]
+    permissions:
+      contents: read
+      packages: write
+    uses: codello/.github/.github/workflows/docker-publish.yml@v0
+    with:
+      image: ${{ github.repository_owner }}/server
+      platforms: linux/amd64,linux/arm64,linux/arm,linux/386

CONTRIBUTING.md

@@ -0,0 +1,54 @@
+#  Welcome to the Karman contributing guide
+
+Thank you for your interest in contributing to the Karman software. This guide will give you an overview of the contribution workflow.
+
+## Issues and Pull Requests
+
+Issues and pull requests are the main way of communicating changes to the codebase. Issues are usually more related to features and ideas whereas pull requests are related to an actual set of changes to the code. Feel free to open issues and start discussions.
+
+If you want to propose your own changes to the code please do open a pull request. Note that we follow [GitHub Flow](https://docs.github.com/en/get-started/quickstart/github-flow) so please read that document to get an overview of the pull request process. We recommend that you name your branches `feature/<name>` where `<name>` is an indication of the feature or change you are working on.
+
+If you are working on a new feature that others might be working on as well, we recommend opening an issue to let others know what you’re up to. This avoids situations where multiple people are working on the same feature without knowing about each other. Likewise before you start working on a feature, search for open issues of people that might have already started.
+
+The issues in this repositories can have multiple flavors indicated by their labels:
+
+- **Proposals** (`proposal`): A proposed new feature for Karman. See below for how to work with proposals.
+- **Documentation Issues** (`documentation`): Issues related to the documentation that is being held in this repository (the actual code).
+- **Questions** (`question`): Any questions about the Karman software or about the development of the software.
+- **Bugs** (`bug`): A bug report.
+- **Other** (`other`): Other issues that do not belong in any of the above categories.
+
+### Working with Feature Proposals
+
+The Karman roadmap is managed through proposals. A proposal is in essence just a GitHub issue with the `proposal` label. A proposal can propose any kinds of changes to the Karman API, frontend or both (which usually is the case). The typical lifecycle of a proposal is as follows:
+
+1. The proposal is created and the `proposal` label is assigned. At first the proposal gets assigned the `status/draft` label as well to indicate that there may still be some details to be discussed.
+2. After the proposal has been reviewed (which may involve multiple iterations of changes to the proposal) it may either get accepted or rejected which is reflected by the `status/accepted` or `status/rejected` label. If the proposal gets rejected, the issue will be closed.
+3. Either immediately after being accepted or some time later the proposal is put on the roadmap. This involves being assigned to a corresponding milestone and the `status/planned` label. At this point there should be corresponding issues in the frontend and backend repositories.
+4. The issue may be closed before the implementation is complete, depending on the nature of the proposal. This is usually the case if the proposal is either being tracked somewhere else or if the remaining challenges are purely technical and are represented through other issues.
+
+A proposal with `status/draft` or `status/accepted`  may also receive the `far future` label. This label indicates that although the proposal fits the design, it will probably not be implemented for quite some time. When the proposal reaches the `status/planned` the `far future` label should be removed.
+
+Right now there is no preferred format for a proposal. However, you should make an attempt at describing the proposed change as clearly as you can. Some proposals make take a lot of time to get implemented. The clearer you can describe the feature the lower are the chances that the understanding of the proposal changes during development.
+
+There is an issue template for feature proposals that we recommend you use. The finalized proposal should always be kept in the original issue. If the proposal has to be amended the issue is edited correspondingly. Maintainers may edit proposals to make notes about implications or implementation details. Ideally the issue itself contains only the proposal and all discussions are held in the comments (including any initial request for comments).
+
+### API Changes
+
+When contributing code be aware of the fact, that the public API of the Karman backend cannot change arbitrarily. The API is the interface between the backend and the frontend so any changes need to be properly coordinated between the two. Because of this pull requests that involve API changes usually take longer and need to be reviewed by someone working on the frontend as well.
+
+We recommend that you split your pull requests whenever possible to separate API changes from implementation changes.
+
+## Milestones and Projects
+
+We use milestones and GitHub projects to track the Karman roadmap. For each version there will be a milestone. Proposals and issues get assigned to these milestones to put them on the roadmap for that version.
+
+For some versions there may also be a GitHub project keeping track of the progress until that version is released. The project usually aggregates the issues for a specific milestone from multiple repositories.
+
+## Working with the code
+
+Editing the code should be straight forward. Use your favorite editor or IDE and just start typing.
+
+Before submitting a pull request please make sure that your code passes all tests and adheres to the coding style enforced by `golangci-lint`. These things are checked in CI and your pull request will only be merged if the CI passes.
+
+Please ensure that you add appropriate tests alongside your features.

Dockerfile

@@ -1,9 +1,14 @@
-FROM gcr.io/distroless/static
+ARG TARGETPLATFORM=linux/amd64
+ARG TARGETOS=linux
+ARG TARGETARCH=amd64
+FROM --platform=$TARGETPLATFORM gcr.io/distroless/static
 
-LABEL maintainer="codello"
+ARG TARGETPLATFORM
+ARG TARGETOS
+ARG TARGETARCH
 
+COPY --chmod=755 build/${TARGETOS}/${TARGETARCH}/karman /karman
 USER nonroot:nonroot
 
-COPY build/karman build/migrate /usr/local/bin/
-
-ENTRYPOINT ["karman"]
+EXPOSE 8080
+ENTRYPOINT ["/karman"]

README.md

@@ -0,0 +1,39 @@
+# Karman – The Karaoke Manager
+
+The **Kar**aoke **Man**ager **Karman** [ˈkaɾmɛ̃n] is a software that manages your UltraStar song library.
+
+## Motivation
+
+Everyone who has tried to manage an UltraStar karaoke library has probably experienced how difficult it can be to ensure that all songs in the library adhere to a certain quality standard. Most libraries contain low-bitrate audio, difficult file encodings, low-res or even missing artwork, incorrectly synchronized songs and a multitude of other problems. The **Karman** [ˈkaɾmɛ̃n] project aims to make it easier to manage large karaoke libraries.
+
+## Karman Overview
+
+Karman is an application running on a server that takes full control over your entire karaoke library. When using Karman you will not be moving songs into specific folders but instead you will use the import feature of the software to upload songs to the server. The software then manages the library and moves files into the right places. When you want to sing you can either sync the songs to your machine or if your network connection is fast enough you can just mount the respective folder.
+
+In contrast to existing software (most notably the [UltraStar Manager](https://github.com/UltraStar-Deluxe/UltraStar-Manager)) Karman takes a few different approaches:
+
+- Karman runs server-side and expects to be the only application or user with write access to the song library.
+- Karman has the concept of a library you import songs into. Cleaning up metadata of songs and correcting common errors usually takes place on import, not at some arbitrary time.
+- Karman can be easily extended to implement more complex optimizations for songs
+- Karman includes a library explorer that allows (potentially unauthenticated) users to browse the library. This can be very useful when singing karaoke and people want to know which songs are available.
+
+In the future Karman might do even more, eventually integrating a sophisticated song editor and intelligent library management
+
+## Karman Architecture
+
+Karman is designed to be compatible with modern development and deployment strategies. At its core the Karman software consists of the **Karman API Backend** (in this repository). The backend provides a well-documented REST API through which clients can read data and make changes. The backend implements the song management logic and most of the import logic.
+
+The user interface is implemented via a **Web Frontend**. The frontend provides the user interface of the software. It communicates with the backend exclusively via the documented REST API.
+
+## Frequently asked questions
+
+### Why is Karman a server-side application?
+
+Karman is intended for users with huge libraries consisting of hundreds of gigabytes of songs. These kinds of libraries cannot feasibly be managed manually by a single person. There were multiple factors involved in the decision of going server side:
+
+1. Storage. Growing libraries with thousands of songs quickly exceed the free storage on typical PCs.
+2. Backups. By storing songs on a server it is easy to include them in periodic backups that protect your valuable songs.
+3. Multi user support. Large libraries often come into existence when many users merge their smaller libraries. We want to offer some kind of collaborative feature that makes it possible to work on new songs together.
+4. Public index. When singing it is often very useful to be able to directo users to a website where they can search their favorite songs. This would not be possible without a server.
+
+// TODO: More questions, maybe?