Benson Wong
66d555e625
* docker: add .env usage in build-container.sh * .github,docker: add rocm, improve logging * .github,CLAUDE.md: fix workflow and update guidelines Update containers workflow to only push images when triggered manually or on schedule, not on workflow file changes. - add push trigger for workflow file changes in containers.yml - update push condition to skip on regular push events - update CLAUDE.md commit message guidelines * docker: remove comma in build-container.sh * .github,docker: improve container build workflow Add pagination support for fetching llama.cpp tags and improve debugging. - add build-container.sh to workflow trigger paths - implement fetch_llama_tag() with pagination support - replace .env with local testing instructions - add DEBUG_ABORT_BUILD flag for testing
1.8 KiB
1.8 KiB
Project Description:
llama-swap is a light weight, transparent proxy server that provides automatic model swapping to llama.cpp's server.
Tech stack
- golang
- typescript, vite and react for UI (located in ui/)
Workflow Tasks
- when summarizing changes only include details that require further action
- just say "Done." when there is no further action
- use
ghto create PRs and load issues - do include Co-Authored-By or created by when committing changes or creating PRs
- keep PR descriptions short and focused on changes.
- never include a test plan
Testing
- Follow test naming conventions like
TestProxyManager_<test name>,TestProcessGroup_<test name>, etc. - Use
go test -v -run <name pattern for new tests>to run any new tests you've written. - Use
make test-devafter running new tests for a quick over all test run. This runsgo testandstaticcheck. Fix any static checking errors. Use this only when changes are made to any code under theproxy/directory - Use
make test-allbefore completing work. This includes long running concurrency tests.
Commit message example format:
proxy: add new feature
Add new feature that implements functionality X and Y.
- key change 1
- key change 2
- key change 3
fixes #123
Code Reviews
- use three levels High, Medium, Low severity
- label each discovered issue with a label like H1, M2, L3 respectively
- High severity are must fix issues (security, race conditions, critical bugs)
- Medium severity are recommended improvements (coding style, missing functionality, inconsistencies)
- Low severity are nice to have changes and nits
- Include a suggestion with each discovered item
- Limit your code review to three items with the highest priority first
- Double check your discovered items and recommended remediations