* show images for troubleshooting
* more debug and try max space action
* fixes
* oops
* maximize first
* mount build volume for docker use
* moved to shared setup and cleanup
* remove temp branch
* remove rocm for master
Setting cache-to=compression=zstd causes the resulting user-pulled image
to have zstd-compressed layers, which are not compatible with docker
prior to 23.0. Ubuntu 20.04 still ships with docker 20.10, which yields
`Error processing tar file` when pulling these images.
Renaming the jetpack cache images is my way of clearing the cache of the
prior zstd layers, and it clarifies the convention I used for the other
cache images in which there is one cache per base image/job, not per
target/step. We don't need to delete the non-jetson cache images because
they haven't been rebuilt since zstd was enabled.
* fixup! Split independent builds into parallel jobs
* Combine caches within steps of same job
* Remove Maintain Cache workflow
Now that we're caching to ghcr instead of gha, we don't have to worry
about gha's cache eviction after 7 days/10 GB.
* Factor out common setup steps
* Re-order
* Split independent builds into parallel jobs
* Cache jetson builds
* Use zstd compression
* Switch from gha cache to registry cache
A CI run (four images cached with mode-max) populates the cache with 295
cache entries totalling 23.44 GB. This exceeds gha's 10GB limit, causing
trashing. Try with a registry instead.
* Enable manual CI runs
* Non-Jetson changes
Required for later commits:
- Allow base image to be overridden (and don't assume its WORKDIR)
- Ensure python3.9
- Map hwaccel decode presets as strings instead of lists
Not required:
- Fix existing documentation
- Simplify hwaccel scale logic
* Prepare for multi-arch tensorrt build
* Add tensorrt images for Jetson boards
* Add Jetson ffmpeg hwaccel
* Update docs
* Add CODEOWNERS
* CI
* Change default model from yolov7-tiny-416 to yolov7-320
In my experience the tiny models perform markedly worse without being
much faster
* fixup! Update docs
* Make main frigate build non rpi specific and build rpi using base image
* Add boards to sidebar
* Fix docker build
* Fix docs build
* Update pr branch for testing
* remove target from rpi build
* Remove manual build
* Add push build for rpi
* fix typos, improve wording
* Add arm build for rpi
* Cleanup and add default github ref name
* Cleanup docker build file system
* Setup to use docker bake
* Add ci/cd for bake
* Fix path
* Fix devcontainer
* Set targets
* Fix build
* Fix syntax
* Add wheels target
* Move dev container to trt
* Update key and fix rpi local
* Move requirements files and set intermediate targets
* Add back --load
* Update docs for community board development
* Update installation docs to reflect different builds available
* Update docs with official and community supported headers
* Update codeowners docs
* Update docs
* Assemble main and standard builds
* Change order of pushes
* Remove community board after successful build
* Fix rpi bake file names
* Add isort and ruff linter
Both linters are pretty common among modern python code bases.
The isort tool provides stable sorting and grouping, as well as pruning
of unused imports.
Ruff is a modern linter, that is very fast due to being written in rust.
It can detect many common issues in a python codebase.
Removes the pylint dev requirement, since ruff replaces it.
* treewide: fix issues detected by ruff
* treewide: fix bare except clauses
* .devcontainer: Set up isort
* treewide: optimize imports
* treewide: apply black
* treewide: make regex patterns raw strings
This is necessary for escape sequences to be properly recognized.
