<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 17, 2021 at 8:32 PM Alex Rousskov <<a href="mailto:rousskov@measurement-factory.com">rousskov@measurement-factory.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">On 5/17/21 2:17 AM, Francesco Chemolli wrote:<br>
<br>
> Our Linux environments are docker containers on amd64, armv7l and arm64.<br>
> On a roughly monthly cadence, I pull from our dockerfiles repo<br>
> (<a href="https://github.com/kinkie/dockerfiles" rel="noreferrer" target="_blank">https://github.com/kinkie/dockerfiles</a>) and<br>
> $ make all push<br>
<br>
Does that "make push" command automatically switch Jenkins CI to using<br>
the new/pushed containers? Or is that a separate manual step?<br></blockquote><div><br></div><div>Right now that's automatic.</div><div>I'm pondering the best way to have a staging step; Docker supports versioning of images but we're using that feature to implement multiarch. In order to rely on that I'll need to change the naming conventions we rely on.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>>> What I would place on each individual dev is the case where a PR breaks<br>
>>> something in the trunk-matrix,trunk-arm32-matrix, trunk-arm64-matrix,<br>
>>> trunk-openbsd-matrix, trunk-freebsd-matrix builds<br>
<br>
>> I think you are saying that<br>
>> some CI tests called trunk-matrix, trunk-arm32-matrix,<br>
>> trunk-arm64-matrix, trunk-openbsd-matrix, trunk-freebsd-matrix should be<br>
>> classified as _required_.<br>
<br>
> That is how I read the statement too.<br>
<br>
... but it sounds like that is _not_ what you (Francesco) is actually<br>
proposing because you are essentialy saying "that ideal would be<br>
impractical" in the paragraph below. Assuming that you are not attacking<br>
your own proposal, that means Amos and I do not know what your proposal<br>
is -- we both guessed incorrectly...<br></blockquote><div><br></div><div>The overarching objectives are:</div><div>- focus on where most users probably are</div><div>- allow iterating quickly giving some signal on tracked branches</div><div>- allow landing quickly with more signal</div><div>- be slow but exhaustive on every other platform we can cover. Do not block landing new code on less common or harder to test on platforms, but still rely on devs to own their changes there, too.</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">
> In a word of infinite resources and very efficient testing, sure.<br>
> But in a space where a single os/compiler combo takes 2hrs on Linux and<br>
> 4hrs on Freebsd or openbsd, and a full 5-pr-test takes 6 hours end to<br>
> end, we need to optimize or making any of these requirements blocking<br>
> would make these times get 4+ times larger (a full trunk-matrix takes<br>
> just about a day on amd64, 2 days on arm64), and the complaint would<br>
> then be that development or release is slowed down by the amount of<br>
> testing done.<br>
<br>
FWIW, I think that full round of PR tests (i.e. one initial set plus one<br>
staging set) should not exceed ~24 hours, _including_ any wait/queuing<br>
time. This kind of delay should still allow for reasonable progress with<br>
PRs AFAICT. This includes any release PRs, of course. If we exceed these<br>
limits (or whatever limits we can agree on), then we should add testing<br>
resources and/or drop tests.</blockquote><div><br></div><div>Is everyone okay with such a slow turnaround?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> My proposal aims to test/land the PR on the systems where we can be<br>
> efficient and that are relevant, and fix any remaining after-the-fact<br>
> issues with followup, PRs, that remain a soft requirement for the dev<br>
> introducing the change.<br>
<br>
Here, I think you are proposing to make some tests optional. Which ones?<br></blockquote><div><br></div><div>Not the tests, but the platforms. Things like gentoo, fedora rawhide, freebsd, openbsd.</div><div>Testing is slower there, so results will lag and we need to batch, running a full test suite every week or so</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> For instance: we currently have a lot of different build-time<br>
> configurations meant to save core memory in runtime environments. Is it<br>
> maybe time to revisit this decision and move these checks to run time?<br>
<br>
Sure, quality proposals for removing #ifdefs should be welcomed, one<br>
(group of) #ifdefs at a time. We can warn squid-users in advance in case<br>
somebody wants to provide evidence of harm.<br></blockquote><div><br></div><div>I'm glad this is having buy-in. Are there any other opinions (for or against)?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> Unfortunately, one of the problems we have is that we're running blind.<br>
> We don't know what configurations our users deploy; we can only assume<br>
> and that makes this conversation much more susceptible to opinions and<br>
> harder to build consensus on<br>
<br>
Yes, we are blind, but I doubt we should care much about actual<br>
configuration in this specific context. If we can remove an #ifdef<br>
without serious negative consequences, we should remove it. We can avoid<br>
long discussions by allowing anybody with concrete evidence of problems<br>
to block any particular removal. I bet that conservative approach would<br>
still allow for the removal of many #ifdefs.<br></blockquote><div><br></div><div>Sounds good to me </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">
FWIW, I do not think reducing the number of #ifdefs will solve our<br>
primary CI problems. I believe we should reduce the number of platforms<br>
we test on and then use Foundation resources to speed up and improve the<br>
remaining tests.<br></blockquote><div><br></div><div>Each test build is right now 4 full builds and test suites:</div><div>autodetected, minimal, maximum, everytthing-in-except-for-auth</div><div><br></div><div>Can we reduce them to 2? If so, which ones? that would be the guide to #ifdef removal</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
HTH,<br></blockquote><div><br></div><div>It does; thanks</div><div><br></div></div></div>