You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[bugfix] Write back lockfile after devbox update (#1291)
## Summary
After calling `devbox update`, we were not writing back to `devbox.lock`. `ensurePkgsAreInstalled` would then return early because the local lock file hadn't changed (since it re-reads `devbox.lock` from disk, rather than using the updated in-memory lockfile), so it would skip writing the lockfile as well.
This also makes the lockfile a bit more self-healing, since it will overwrite the current user's sysInfo entirely, rather than just adding the CAStorePath. This ensures that the StorePath and CAStorePath are written together.
## How was it tested?
Manually, but plan to add testscripts in separate PR. I tested a few different scenarios, notably:
1. `devbox update` adds system info for current user without changing system info for other systems.
2. If current system info is missing something (either CAStorePath or Path), `devbox update` will restore it.
3. If, say, CAStorePath is missing for the current system, and the user calls `devbox shell`, then we'll print a warning instructing the user to run `devbox update`. Calling it will then actually fix the lockfile and the warning will not be reprinted. It's worth mentioning that the warning will only be shown once to the user, because then they'll cache print-dev-env, so we won't re-exercise the path that computes CAStorePath. Not super ideal, but good enough I think.
4. If current system info is missing entirely, it is added.
5. If current system info exists and matches new one, nothing is done and we print "Already up-to-date"
0 commit comments