Repository navigation
fix(updater): apply new manifest and version pins in a single Update - #362
Open
gmmcosta15 wants to merge 2 commits into
Open
gmmcosta15 wants to merge 2 commits into
gmmcosta15 wants to merge 2 commits into
Conversation
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
One Update now applies everything a BlocksScreen release ships, including
components.yamlpin or branch changes and new updater code. Previously a new Spoolman pin needed a second Update and, because of a status bug, was never applied at all.Changes
executor.py: a pinnedversionreports 1 pending update while HEAD is off the pin (it was always 0, so a new pin never counted as dirty);remote_versiondescribes the pin; newgit_show_file(sha refs only).models.py:ComponentStatus.needs_updatereplaces the inline dirty predicate in_update_all_locked, so the batch and the follow-up share it.hooks/BlocksScreen.sh: anupdater/change writescodeto the restart sentinel (the existing_apply_deferred_restartpath: import self-test, then post-batch self-restart). Acomponents.yamlchange also writes the pre-update hash to~/.cache/blockscreen/updater_followup, keeping the oldest base across chained updates.components.py:load_components(bundled_text)parses a given manifest instead of the bundled file.service.py:run_followupruns once after a daemon restart. It diffs the manifest at the marker hash against the loaded one, then updates the changed entries that are also dirty. BlocksScreen itself is excluded, so it cannot loop.dbus_service.py: the boot loop calls the follow-up after provisioning and re-polls at the retry interval while it is deferred. A follow-up that ran also triggers the background apt sweep that the restart skipped.Motivation
Root causes:
components.yamlis loaded once inUpdateService.__init__, andupdate_allruns BlocksScreen last under the old manifest.commits_behind=0.coderestart sentinel, so new updater code was only adopted on the next deploy or reboot.The fix follows Homebrew's
update.sh: it pulls brew and the taps first, then runsbrew update-reportin a new process, so the new manifest is applied by new code.Old daemons are covered too. The daemon runs from the repo, so a Release-2.0 daemon executes the new hook after staging, and its
_read_clear_sentinelalready handlescode.Tests
git_show_filesha-only guardneeds_updaterun_followup: no marker, malformed marker, printing, deploy, lock, apply, one-shot on failure, nothing dirty, offline cap_followup_targets: changed ∩ dirty, BlocksScreen excluded, missing base