37 lines
1.3 KiB
Markdown
37 lines
1.3 KiB
Markdown
---
|
|
status: located
|
|
opened: 2026-10-03
|
|
located-in:
|
|
- mesh-controller
|
|
fixed-by:
|
|
- mesh-controller#246
|
|
amended-design:
|
|
---
|
|
|
|
# 215 — A module built once at a commit stops following its branch, and merges leave it out
|
|
|
|
## What was observed
|
|
|
|
2026-10-03, a catalogue merge changed seven modules. Its plan built six; `unifi` was not in it,
|
|
though its change was in the same commit. A second merge the same evening left it out again. Its
|
|
build records name a commit where every other module names a branch:
|
|
|
|
```
|
|
unifi built 9c97a8a1 … http://…/mesh-catalog.git at 9c97a8a
|
|
```
|
|
|
|
Built by hand from `main` it was registered again and the change reached its machine.
|
|
|
|
## Why it matters beyond this instance
|
|
|
|
A module that was once built at a commit — to pin it during a fix, or by a build asked with a `ref`
|
|
— silently stops following its branch: merges plan without it, `status` does not say it is behind its
|
|
branch, and nothing says it is pinned. The operator learns it when a change does not arrive.
|
|
|
|
## Diagnosis
|
|
|
|
Owner mesh-controller. **Fix direction:** a build asked at a commit does not change the branch a
|
|
module follows; or, if pinning is meant, the pin is said — in `module list`, in `status`, and by a
|
|
merge's plan naming the module it leaves out and why. A test: building a module at a commit and then
|
|
merging a change to it plans it.
|