Development

The HTTP server uses Fuego , with existing net/http handlers to preserve streaming, range requests, conditional requests, and HEAD support. Asset routes accept GET and HEAD; other methods return 405. OpenAPI generation and Swagger routes are disabled for this file-serving application. Server timeouts are 15 seconds for reads/writes, 5 seconds for headers, and 60 seconds for idle connections.

go build ./...
go test ./... -race
go vet ./...
go run . -serve

Behavioral tests

Behavioral checks are defined in features/**/*.feature, including configuration, image options, resources, middleware, CLI/release handling and plugin execution. Gocuke runners in each Go package bind these scenarios to Go step implementations. Scenario outlines keep test inputs and expected outcomes in the feature files.

# Run all feature suites through Go's test runner.
go test ./... -run 'Features$' -v

# Run the complete suite with the race detector.
go test ./... -race

Add or change the appropriate feature scenario when behavior changes. Go test functions serve as suite runners or subprocess fixtures; setup, actions and assertions belong in step implementations. Conversion scenarios skip only when their required tools are unavailable. Image scenarios check decoded dimensions and pixels for resizing, crop positioning, flipping and color transformations. CLI and release tests use a fake release transport and never contact GitHub or modify the running executable.

Configuration loading uses a separate Viper instance per load and publishes the new configuration after validation. CLI operations keep configuration and release metadata local. Production and server tests share newServer, including its codec registry and middleware. Use slices.Clone and maps.Clone when returning independent registries or lists; keep callback and close serialization at the runtime boundary. See Go Code Review Comments for general Go conventions.

Self-updates use go-selfupdate with archive filters matching GoReleaser and mandatory checksums.txt verification. Updater feature scenarios use local HTTP fixtures and temporary executables; they never replace the test process or download live releases. Rate limiting uses go-limiter’s in-memory fixed windows. Call the cleanup function returned by newServer after stopping the HTTP server to release its limiter store.

Plugin integration checks

Run go test ./... -race when changing discovery, inheritance, callbacks, codecs or external-tool processing. Core process tests use an arbitrary text tool. Example loading is always tested; conversion tests require FFmpeg and ImageMagick. macOS CI uses Homebrew’s ffmpeg-full for the audio plugin’s Vorbis encoder; see audio dependencies for local setup, and QOA additionally needs qoaconv on PATH. Linux CI builds a pinned QOA tool. See QOA setup for building it locally.

Container packages

The Docker guide covers local builds and deployment. The container workflow publishes multi-platform GHCR images on main and v* tags and builds pull requests without pushing. The Dockerfile excludes plugins by default; install them through a startup mount. Go tests remain in the existing test workflow.

Documentation site

The README, reference pages and example READMEs are the documentation sources. Hugo renders them using the repository’s small documentation layout, with sidebar navigation, syntax highlighting and automatic light/dark colors. Markdown links keep working on GitHub; a Hugo render hook changes their .md destinations to published .html pages. The existing page URLs and mascot images are preserved. Edit a topic in its reference page and link to it from examples instead of copying shared API, deployment or execution-limit details.

In the repository’s Settings → Pages, select GitHub Actions as the publishing source. Branch publishing runs a separate Jekyll deployment that can overwrite the Hugo site and cause a 404 at the home page. After changing the source, run the Documentation workflow on main to publish Hugo. Keep the custom domain set to assetgoblin.sbolch.hu. The documentation workflow builds pull requests for validation and deploys pushes to main or a manual run on main. It publishes only documentation and site assets; application source and Python scripts are excluded. The workflow uses GitHub’s Pages actions; see GitHub’s setup guide .

To preview locally, install Hugo 0.167.0 (the version pinned in the workflow), then run:

hugo server

Open http://localhost:1313/. To reproduce the deployment build:

hugo --destination _site --minify --panicOnWarning

hugo.toml mounts the existing README, reference pages and plugin READMEs without copying them into a separate content folder. Only Markdown files are mounted from plugin folders; Python files and application sources are never published. Page front matter defines titles, weights and stable URLs. layouts/ contains the templates and link hook; assets/docs.css provides styling. Generated _site and Hugo build state are ignored. No Ruby, Bundler, Node.js or external theme installation is required.