Hi Holger, On Wed, Aug 11, 2021 at 05:12:54PM +0000, Holger Levsen wrote: > Hi Wouter, > > sorry for the late reply but I think it's still relevant... > (just thus rather leaving almost full quote as context.) > > On Thu, Jul 08, 2021 at 11:25:26AM +0200, Wouter Verhelst wrote: > > On Mon, Jul 05, 2021 at 12:31:10PM +0000, Holger Levsen wrote: > > > On Mon, Jul 05, 2021 at 02:09:36PM +0200, Mathieu Parent (Debian) wrote: > > > > > Do you have plans to support publishing builds only if they've > > > > > produced > > > > > bit by bit identical results on several builders? IOW, do you plan to > > > > > support reproducible builds? :) > > > > There is no specific support for reproducible builds. Currently, > [...] > > > > But reproducibility can be tested in GItlab jobs, before the upload. > > > that's nice, but rather theoretic (however common it is today) in > > > practice :) > > > It would be really interesting / a game changer, to have a publishing > > > option > > > which would only allow publishing of builds proven in practice to be > > > identical. > > It's actually fairly easy to do that: > > > > - Create two runners, with different tags (e.g., one tagged "build1", > > and one tagged "build2"). One can be a docker runner, the other a > > shell runner, just to keep things interesting. > > - Create two jobs that build the same source in ways that might trigger > > reproducability issues (I'm sure you're better at this than me). Make > > sure that they don't store their artifacts in the same location (e.g., > > one job runs "dcmd mv ../*.changes products/build1/", and the other > > one does "dcmd mv ../*.changes products/build2/"). > > - Have a third job that depends on both the above two jobs, and that > > runs diffoscope over the artifacts of both jobs. If and only if the > > diffoscope doesn't reveal any issues, run dput to upload the packages. > > > > I think the salsa-CI team can easily add support for this to their > > generic pipeline... > > that would be really nice, thank you for explaining this idea so well! > > just one thing: here we do *not* want to trigger reproducibility issues, > rather the opposite: if we manage to do two builds resulting in exactlty > the same .deb(s), we are happy.
Yes, of course -- I didn't mean to say "you should make it fail", but rather "I'm sure you know of ways in which it commonly fails that we want to protect against". > because here, our focus would be to publish things :) Sure. But also to find problems early rather than late, no? -- w@uter.{be,co.za} wouter@{grep.be,fosdem.org,debian.org}