yea, i'd like to build locally too... i'd kinda like to get the workflows setup so theyd run on eith
yea, 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
Bthat's not opinionated at all 
Aeg: buildah action is really just
buildah bud./build.shi like the workflows, seems nice to use them in both places
Bgit and gitea
AFor github actions or gitea or gitlab, etc
AGitea will never be 100% compatible with github actions
Bobviously i agree one can more quickly make a script to do it, but you might be surprised how far act and act_runner have come.
Achasing the subset of stuff supported by gitea and github actions seems like a loosing battle full of "it works on GH but not here"
ASpecially as you import third party actions that will very likely not support gitea actions
AAnd 1:1 compatibility seems like a non-goal:
However, we recommend using gitea.xyz in case Gitea adds something that GitHub does not have to avoid different kinds of secrets in your workflow file (and because you are using this workflow on Gitea, not GitHub). Still, this is completely optional since both options have the same effect at the moment.
Xcould be possible to write a localbuild.sh script or smth for startingpoint in the future, since a barebones build.yml is actually pretty simple if you strip adding the container metadata labels and stuff. the only thing i don't know anything about is rebasing to local images.
Xthought that's obviously way less comprehensive than forge or gitea
AIt just needs a single podman/buildah command to build
AThen rebasing to a local container and then there's nothing special that needs to happen
AI'm running on a local image for about a week
AIt requires around 3x the disk space as the image is stored in multiple places during the process
Weh
Whonestly
Wforge sounds like it has the guts
WI am not biased towards any one solution, as long as its open source, I'm happy
WThe one thing I think would be reasonable to do from something like gitlab/gitea is "when a push happens, build the image"
Weven if that's just like an http webhook to forge to say "go do the thing"
J