Skip to content
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

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

Closed
xynydev opened this issue Apr 2, 2023 · 11 comments
Closed

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

xynydev opened this issue Apr 2, 2023 · 11 comments
Labels
type: feature Brand new functionality, features, pages, workflows, endpoints, etc.

Comments

@xynydev
Copy link
Member

xynydev commented Apr 2, 2023

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

@xynydev
Copy link
Member Author

xynydev commented Apr 4, 2023

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
Copy link
Member Author

xynydev commented Apr 22, 2023

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
Copy link

tunix commented Apr 25, 2023

#34 seems to be closed?

@castrojo
Copy link
Contributor

This should have covered it: ublue-os/isogenerator@111381f

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

@xynydev xynydev added the type: feature Brand new functionality, features, pages, workflows, endpoints, etc. label May 2, 2023
@xynydev xynydev changed the title feat: iso build feat: iso build ["1.0" GOAL] May 14, 2023
@xynydev
Copy link
Member Author

xynydev commented May 14, 2023

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 xynydev pinned this issue May 16, 2023
@xynydev
Copy link
Member Author

xynydev commented Aug 4, 2023

#133

@lorduskordus
Copy link
Contributor

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
Copy link
Member Author

xynydev commented Aug 5, 2023

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

@lorduskordus
Copy link
Contributor

lorduskordus commented Aug 5, 2023

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
Copy link
Member Author

xynydev commented Aug 6, 2023

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
Copy link
Member Author

xynydev commented Aug 8, 2023

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?

@xynydev xynydev closed this as completed Aug 8, 2023
@xynydev xynydev unpinned this issue Aug 9, 2023
b- pushed a commit to briorg/server that referenced this issue Oct 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: feature Brand new functionality, features, pages, workflows, endpoints, etc.
Projects
None yet
Development

No branches or pull requests

4 participants