Closed xynydev closed 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.
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.
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.
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.
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.
Good catch, we should add version tags to startingpoint. We probably wont change the tag the ISO pulls.
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.
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.
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?
Bluefin recently got ISO builds and there's progress on that. An ISO build action should be added to be created when needed.