Skip to content

feat: add linglong.lock for reproducible builds - #2177

Open
reddevillg wants to merge 1 commit into
OpenAtom-Linyaps:masterfrom
reddevillg:feat_lock
Open

reddevillg wants to merge 1 commit into
OpenAtom-Linyaps:masterfrom
reddevillg:feat_lock

Conversation

@reddevillg

Copy link
Copy Markdown
Collaborator

Introduce a project lock file that pins the resolved source hashes and the selected base/runtime references:

  • ll-builder build writes linglong.lock on the first build once sources are verified and dependencies are acquired, and reuses it on later builds; --locked requires an existing, complete lock and never rewrites it, while the new generate-lockfile/update-lockfile subcommands create or refresh the lock on demand
  • source entries record the normalized declaration together with the resolved hash (sha256 for file/archive/dsc sources, the commit for git sources); dependency entries record the requested declaration and the resolved reference/modules; the lock also records the target build architecture and is rejected when it does not match
  • the digest of file/archive/dsc sources is now optional: when omitted, the first build pins the hash of the fetched source and later builds verify against it

Rework source fetching into per-kind handlers (git/file/archive/dsc) backed by a content-addressed cache under linglong/cache/sources/v1/. Cache entries are guarded by a per-entry file lock, published via atomic rename, and re-validated on every read; the fetch scripts move to an action-based interface (download/materialize/verify). As a result, --offline no longer implies --skip-fetch-source: it re-materializes sources from the validated cache and discards manual edits under linglong/sources/; use --skip-fetch-source to keep them.

Build integration:

  • dependencies are pulled at the locked reference and modules; the module set now comes from the lock instead of best-effort mounting
  • when base is omitted from linglong.yaml it follows the base declared by the runtime layer metadata, and non-locked builds may rewrite the base entry of an existing lock when that metadata changes
  • build container overlay reuse is keyed on the locked dependency state (build_overlay.state), so dependency changes reset the overlays

@codecov

codecov Bot commented Oct 13, 2026 •

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 59.08170% with 606 lines in your changes missing coverage. Please review.

Files with missing lines Patch % Lines
...linglong/src/linglong/builder/linglong_builder.cpp 51.36% 143 Missing and 70 partials ⚠️
...s/linglong/src/linglong/builder/source_fetcher.cpp 69.21% 60 Missing and 85 partials ⚠️
...ibs/linglong/src/linglong/builder/project_lock.cpp 64.68% 14 Missing and 87 partials ⚠️
...inglong/src/linglong/builder/builder_directory.cpp 58.40% 16 Missing and 31 partials ⚠️
apps/ll-builder/src/main.cpp 0.00% 44 Missing ⚠️
libs/utils/src/linglong/utils/file.cpp 44.18% 4 Missing and 20 partials ⚠️
...ibs/linglong/src/linglong/builder/source_cache.cpp 54.28% 3 Missing and 13 partials ⚠️
libs/linglong/src/linglong/runtime/run_context.cpp 45.00% 3 Missing and 8 partials ⚠️
libs/linglong/src/linglong/repo/ostree_repo.cpp 72.72% 0 Missing and 3 partials ⚠️
.../linglong/src/linglong/builder/builder_directory.h 88.88% 2 Missing ⚠️
Files with missing lines Coverage Δ
...s/linglong/src/linglong/builder/linglong_builder.h 100.00% <ø> (ø)
libs/linglong/src/linglong/builder/source_cache.h 100.00% <100.00%> (ø)
libs/linglong/src/linglong/runtime/run_context.h 73.33% <ø> (+6.66%) ⬆️
.../linglong/src/linglong/builder/builder_directory.h 88.88% <88.88%> (ø)
libs/linglong/src/linglong/repo/ostree_repo.cpp 41.43% <72.72%> (+0.80%) ⬆️
libs/linglong/src/linglong/runtime/run_context.cpp 16.47% <45.00%> (+1.69%) ⬆️
...ibs/linglong/src/linglong/builder/source_cache.cpp 54.28% <54.28%> (ø)
libs/utils/src/linglong/utils/file.cpp 40.87% <44.18%> (+7.83%) ⬆️
apps/ll-builder/src/main.cpp 0.00% <0.00%> (ø)
...inglong/src/linglong/builder/builder_directory.cpp 58.40% <58.40%> (ø)
... and 3 more

... and 6 files with indirect coverage changes

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@reddevillg
reddevillg requested review from ComixHe, dengbo11 and myml and removed request for myml October 14, 2026 02:03
Introduce a project lock file that pins the resolved source hashes and
the selected base/runtime references:

- ll-builder build writes linglong.lock on the first build once sources
  are verified and dependencies are acquired, and reuses it on later
  builds; --locked requires an existing, complete lock and never
  rewrites it, while the new generate-lockfile/update-lockfile
  subcommands create or refresh the lock on demand
- source entries record the normalized declaration together with the
  resolved hash (sha256 for file/archive/dsc sources, the commit for
  git sources); dependency entries record the requested declaration and
  the resolved reference/modules; the lock also records the target
  build architecture and is rejected when it does not match
- the digest of file/archive/dsc sources is now optional: when omitted,
  the first build pins the hash of the fetched source and later builds
  verify against it

Rework source fetching into per-kind handlers (git/file/archive/dsc)
backed by a content-addressed cache under linglong/cache/sources/v1/.
Cache entries are guarded by a per-entry file lock, published via
atomic rename, and re-validated on every read; the fetch scripts move
to an action-based interface (download/materialize/verify). As a
result, --offline no longer implies --skip-fetch-source: it
re-materializes sources from the validated cache and discards manual
edits under linglong/sources/; use --skip-fetch-source to keep them.

Build integration:

- dependencies are pulled at the locked reference and modules; the
  module set now comes from the lock instead of best-effort mounting
- when base is omitted from linglong.yaml it follows the base declared
  by the runtime layer metadata, and non-locked builds may rewrite the
  base entry of an existing lock when that metadata changes
- build container overlay reuse is keyed on the locked dependency
  state (build_overlay.state), so dependency changes reset the overlays

Signed-off-by: reddevillg <reddevillg@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant