Respect user-overridden Core image for install and update - #7092
Draft
agners wants to merge 1 commit into
Draft
Conversation
The override_image setting was only honored by load(): the landingpage install, the initial Core install and Core updates always pulled the image from the update information and wrote it back to the Home Assistant config afterwards, discarding the user override on the next install or update. Add a HomeAssistant.install_image property that returns the user-overridden image if set and the image from the update information otherwise. Use it in the landingpage install, Core install and Core update paths, and persist that same image afterwards so the override is kept. Version resolution is unchanged. With an override set, a fresh install now pulls <image>:landingpage from the overridden image as well. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Member
Author
|
The current override_image does not seem very useful to me, but then this is hacky too since it forces an alternative image source to create releases in lockstep with our release cadence 🤷 . |
Member
Author
|
This essentially makes it easier to run your own fork. You'll have to make sure the release is in lockstep with Core (rather easy if you track beta/stable). We probably want to know if a user runs a Core fork. So yes, let's do this, but mark the system unsupported (which we should have probably done anyways if it is set even without the updateable wrinkle). |
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.
Proposed change
The
override_imagesetting (set when a user configures a custom Coreimagevia/core/options) was only honored byload(). The landingpage install, the initial Core install and Core updates always passedimage=self.sys_updater.image_homeassistantto the Docker layer and wrote that image back to the Home Assistant config afterwards, discarding the user override on the next install or update.This adds a
HomeAssistant.install_imageproperty that returns the user-overridden image whenoverride_imageis set, and the image from the update information otherwise. The landingpage install, Core install and Core update paths now use it for the image pull and persist that same image afterwards, so the override survives installs and updates. Version resolution is unchanged and still comes from the update information.Behavior note: with an override set, a fresh install now pulls
<image>:landingpagefrom the overridden image as well (previously the official landingpage image was used). An overridden image therefore needs alandingpagetag on the registry or a matching preinstalled local image for the fresh install flow. Sinceoverride_imageis an explicit opt-in, the override is applied consistently to all image pulls.Type of change
Additional information
Checklist
ruff format supervisor tests)If API endpoints or add-on configuration are added/changed: