Skip to content

Conversation

@eshattow
Copy link
Contributor

@eshattow eshattow commented Nov 14, 2025

Use context github.repository_owner instead of hard-coded "home-assistant" namespace in action.yml . This resolves one of the friction points for being able to clone the repo somewhere else on GitHub and run the actions outside of home-assistant org.

Edit: Have updated this to take a slightly different approach where a "namespace" output is defined and is conditionally dependent on when github.repository_owner is valid for run and pull of image to build from. The use of a hard-coded value "home-assistant" is now configurable.

@eshattow eshattow marked this pull request as draft November 15, 2025 02:30
@eshattow eshattow force-pushed the actions-use-repositoryowner branch from 58f8c07 to c7e5936 Compare November 16, 2025 19:58
@eshattow eshattow marked this pull request as ready for review November 16, 2025 20:01
@agners
Copy link
Member

agners commented Nov 19, 2025

Thank you for your PR.

Will that work well with the version? Afaik it takes the tag from the current repository, which will be outdated quickly as well in clones.

Maybe it would be better to simply rely on ${{ github.repository_owner }}, and create an actual release in forks which pushes a container to the forked repo 🤔

@eshattow
Copy link
Contributor Author

Will that work well with the version? Afaik it takes the tag from the current repository, which will be outdated quickly as well in clones.

I've only tested that it builds in GitHub actions on a fork with drafting a published release version, and then again which uses that published version's image of the fork there to build for that second iteration. It will be whatever is the available published version image for that namespace (fork).

Maybe it would be better to simply rely on ${{ github.repository_owner }}, and create an actual release in forks which pushes a container to the forked repo 🤔

Yes, and in either case depends on home-assistant namespace anyways for the initial base image, which is less than ideal. This is a good conversation starter for how to make it easier to fork and contribute back with changes that can be tested outside of home-assistant namespace.

How was the original builder image formed if there's no base builder image? I think that instead of switching "home-assistant" in and out that there should simply be a generation of the image, but as it is with chicken-and-egg problem we depend on the image to create the image.

I don't know what is correct for generating this image without having an existing image (i.e. from "home-assistant") to build with. I think of this as a first step to identifying the minimum needed changes just to get any successful result. If no valid published image is found (the namespace owner for whatever reason cannot accept published images) then this at least results in a fall-back to the "home-assistant" namespace for the base image to build with. I think that may be desirable in the near-term.

I'm okay with either approach but I don't have enough knowledge about what direction you'd like to go with this to make an implementation of building the original initial base image.

@eshattow eshattow force-pushed the actions-use-repositoryowner branch from 000a1bf to 3b22148 Compare November 21, 2025 21:25
…repository_owner

Hard-coded "home-assistant" is now configurable and used as a fallback when the
context github.repository_owner is not valid for the image to pull or run from.
@eshattow eshattow force-pushed the actions-use-repositoryowner branch from 3b22148 to 651c3ee Compare November 21, 2025 23:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants