then renovate can figure out when timothee releases F43, we can be in bed!
then renovate can figure out when timothee releases F43, we can be in bed!
RThat's one thing we can't do... Renovate gets really confused with Fedora versions, and tries to bump to the rawhide version
JNoooooooooooooo
Jhey, it can monitor RPMs right? renovate?
RIf the package is in repology or versions match up with GitHub, yes
Jlike do you think we can do a thing where we can watch the vscode RPM and kick off a build for dx then?
Jwas thinking this could help fix that annoyance. 
RNot sure if it would work with VSCode since it's not in any normal repos
RBut vscode being a day old is no big deal IMO. We've disabled the update pop-ups already, and there's hardly ever any new features you will want immediately.
Jtrue
RSorry about the hundreds of PRs 
JLOVE IT
Jantheas will not love it in countme hahaha
Ti wonder how deep we could customize renovate
J
JThis is awesome!!!!!!
Jautomatic
Jwhenever @Carl George gets us a new image, we kick off a build.
Ti think they do that on centos-bootc :)
Tthats really nice
JLike, that build is just automated now
Jman dude if we could go cron-less across the board and just build when the stuff actually needs to be built
JHow many hours have we spent after fixing something in akmods to then babysit the build, so we can click main to rebuild, and then click the downstream images. Hours.
TYESYESDYES
Rhttps://github.com/ublue-os/main/pull/792
Starting on this
Won't be ready to merge today, but making a start
Starting on this
Won't be ready to merge today, but making a start
GitHub
Thank you for contributing to the Universal Blue project!
Please read the Contributor's Guide before submitting a pull request.
Please read the Contributor's Guide before submitting a pull request.
Jok even the old ones huh?
RThe YAML isn't the cleanest, but it's not meant to be maintained by people
Jright
RMight as well. It's easier to roll it out across the board than build in the logic to exclude older images
JI met the creator of yaml in london
Jok so question
Jlet's say you fix something on akmods
Jbut some of the builders go red or we get a dud that takes a while.
Jis there a chance that the downstream bot could accidentally do it twice.
Jlike main rebuilds but then the matrix finishes like 10m later or something then would it try to rebuild all of main again?
RYou mean the merge queue builds and pushes an image, but other images fail so the merge queue is cancelled and reran?
Jok so let's say silverblue, kinoite, and base-main for three examples.
Jbot fires off, automerges
Jthey all rebuild.
Jbut say kinoite is red or something.
Jso bazzite sees silverblue updates, and also automerges and builds
Jbut it's behind on kinoite now
Jthough I guess we'll just see how it works, I am overthinking it
RNo, you're right. That could happen...
RThere's a few things we could do.
JI know we're getting rid of it, but basically with a huge matrix like hwe has
JI can see renovate PRing a downstream like 3 times given the churn or something.
Ti think we should gate it behind the merge queue
Tso it wont get automerged if it fails to build
RWe can stop the merge queue from pushing to the "production" tags (latest, stable etc), and re-tag the merge-queue builds as those prod tags in the push trigger.
So:
So:
- Merge queue builds all images, pushes to merge-queue only tags
- Push trigger re-tags merge queue tags with production tags
Jit does, it PRs and if checks fail it doesn't merge
