ChanServ changed the topic of #freedesktop to: https://www.freedesktop.org infrastructure and online services || for questions about freedesktop.org projects, please see each project's contact || for discussions about specifications, please use https://gitlab.freedesktop.org/xdg or xdg@lists.freedesktop.org
ngcortes has quit [Remote host closed the connection]
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
ximion has quit []
danvet has joined #freedesktop
<hakzsam>
it seems I don't get any Gitlab email notifications, is it broken on my side or is it a fdo issue?
<daniels>
oh damnit
<daniels>
hakzsam: thanks for letting us know
<hakzsam>
np
<hakzsam>
it's back, thanks!
<daniels>
np :)
MajorBiscuit has joined #freedesktop
AbleBacon has quit [Read error: Connection reset by peer]
thaller has quit [Read error: No route to host]
thaller has joined #freedesktop
MajorBiscuit has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #freedesktop
ximion has joined #freedesktop
<MrCooper>
emersion: needlessly building an image when there already is one is not only wasteful, it can also break the pipeline, e.g. due to pulling in newer packages from the base distro
<emersion>
shrug
<emersion>
most other CI systems just start from a blank image for each build
<emersion>
e.g. GitLab CI if you keep it simple, GitHub actions, builds.sr.ht, etc
<emersion>
the only reason why i care about not starting from scratch each build is to save the scarce fdo resources
<pq>
caching images and not rebuilding randomly them is much better indeed
<emersion>
it's an unnecessary optimization in most cases
<pq>
not just the huge time savings, but repeatability as well
<emersion>
my CI is pretty quick without image caching
<emersion>
usually it takes 30s
<pq>
that's pretty long, if that's just the image prep? I mean, in thinking of terms of CI turnaround. Shaving 25s off would be big.
<pq>
going forward, we are likely going to need pre-release VKMS at times
<emersion>
(and as you can see, the whole smoke test setup is maybe 10 lines of shell script long, compare that to weston's complicated setup)
<emersion>
but yeah, for a project like weston where linux and other deps get built, it makes sense to cache
<pq>
the first show-stopper is "sudo modprobe"
<emersion>
oh yeah this is def not going to work with docker-based CIs
<emersion>
not suggesting to copy-paste anything here
<emersion>
just saying that fdo is too complicated
<pq>
how would you make it simpler?
<daniels>
it's too complicated in the same way that wlr is too simple :P
<daniels>
both are valid, just different tradeoffs
<daniels>
pinning your deps and managing your own VMs (if you need them) means you don't have to eat checksum differences when llvmpipe gets upgraded, or have every pipeline go red when your compiler gets upgraded and emits new warnings, or go fix every project to have it retry on package-download fails because distro CDNs are surprisingly flaky, or maintain a single 'known-good' kernel image for every project on your infra, or have test
<daniels>
results vary as you bisect back, or
<MrCooper>
pq: each docker image built by current ci-templates has labels pointing to the job which built it
<pq>
MrCooper, gitlab does not list the labels for me.
<pq>
MrCooper, or any image tags from the registry, the web page just stop loading eventually and shows nothing.
<MrCooper>
right, probably need to use skopeo or something
<emersion>
daniels: all of these things are stuff users will hit. it's a good thing to hit them in CI so that the issues can be fixed earlier
<daniels>
for simple things, sure
<pq>
sounds like another trade-off depending on what kind of users you have - ideally you'd run *both* kinds of CI: with known-good image and with "live image".
<daniels>
yeah
<pq>
libinput might be doing something like that?
<pq>
IIRC it's running at least on a dozen different distros
<daniels>
but yeah, by the time you get up to testing zink on venus on llvmpipe where your test results (which aren't binary pass/fail but like 70k individual tests as well as checksummed rendering traces) depend on all of zink + mesa-venus + virtio-gpu + crosvm + virglrenderer + host lavapipe + host LLVM, it's not really practical to just YOLO the entire setup in 10 lines
<emersion>
complicated CI for complicated projects is fine
<emersion>
complicated CI for simple projects is annoying
<pq>
both projects and CI tends to grow more complicated over time, so if we're talking about libdisplay-info here, I'd take the hit of libwayland-level complicated CI from the start, since it's likely we are going to want to add e.g. freebsd at some point.
<daniels>
no disagreement; equally, another consideration is that sharing conventions is nice, but having to walk into another person's bespoke recreation of what's already there is jarring and time-consuming
<emersion>
it depends
<daniels>
none of those are slam-dunk argument-ending points, all just different axes
<emersion>
a simple GitLab CI manifest is pretty standard
<emersion>
arguably, fdo's ci-templates is pretty non-standard in the larger GitLab ecosystem
<emersion>
pq, nah, not talking about any particular project here. libdisplay-info already has cached images
<pq>
oh, good
<emersion>
although i'd prefer to avoid things like manifest templating with python
<emersion>
which is another… interesting custom fdo thing
<daniels>
yeah, no argument that the template-generation is pretty overkill
<daniels>
and hopefully obviated by the YAML now natively supporting matrix configs
<emersion>
ah, nice!
<daniels>
(you'll note that neither Mesa nor Wayland uses the generator)
<emersion>
inded, pretty happy about that :P
<pq>
nor weston
<MrCooper>
pq: I'd argue "live image" should only be used for scheduled pipelines, not for pre-merge ones
<MrCooper>
scheduled pipelines like that can serve as heads up for new issues
<pq>
indeed
GNUmoon has joined #freedesktop
ximion has quit []
GNUmoon has quit [Remote host closed the connection]