<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div class=""> Now stage 2 has a failed job, will no more jobs in stage 3 be started? </div></div></blockquote>Honestly, I’m not sure. According to these stale MR's <a href="https://gitlab.com/gitlab-org/gitlab/-/issues/30476" class="">https://gitlab.com/gitlab-org/gitlab/-/issues/30476</a> , <a href="https://gitlab.com/gitlab-org/gitlab/-/issues/23605" class="">https://gitlab.com/gitlab-org/gitlab/-/issues/23605</a> this question has been raised before. As per <a href="https://gitlab.com/gitlab-org/gitlab/-/issues/30476#note_215843706" class="">https://gitlab.com/gitlab-org/gitlab/-/issues/30476#note_215843706</a> It seems like the only way to cull the whole pipeline on failure is to add a “after_script” to every job which conditionally kills the pipeline if the job fails.<div class=""><br class=""><div class="">
<div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div>Best regards,<br class=""><br class="">Jacob Faibussowitsch<br class="">(Jacob Fai - booss - oh - vitch)<br class="">Cell: (312) 694-3391</div></div>
</div>
<div><br class=""><blockquote type="cite" class=""><div class="">On Jul 6, 2020, at 2:47 PM, Barry Smith <<a href="mailto:bsmith@petsc.dev" class="">bsmith@petsc.dev</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><br class=""></div> This sounds like a good idea but is confusing to me.<div class=""> </div><div class=""> We use stages so if anything fails in stage 2 we don't waste compute time on anything in stage 3 or higher. </div><div class=""><br class=""></div><div class=""> If one uses this needs how does that affect this? Will it run everything to the end despite failures in earlier stages or will it stop any more higher stage jobs from starting if there is a failure on a stage? So for example stage 2 is running and because of needs job x of stage 3 starts. Now stage 2 has a failed job, will no more jobs in stage 3 be started? </div><div class=""><br class=""></div><div class="">Ideally if anything fails in stage 2 it kills the jobs started in stage 3 but I guess it doesn't do that.</div><div class=""><br class=""></div><div class=""> Barry</div><div class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Jul 6, 2020, at 1:15 PM, Jacob Faibussowitsch <<a href="mailto:jacob.fai@gmail.com" class="">jacob.fai@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div class="">If we did this in the pipeline they could be significantly faster</div></div></blockquote>We might also consider not locking _all_ stage n+1 jobs behind completion of stage n. Gitlab supports this via the “needs” command <a href="https://gitlab.com/help/ci/yaml/README.md#needs" class="">https://gitlab.com/help/ci/yaml/README.md#needs</a> which allows you to run jobs immediately after their prerequisite jobs have finished regardless of stage. For example, I find that I am quite often waiting on stage 2 freebsd jobs to start in order to advance to stage 3, even after every other stage 2 job has run its course. <div class=""><div class=""><br class=""><div class=""><div class="">
<div dir="auto" style="caret-color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">Best regards,<br class=""><br class="">Jacob Faibussowitsch<br class="">(Jacob Fai - booss - oh - vitch)<br class="">Cell: (312) 694-3391</div></div>
</div>
<div class=""><br class=""><blockquote type="cite" class=""><div class="">On Jul 6, 2020, at 12:47 PM, Barry Smith <<a href="mailto:bsmith@petsc.dev" class="">bsmith@petsc.dev</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><br class=""></div> We should be more clever than checking just examples but also check source code. If, for example, only KSP is changed then tests could skip the sys/vec/mat levels saving time.<div class=""><br class=""></div><div class=""> If we did this in the pipeline they could be significantly faster; all the time saved not testing sys to mat for Matt's changes :-)</div><div class=""><br class=""></div><div class=""> Is there a fallacy here?</div><div class=""><br class=""></div><div class=""> Barry</div><div class=""><br class=""></div><div class=""> Need to check changes in include files as well, of course.</div><div class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Jul 6, 2020, at 12:13 PM, Jacob Faibussowitsch <<a href="mailto:jacob.fai@gmail.com" class="">jacob.fai@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">While were on this topic, I always parse git diff —name-only $(git merge-base —fork-point master) when testing. This gives you all the files that are different between your branch and master. You can switch it out for maint if needs be.<div class=""><br class=""><div class="">
<div dir="auto" style="caret-color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">Best regards,<br class=""><br class="">Jacob Faibussowitsch<br class="">(Jacob Fai - booss - oh - vitch)<br class="">Cell: (312) 694-3391</div></div>
</div>
<div class=""><br class=""><blockquote type="cite" class=""><div class="">On Jul 6, 2020, at 12:00 PM, Barry Smith <<a href="mailto:bsmith@petsc.dev" class="">bsmith@petsc.dev</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class="">I couldn't see how Jed can avoid doing the filename hacking since alltesttargets are the hacked filenames but probably I am missing something. <br class=""><br class=""> Anyways this patch works for me based on Jed's email.<br class=""><br class=""> Barry<br class=""><span id="cid:597D9B43-C0CA-4310-8E5E-F892A58B75CF" class=""><since.patch></span><br class=""><br class=""><blockquote type="cite" class="">On Jul 6, 2020, at 9:40 AM, Jed Brown <<a href="mailto:jed@jedbrown.org" class="">jed@jedbrown.org</a>> wrote:<br class=""><br class="">It'd be possible to hack the file names, but I'd rather not duplicate that logic.<br class=""><br class="">My inclination would be to filter similar to argsearch, which requires<br class="">adding the source files to testfiles. Then you could use<br class=""><br class=""> make test since=@<br class=""><br class="">ifdef since<br class=""> gitchanged := $(shell git diff --name-only $(since) src/)<br class="">endif<br class=""><br class="">Pierre Jolivet <<a href="mailto:pierre.jolivet@enseeiht.fr" class="">pierre.jolivet@enseeiht.fr</a>> writes:<br class=""><br class=""><blockquote type="cite" class="">Hello,<br class="">To git/regexp enthusiasts and/or test harness people: is there some script/command lying around to convert a list of modified examples (according to git) into a list understandable by the test system?<br class="">Thanks for your help,<br class="">Pierre<br class=""><br class="">PS: here is such a list<br class="">$ git status -uno<br class="">On branch master<br class="">Your branch is up to date with 'origin/master'.<br class=""><br class="">Changes not staged for commit:<br class=""> (use "git add <file>..." to update what will be committed)<br class=""> (use "git checkout -- <file>..." to discard changes in working directory)<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>modified: config/BuildSystem/config/types.py<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>modified: include/petscsys.h<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>modified: src/dm/label/tutorials/ex1f90.F90<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>modified: src/ksp/ksp/tests/ex16f.F90<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>modified: src/ksp/ksp/tutorials/ex5f.F90<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>modified: src/ksp/ksp/tutorials/ex75f.F90<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>modified: src/ksp/ksp/tutorials/ex76f.F90<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>modified: src/ksp/ksp/tutorials/ex77f.F90<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>modified: src/ksp/ksp/tutorials/ex7f.F90<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>modified: src/mat/tests/ex196f90.F90<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>modified: src/sys/tests/ex13f.F90<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>modified: src/sys/tests/ex47f.F90<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>modified: src/sys/tutorials/ex17f.F90<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>modified: src/sys/tutorials/ex2f.F90<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>modified: src/vec/vec/tutorials/ex11f90.F90<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>modified: src/vec/vec/tutorials/ex18f.F90<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>modified: src/vec/vec/tutorials/ex1f.F90<br class=""><br class="">no changes added to commit (use "git add" and/or "git commit -a")<br class=""></blockquote></blockquote><br class=""></div></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></div></div></div></div></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></div></body></html>