blue-build / legacy-template

Starting point for making your own OS image
Apache License 2.0
127 stars 180 forks source link

feat: iso build ["1.0" GOAL] #12

Closed xynydev closed 1 year ago

xynydev commented 1 year ago

Bluefin recently got ISO builds and there's progress on that. An ISO build action should be added to be created when needed.

xynydev commented 1 year ago

The action here https://github.com/ublue-os/main/blob/main/.github/workflows/release-please.yml seems pretty simple to understand, I figure just small modification would be enough. I don't know whether it is wise to add this already, as F38 isn't that stable yet.

Another consideration is a possible post-script for Nvidia ISO's. That would either need to be added programmatically, or by the user.

xynydev commented 1 year ago

https://github.com/ublue-os/isogenerator is the secret sauce, just gotta wait for #34 to merge and I think we're good to start implementing this.

tunix commented 1 year ago

34 seems to be closed?

castrojo commented 1 year ago

This should have covered it: https://github.com/ublue-os/isogenerator/commit/111381f493c913aaddbc82801ab1f0bacbc8deeb

Following the README in the isogenerator repo should work now for your repo.

xynydev commented 1 year ago

I'm setting this as a goal to be achieved before a future release, as I view it as an important (read: flashy) feature for a user to be able to click click create their own image and very easily install it directly on real hardware (or a vm) the same day.

xynydev commented 1 year ago

133

lorduskordus commented 1 year ago

I don't know if it's known and being worked on, or just an issue on my side, but the installer always wants to pull any image with the :38 tag, so if one has recipe with 'fedora-version: latest' for example, the installer throws an error as the :38 image doesn't exist. Otherwise it works as it should.

xynydev commented 1 year ago

Good catch, we should add version tags to startingpoint. We probably wont change the tag the ISO pulls.

lorduskordus commented 1 year ago

Would still be an issue for someone doing 'fedora-version: 37' though, as one previous version of Fedora is supported. Or the next version, 39, once it's beta, if uBlue creates those images. Then there also could be a case of multiple recipes with different versions.

Ideally the ISO should get the version from the recipe. Or just fail to build if the version of any recipe doesn't match what's considered latest.

xynydev commented 1 year ago

Would still be an issue for someone doing 'fedora-version: 37' though

ISOs don't (and never did) support F37, I can put that in the docs too. You can change the installer-major-version in the GHA which should probably change the image version that is pulled.

The reason no data is automatically ingested from the recipe is because we'd need it in the boot_menu.yml for it to work, and I didn't want to look into automatically generating the file.
The installer-major-version could be tied to a recipe, but then the recipe would have to be separately specified in the ISO action. I think a better direction for that is to just document what you need to change in the action to change the version.

xynydev commented 1 year ago

This should be done now #134. I'm not doing a release yet, I'm seeing where #103 goes and we'll figure it out. I don't know if it makes sense to do a "1.0" release if the whole thing would be rewritten afterwards so a pre-release could be the direction to go?