and I'm also biased to as few additions to main as possible
and I'm also biased to as few additions to main as possible
Bthat's been a learned bias though, as I more and more see main as the foundation of a toolkit, and... anything added is difficult/impossible to remove downstream
JI wouldn't say it's a bias, that's just how you're supposed to do it. 
WWhat is the status of Forge? I was listening to a podcast yesterday that was talking about Gitea beginning the process of trying to 1:1 github actions and it made me think "huh, I wanna have my ublue running entirely self hosted, maybe this'll work"
Whttps://docs.gitea.com/next/usage/actions/overview I'd love to look into it, and maybe help push forge along if it fits
Starting with Gitea 1.19, Gitea Actions are available as a built-in CI/CD solution.
Jsomeone needs to try it and see if it works.
WI'm down. On the "vision" I won't be doing 4 though
PXE boot the clients, select ublue in the menuWso this looks like it'd be deployed via podman cluster?
Wok, so ucore VM
WReally I just want to in house my image creation
Jit should run on any linux with podman or docker iirc
WIs it a single container? Cause if so, I'll just attempt to throw it in the mix on unraid
Wif its orchastrating multiple containers I may throw a VM at it for testing
JGitHub
On-prem Universal Blue. Contribute to ublue-os/forge development by creating an account on GitHub.
Jit's a few
Wyea, I'll just spin up a VM to test it in
Wkeep it contained
BI use gitea for git and their actions with act_runner for CI builds and as a container registry...
i can tell you that the buildah actions we use today don't work on act_runner, but could almost certainly be swapped out for docker's builder action (and still probably run against podman, if you like)
i can tell you that the buildah actions we use today don't work on act_runner, but could almost certainly be swapped out for docker's builder action (and still probably run against podman, if you like)
WHonestly if Forge does what it advertises (and if it doesn't, I bet its way further along than me starting from scratch) I think its probably the better starting point than trying to slam gitea in
W¯\_(ツ)_/¯
Wbut that conversation made me really curious to get it all building locally
WEspecially since I'll have multiple machines on the same image, save internet bandwidth
Whave it build locally then distribute to the entire house
Byea, i'd like to build locally too... i'd kinda like to get the workflows setup so theyd run on either github or gitea if possible
Bthis is related
BI saw an interesting post by Walters today: https://github.com/coreos/fedora-coreos-tracker/issues/1263#issuecomment-1680999863
The important line is:
Got me thinking, having frequent upgrades of ucore/ublue is great, but the best way to gate them is to install from a local mirror, and then I choose when I want to sync the mirror with ghcr... it not only provides a buffer between build and install, but saves bandwidth for those are are running ublue/ucore on multiple systems.
The important line is:
[Users can] mirror the OS update containers on their own to a registry and update it on their own timeframe and schedule. Which is what they already need to know how to do for application containers!the context is replacing zincati/simplifying its function and instead of having complexity, managing things in a better way.
Got me thinking, having frequent upgrades of ucore/ublue is great, but the best way to gate them is to install from a local mirror, and then I choose when I want to sync the mirror with ghcr... it not only provides a buffer between build and install, but saves bandwidth for those are are running ublue/ucore on multiple systems.
Wyea, read that
Bso, even if building in github, could just mirror to a local container registry
WMy inclination, at least with some of this, is to get it off of github
WPersonally I don't love the idea of "hey, my entire system configuration is in a public repo"
Wthe tradeoffs right now are totally in the "worth it" camp, but if I can help get it to where its entirely onprem I'll happily be a guinea pig.
Wreally dumb question... how large are these images? Like I'm looking at one of the images on github and for the life of me it doesn't show a filesize.
Btotal size is around 6GB depending which variant and nvidia or no
Byou can just
podman pull an image to seeWah, larger than I thought.
WNot huge though.
Band really most of the work I do for ublue involves locally running
podman build Containerfile from our various repos with different build argsBusually only the github workflows themselves need to be in github for testing
Wat ~6gb, to replicate github's 90 day retention, that's about a half a TB per image
Wouch
WI'd probably cut back a bit
Wone of the things I've been thinking of doing, which is really dumb, is to do a local cached repo for dnf, then once you have that, in theory you could build N images on the fly from from it, but that sounds like hyper-overkill
BI am spoiled with fast internet now, and i've already considered caching container registries and DNF repos, etc...
but I may be moving somewhere with much restricted internet... if so, it'll be imperative to figure that out
but I may be moving somewhere with much restricted internet... if so, it'll be imperative to figure that out
Jtransparent inhouse registry would be dope, I filed an issue for that in the website repo.
Wbut yea, baby steps, for now Imma test forge
Wif not tonight, then maybe this weekend
Wmy setup at home is unraid, and it has some oddities when it comes to docker, you wanna know going in its templated for unraid
Wso I'll just setup a ucore VM
Wto remove that from the oddities
Wif I get it setup there, maybe I can tweak it a bit to template it for unraid
AIf you want that the best is to avoid github actions and just scripts
