Graduate lockfile from experimental to stable#1212
Graduate lockfile from experimental to stable#1212brooke-hamilton wants to merge 9 commits intodevcontainers:mainfrom
Conversation
Signed-off-by: Brooke Hamilton <[email protected]>
Signed-off-by: Brooke Hamilton <[email protected]>
Signed-off-by: Brooke Hamilton <[email protected]>
Signed-off-by: Brooke Hamilton <[email protected]>
chrmarti
left a comment
chrmarti
left a comment
There was a problem hiding this comment.
Great, thanks! Really just one question: The two experimental properties are no longer needed in code, it seems?
Signed-off-by: Brooke Hamilton <[email protected]>
Signed-off-by: Brooke Hamilton <[email protected]>
|
@chrmarti please look at my most recent commit that adds This could cause confusion for developers who run a test and see the lockfile changed, giving a false indication that their code change caused the lockfile to change. I found this when running tests unrelated to the lockfile tests. The downside is that intentionally adding a lockfile to these folders requires an explicit |
| if (experimentalLockfile) { | ||
| process.stderr.write('Warning: --experimental-lockfile is deprecated. Lockfiles are now enabled by default.\n'); | ||
| } | ||
| if (experimentalFrozenLockfile) { |
There was a problem hiding this comment.
Not specific to this PR, but we should refactor these to avoid the duplicate logic.
There was a problem hiding this comment.
Fixed. Thank you!
chrmarti
left a comment
chrmarti
left a comment
There was a problem hiding this comment.
LGTM! Could you resolve the merge conflict? Otherwise ready for merging. Thanks!
…ate-lockfile Bring in the 0.86.1 fix that excludes `--additional-features`-only features from the lockfile, and integrate it with the lockfile graduation work on this branch. Conflict resolution: - src/spec-configuration/containerFeaturesConfiguration.ts: Drop the `initLockfile` argument from the `writeLockfile` call. The graduation work removed `forceInitLockfile` from `writeLockfile` and `initLockfile` from `readLockfile`'s return, so the incoming reference no longer compiles. The remaining `generateLockfile(featuresConfig, config, additionalFeatures)` call from main is preserved inside the `!params.noLockfile` guard. Other reconciliations: - package.json: keep 0.87.0 (graduation release) instead of 0.86.1 so the version reflects the graduation feature set being shipped. - CHANGELOG.md: move the 0.87.0 graduation entry under "May 2026" and nest the 0.86.1 bullet beneath it for historical accuracy. Signed-off-by: Brooke Hamilton <[email protected]>
Signed-off-by: Brooke Hamilton <[email protected]>
Done. I also made an additional edit to the |
3 participants
This pull request graduates the lockfile feature from experimental to stable. Lockfiles are now generated by default during
buildandupcommands to ensure reproducible builds. New CLI flags (--no-lockfileand--frozen-lockfile) are introduced for more explicit control, while the old experimental flags are deprecated but still accepted with warnings.Lockfile Feature Graduation and CLI Changes:
.devcontainer-lock.json) are now generated by default onbuildandup, pinning feature versions for reproducibility. [1] [2]--no-lockfile(disables lockfile generation/verification) and--frozen-lockfile(enforces lockfile existence and immutability). Deprecated--experimental-lockfileand--experimental-frozen-lockfilewith warnings. [1] [2] [3] [4] [5] [6]Documentation and Tooling:
README.mdandCHANGELOG.mdto reflect lockfile graduation and new CLI behavior. [1] [2]docs/contributing-code.mdto clarify packaging requirements before running tests.This PR closes issue #1195
There are no spec changes in this PR, but there is a related proposal at devcontainers/spec#727