-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
helpers: Hack around MEDs/oe-builtin issue #325
Conversation
oe-builtin logic is seeing a CI error like: | Traceback (most recent call last): | File "/script-repo/preload_apps.py", line 14, in <module> | from apps.docker_registry_client import ThirdPartyRegistry | File "/script-repo/apps/docker_registry_client.py", line 18, in <module> | class DockerRegistryClient: | File "/script-repo/apps/docker_registry_client.py", line 19, in DockerRegistryClient | DefaultRegistryHost = 'hub.' + fio_dnsbase() | File "/script-repo/helpers.py", line 123, in fio_dnsbase | parts = urlparse(os.environ["H_RUN_URL"]) | File "/usr/lib/python3.8/os.py", line 675, in __getitem__ | raise KeyError(key) from None | KeyError: 'H_RUN_URL' This is because bitbake isolates the environment that it runs in. There are a couple ways to pass H_RUN_URL in, but they cause a big cache invalidation. The workaround provided here works as long as we don't have a customer on MEDs that does oe-builtin. Signed-off-by: Andy Doan <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That shows that will solve the issue for me 👍
parts = urlparse(os.environ["H_RUN_URL"]) | ||
_, base = parts.netloc.split(".", 1) | ||
return base | ||
run_url = os.environ.get("H_RUN_URL") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could be os.environ.get("H_RUN_URL", "https://api.foundries.io"
) too. Or, os.environ.get("H_RUN_URL",os.environ.get("GIT_URL")
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The giturl but I don't think it gets passed into bitbake does it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably not the case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see it in the bitbake runs.
GIT_URL=https://source.foundries.io/factories/msul-dev01/lmp-manifest.git
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
oe-builtin logic is seeing a CI error like:
| Traceback (most recent call last):
| File "/script-repo/preload_apps.py", line 14, in
| from apps.docker_registry_client import ThirdPartyRegistry
| File "/script-repo/apps/docker_registry_client.py", line 18, in
| class DockerRegistryClient:
| File "/script-repo/apps/docker_registry_client.py", line 19, in DockerRegistryClient
| DefaultRegistryHost = 'hub.' + fio_dnsbase()
| File "/script-repo/helpers.py", line 123, in fio_dnsbase
| parts = urlparse(os.environ["H_RUN_URL"])
| File "/usr/lib/python3.8/os.py", line 675, in getitem
| raise KeyError(key) from None
| KeyError: 'H_RUN_URL'
This is because bitbake isolates the environment that it runs in. There are a couple ways to pass H_RUN_URL in, but they cause a big cache invalidation.
The workaround provided here works as long as we don't have a customer on MEDs that does oe-builtin.