-
Notifications
You must be signed in to change notification settings - Fork 21
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
Introduce a ObsPackage class for grouping Container Images #1815
base: main
Are you sure you want to change the base?
Conversation
Created a staging project on OBS for 16.0: home:defolos:BCI:Staging:16.0:16.0-1815 |
Created a staging project on OBS for 5: home:defolos:BCI:Staging:SLE-15-SP5:5-1815 Build ResultsRepository
Repository
Repository
Repository
Repository
Repository
Repository
Repository
Build succeeded ✅ To run BCI-tests against this PR, use the following command: OS_VERSION=15.5 TARGET=custom BASEURL=registry.opensuse.org/home/defolos/bci/staging/sle-15-sp5/5-1815/ tox -- -n auto The following images can be pulled from the staging project:
|
Created a staging project on OBS for 7: home:defolos:BCI:Staging:SLE-15-SP7:7-1815 |
Created a staging project on OBS for 6: home:defolos:BCI:Staging:SLE-15-SP6:6-1815 |
Created a staging project on OBS for Tumbleweed: home:defolos:BCI:Staging:Tumbleweed:Tumbleweed-1815 Build ResultsRepository
Repository
Repository
Repository
Build failed ❌ To run BCI-tests against this PR, use the following command: OS_VERSION=tumbleweed TARGET=custom BASEURL=registry.opensuse.org/home/defolos/bci/staging/tumbleweed/tumbleweed-1815/ tox -- -n auto The following images can be pulled from the staging project:
|
@@ -1479,7 +1484,7 @@ def generate_disk_size_constraints(size_gb: int) -> str: | |||
|
|||
SORTED_CONTAINER_IMAGE_NAMES = sorted( | |||
ALL_CONTAINER_IMAGE_NAMES, | |||
key=lambda bci: f"{ALL_CONTAINER_IMAGE_NAMES[bci].os_version}-{ALL_CONTAINER_IMAGE_NAMES[bci].name}", | |||
key=lambda bci: f"{ALL_CONTAINER_IMAGE_NAMES[bci].os_version}-{ALL_CONTAINER_IMAGE_NAMES[bci].uid}", |
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 change seems unrelated?
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.
It is required, because ObsPackageBase
doesn't have a name
property
|
||
async def _write_service_file(self, dest: str) -> list[str]: | ||
await write_to_file(os.path.join(dest, "_service"), self._service_file_contents) | ||
return ["_service"] |
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 return value seems unused? since it should end up in the files list anyway..
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.
It is used here:
return [f for file_list in await asyncio.gather(*tasks) for f in file_list] |
There's at least 3 refactorings in this PR which makes it really hard to review. the osversion -> os_version rename, the service jinja to class refactoring and the change of the containercrate to ObsPackage refactoring. any chance to split the first two out so that it is easier to see what the rest is about? this is a 1000 lines diff over 11 commits. personally I don't really like the Base in the name also, why is there "magic" to collate up the services, but no magic to collate up the build flavors? instead they have to be set explicitly in multiple list entries (so whenever we add or remove a os_version that has different build flavors, the whole shebang needs to be duplicated)? Its such an implementation detail, it should be hidden the same way like services imho. |
af79acf
to
f843b5d
Compare
I've renamed the classes as you suggested,
Hm, I don't fully understand what pain point that this should solve though? |
Overall LGTM, seems to clean up the code a bit. I am not a big fan of the name |
This is pretty much a re-implementation of #1755, with more code but an API that I personally like a bit more, because it is more explicit:
This required the introduction of another base class
ObsPackageBase
from which bothObsPackage
andBaseContainerImage
inherit. The API is not yet great, as there's now a bit of duplication going on, if you stuff a BCI into aObsPackage
, but I wanted to get some feedback first.