The canary workflow passed VERSION=canary as a build-arg, so the demo
instance reported "canary" as its version. Derive the version from the
latest git tag instead (e.g. 0.29.1) so the app reports a real semver.
The `canary` image tag is unchanged.
Add area dropdowns, reproduction requirements, regression info, and
compatibility sections to reduce back-and-forth on bug reports and
feature requests.
Replace `labels: [bug]` and `labels: [enhancement]` with `type: Bug`
and `type: Feature` to leverage GitHub's native issue types already
configured on this repo.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Add PR stale/close handling alongside issues
- Reduce close grace period from 7 to 3 days
- Add inline comments explaining the two-phase stale behavior
- Rename workflow and job names for clarity
- Add workflow_dispatch trigger for manual binary builds
- Build for linux (amd64, arm64, arm/v7), darwin (amd64, arm64), windows (amd64)
- Package as tar.gz (Unix) and zip (Windows)
- Generate build summary with artifact sizes
Problem:
- store/test/TestMain checks if DRIVER env var is set
- If not set, it runs tests for all 3 drivers (sqlite, mysql, postgres)
by spawning child 'go test' processes
- This conflicts with t.Parallel() in individual tests
- CI workflow didn't set DRIVER, triggering multi-driver execution
Solution:
- Set DRIVER=sqlite in GitHub Actions workflow
- TestMain will run tests once with SQLite driver
- Tests run in parallel with t.Parallel() as intended
- Avoids spawning child processes and race conditions
Why SQLite:
- Fastest test execution (no container startup)
- Sufficient for CI validation
- MySQL/Postgres can be tested locally when needed
This fixes the 'table already exists' errors and test flakiness
in CI while maintaining parallel execution benefits.
Improve bug report and feature request templates to reduce duplicate submissions and gather better information:
Bug Report Template:
- Add pre-submission checklist requiring users to search existing issues and test on latest version/demo
- Add dropdown for issue location (stable, dev, demo site, older version)
- Restructure fields with clearer labels and better placeholders
- Add "Expected Behavior" section for clarity
- Combine screenshots and context with helpful prompts
Feature Request Template:
- Add pre-submission checklist to confirm issue search
- Expand feature type categories (API/Backend, Integrations/Plugins, Security/Privacy, Performance)
- Add "Problem or Use Case" field to understand the underlying need
- Add "Alternatives Considered" section
- Improve placeholders with specific examples
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>