Show the running commit instead of just the release tag for dev deploys - #4653
Draft
chalfontchubby wants to merge 2 commits into
Draft
Show the running commit instead of just the release tag for dev deploys#4653chalfontchubby wants to merge 2 commits into
chalfontchubby wants to merge 2 commits into
Conversation
chalfontchubby
force-pushed
the
feature/dash-versions
branch
from
August 22, 2026 17:03
ce8f160 to
329cd2b
Compare
| cmd += "mv -f {} {} && ".format(os.path.join(this_path, file + "." + tag), os.path.join(this_path, file)) | ||
| cmd += "echo 'Update complete'" | ||
| os.system(cmd) | ||
| clear_deploy_git_version(this_path) |
Owner
There was a problem hiding this comment.
This might want to be before the os.system(cmd) as touching the files triggers a restart
chalfontchubby
marked this pull request as draft
August 22, 2026 21:55
…e running version is rather than a tag
Also fix record_status() writing the status entity's last_updated attribute
via str(datetime.now()) - a naive, sub-second-precision string in a format
str2time() can't parse - so the web dashboard's Last Updated field rendered
raw microseconds instead of a clean timestamp. Now written via TIME_FORMAT
like last_started already is, and parsed/rounded to whole seconds for
display in web.py.
Uses self.now_utc_real rather than self.now_utc: the latter is deliberately
snapped to the PREDICT_STEP grid for the simulation (see update_time()), so
using it here made Last Updated show a rounded, past minute instead of the
actual time record_status() ran. now_utc_real is the same true wall-clock
source last_started already uses (self.started_time = self.now_utc_real).
Also fixes is_running(): it reads the same last_updated attribute, and its
naive datetime.now() comparison broke once the attribute became tz-aware
("can't subtract offset-naive and offset-aware datetimes"), which was
showing as Unhealthy on the web dashboard. Now compares against
datetime.now(timezone.utc).
Reorders predbat_update_move() per review: clear_deploy_git_version() now
runs before the mv, so the marker is gone before any new process (including
one started by a hot-reload the mv itself triggers) could read it.
chalfontchubby
force-pushed
the
feature/dash-versions
branch
from
August 22, 2026 22:28
edbc195 to
551077f
Compare
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.
Summary
coverage/deployandhass.pynow write agit_version.txtmarker (source commit,-dirtyif the tree has local changes) alongside the deployed.pyfiles, so a dev checkout or the standalone-against-live-HA workflow can be told apart from an actual tagged release.THIS_VERSION_DISPLAY, shown wherever the version is surfaced for humans (web UI header/menu, the Dashboard page, thepredbat.statusentity'sversionattribute, the generated Lovelace dashboard card, and thegithub.pystartup log line). The realTHIS_VERSIONtag is left untouched everywhere it drives actual logic - the GitHub release-tag match, the HAupdateentity'sinstalled_version/release_url(changing that would falsely show "update available" forever), the Prometheusversionlabel, and the manual version-select comparison.download.py'spredbat_update_move()clears the marker after a real update lands, so a stale dev-commit marker doesn't linger once official release files are installed.record_status(), found while testing this on a live deploy: the status entity'slast_updatedattribute was written viastr(datetime.now())- a naive, sub-second-precision string in a shapestr2time()can't parse - so the web dashboard's "Last Updated" field rendered raw microseconds. It's now written viaTIME_FORMAT(matching howlast_startedis already written) usingself.now_utc_real- the true wall-clock time, not the PREDICT_STEP-grid-snappedself.now_utc- and parsed/rounded to whole seconds for display inweb.py.Test plan
./run_all --test github,./run_all --test download,./run_all --quick, and./run_all -k weball passpre-commit(ruff, black, cspell) passes on all touched filesread_deploy_git_version/clear_deploy_git_versionround-trip and thehass.pymarker-writer resolves correctly through the symlinked.pyfilescoverage/standalone_hasets upv8.50.0 (<commit>[-dirty]), andLast Updatedshows a clean wall-clock second-precision timestamp afterrecord_status()next fires🤖 Generated with Claude Code