<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 17, 2022 at 3:10 PM Paolo Greppi <<a href="mailto:paolo.greppi@libpf.com">paolo.greppi@libpf.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Jérémy,<br>
<br>
Il 17/03/22 13:26, Jérémy Lal ha scritto:<br>
> ...<br>
> <br>
>     So I ended up installing a gitlab-runner with nspawn-runner and a<br>
>     semi-active server I maintain.<br>
>     I documented the process here:<br>
>     <a href="https://wiki.debian.org/Salsa/Doc/CustomRunners/SystemdNspawnRunner" rel="noreferrer" target="_blank">https://wiki.debian.org/Salsa/Doc/CustomRunners/SystemdNspawnRunner</a><br>
>     <<a href="https://wiki.debian.org/Salsa/Doc/CustomRunners/SystemdNspawnRunner" rel="noreferrer" target="_blank">https://wiki.debian.org/Salsa/Doc/CustomRunners/SystemdNspawnRunner</a>><br>
> <br>
>     salsa's driving that runner to rebuild the thousands of packages now.<br>
>     Minimal build time is 1 minute, so it should take about two days to<br>
>     rebuild the whole.<br>
> <br>
>     After that, anyone knowing gitlab API and <a href="http://bugs.debian.org" rel="noreferrer" target="_blank">bugs.debian.org</a><br>
>     <<a href="http://bugs.debian.org" rel="noreferrer" target="_blank">http://bugs.debian.org</a>> API could help to open FTBFS bugs ?<br>
> <br>
> I started this:<br>
> <a href="https://salsa.debian.org/kapouer/dance" rel="noreferrer" target="_blank">https://salsa.debian.org/kapouer/dance</a> <br>
> <<a href="https://salsa.debian.org/kapouer/dance" rel="noreferrer" target="_blank">https://salsa.debian.org/kapouer/dance</a>><br>
> <br>
> to fetch logs of failed jobs, and also to be able to retry jobs that <br>
> failed because of external reasons<br>
> (runner configuration issue, for example).<br>
> When all jobs are finished, i'll start to use "dance" to send bug reports.<br>
> <br>
> Jérémy<br>
<br>
this is all super interesting. In the past I have done quite a few mass <br>
rebuilds of reverse dependencies using ratt <br>
(<a href="https://salsa.debian.org/debian/doxygen/-/wikis/ratt_doxygen_1.9.1-1_amd64%20partial%202" rel="noreferrer" target="_blank">https://salsa.debian.org/debian/doxygen/-/wikis/ratt_doxygen_1.9.1-1_amd64%20partial%202</a>)<br>
<br>
Your approach is cool because it can be easier to automate.<br>
<br>
To look at pipeline results programmatically I would have used this <br>
Python library:<br>
- <a href="https://packages.debian.org/bullseye/python3-gitlab" rel="noreferrer" target="_blank">https://packages.debian.org/bullseye/python3-gitlab</a><br>
- <br>
<a href="https://python-gitlab.readthedocs.io/en/stable/gl_objects/pipelines_and_jobs.html" rel="noreferrer" target="_blank">https://python-gitlab.readthedocs.io/en/stable/gl_objects/pipelines_and_jobs.html</a><br>
<br>
But I see you plan to use JS for "dance".<br></blockquote><div><br></div><div>I'm just gluing existing solutions together, in js because i don't do python.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Do you intend to trigger the dance from within the pipeline ? You'd then <br>
have a recursive pipeline ... who knows if it will finish in finite time ;-) </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Anyway from my experience:<br></blockquote><div> </div><div>I don't plan to use this as CI, and instead it will only be manually triggered.</div><div>(unfortunately I can't leave that runner open for all, and it would be great</div><div>if some sponsor could dedicate a group of runners for building reverse deps</div><div>using systemd-nspawn which is kind of simple and fast).</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
1. some rdeps reproducibly fail all the time, these should be excluded<br></blockquote><div><br></div><div>Since it's not really Continuous, I don't mind some systematic failures (at least for now).</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
2. ratt rebuilds failed rdeps against the previous version of the parent <br>
package (this filters out false positives), does your job definition do <br>
that as well ? (too lazy to check)<br></blockquote><div><br></div><div>I suppose so, dance is not the one responsible for the schedule of the rebuilds:</div><div>right now the list is generated here and added to its repository:</div><div><a href="https://salsa.debian.org/js-team/nodejs/-/blob/master-14.x/debian/salsa-gen-transition-jobs">https://salsa.debian.org/js-team/nodejs/-/blob/master-14.x/debian/salsa-gen-transition-jobs</a><br></div><div>(with some ci variables to avoid triggering the pipeline by accident)</div><div><br></div><div>I plan to move that script (from Bernd Zeimetz) to "dance".</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
3. some rdeps take much longer to build than others, I ended up creating <br>
lists of "fast" and "slow" rdeps; if you only include "fast" ones your <br>
mass rebuild can run in hours instead of days, but may still be able to <br>
catch regressions<br></blockquote><div><br></div><div>Totally ! I excluded</div><div><div>chromium firefox firefox-esr thunderbird nodejs ffmpeg emscripten</div><div>because they're just too slow to rebuild. Maybe I left some other slow builds.</div></div><div>The quick builds, on the other hand, are very fast (~1 minute). </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
4. I used to create spreadsheets to compare build times and which rdep <br>
failed; for max fun it would be nice to have a database (!) where to <br>
store (stamp, parent_package, old_version, new_version, rdep, status, <br>
duration)</blockquote><div><br></div><div>That kind of information is already somewhere in debian, but how to get it ?</div><div><br></div><div>Jérémy</div><div><br></div><div><br></div></div></div>