Update workflow: version diff never fetches — make step 2 a real release check#1519
Closed
erf1nd0r wants to merge 1 commit into
Closed
Update workflow: version diff never fetches — make step 2 a real release check#1519erf1nd0r wants to merge 1 commit into
erf1nd0r wants to merge 1 commit into
Conversation
…load via the bootstrap when behind The old step 2 compared 'the release version being updated to' against the install marker, but nothing in the workflow ever fetched a release: the only version on hand was the on-disk payload's own — i.e. the value that wrote the marker. The diff was self-referential, so an installed user running the Update workflow always got 'already current', even with a newer release published. install.sh already resolves the latest release dynamically (7.1.1), but no step told an existing install to run it. Step 2 now reads the installed version from LIFEOS/VERSION (shipped since 7.1.1), resolves the latest tag from the same GitHub endpoint the bootstrap uses, and when behind, re-runs the shipped install.sh (additive: replaces only the LifeOS skill dir, backs up the prior one) before continuing with the new payload's workflow. Offline degrades gracefully to re-applying the current version. Step 3 now also overwrites the VERSION marker — the copyMissing deploys never touch an existing file, so without this the stale marker would re-trip step 2 on every future update. Mirrored into the nested payload copy (install/skills/LifeOS).
Owner
|
Ported into source exactly as written — step 2 is a real release check and step 3 overwrites the VERSION marker; the workflow text credits you. Closing the PR because the public repo is release-generated (merge-back doctrine); your fix ships in the next release. The anti-pattern note you embedded ("payload-vs-marker is not a release check") is the kind of line that prevents regressions — appreciated. |
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
2 participants
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.
Problem
An installed user who runs the LifeOS skill's Update workflow always gets "already current", no matter how far behind their install is.
Step 2 says to compare "the release version being updated to" against the install marker — but nothing in the workflow ever fetches a release. The only version available on disk is the payload the skill itself shipped with, which is exactly what wrote the install marker. The comparison is self-referential, so it can never detect a newer release.
7.1.1 fixed the other half of this (
install.shnow resolves the latest release dynamically), but no step tells an existing install to re-run the bootstrap — so the fix is unreachable from the update path. Hit in practice: an install on 7.0.0, with v7.1.1 published, reported "already current".Change (docs only, 2 files — the workflow + its nested payload mirror)
Step 2 → a real release check:
<configRoot>/LIFEOS/VERSION(the install marker, shipped since 7.1.1; absent → treat as behind)tag_namefrom the same GitHub releases endpoint the bootstrap resolves againstinstall/install.shfirst (additive: replaces only the LifeOS skill dir, backs up the prior one), then continue from the new payload's workflowStep 3 additionally overwrites the
VERSIONmarker — the copyMissing deploys never touch an existing file, so without this the marker stays stale and step 2 re-trips on every future update.Possible follow-ups (intentionally not bundled)
--network("installed 7.0.0, latest 7.1.1") would fit 7.1.1's install-awareness direction, but mapping "update available" onto the live/broken/declined states is a maintainer call, so it's left out here.