Store "protos" in buildbox-casd asset cache
- Dominant language
- Python
- Stars
- 140
- Forks
- 45
- Avg merge
- 1d 3h
- Merged PRs (30d)
- 6
Description
Here is what a `~/.cache/buildstream` directory currently looks like.
```
actioncache/
artifacts/
assets/
cas/
casserver-x864eg_i.sock=
elementsources/
logs/
source_protos/
sources/
tmp/
```
There are mainly two problems with this:
- `artifacts/refs/`, `elementsources/` and `source_protos/` are used for storing "protos" that can be pushed to asset cache.
- `artifacts/` is also used by bst1 with a different layout (which luckily doesn't use `artifacts/refs/`)
I would suggest to instead store them in the asset cache of buildbox-casd (which uses the `assets/` directory).
However there is something special about the artifact protos (other than the fact they are stored in a non-toplevel directory): they are stored as `project/element-name/key` and this is reflected in the UI (the `bst artifact` commands). Which is something that needs to be discussed. Do we really need all these? Can we somehow get the same UI?
(source_protos are also currently stored as `plugin/key`, but that doesn't matter as they aren't exposed in the UI)
Contributor guide
Research direction
Start by examining the current ~/.cache/buildstream layout, especially artifacts/refs/, elementsources/, source_protos/, and assets/. Then trace the bst artifact commands and the buildbox-casd asset-cache integration to determine how artifact and source protos are addressed. Done means the storage layout and the required artifact UI behavior are agreed and implemented without conflicting with the bst1 artifacts layout.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- build-system
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100