> If we did this in the pipeline they could be significantly faster We might also consider not locking _all_ stage n+1 jobs behind completion of stage n. Gitlab supports this via the “needs” command https://gitlab.com/help/ci/yaml/README.md#needs <https://gitlab.com/help/ci/yaml/README.md#needs> 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.
Best regards, Jacob Faibussowitsch (Jacob Fai - booss - oh - vitch) Cell: (312) 694-3391 > On Jul 6, 2020, at 12:47 PM, Barry Smith <[email protected]> wrote: > > > 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. > > 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 :-) > > Is there a fallacy here? > > Barry > > Need to check changes in include files as well, of course. > > >> On Jul 6, 2020, at 12:13 PM, Jacob Faibussowitsch <[email protected] >> <mailto:[email protected]>> wrote: >> >> 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. >> >> Best regards, >> >> Jacob Faibussowitsch >> (Jacob Fai - booss - oh - vitch) >> Cell: (312) 694-3391 >> >>> On Jul 6, 2020, at 12:00 PM, Barry Smith <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> >>> I couldn't see how Jed can avoid doing the filename hacking since >>> alltesttargets are the hacked filenames but probably I am missing >>> something. >>> >>> Anyways this patch works for me based on Jed's email. >>> >>> Barry >>> <since.patch> >>> >>>> On Jul 6, 2020, at 9:40 AM, Jed Brown <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> It'd be possible to hack the file names, but I'd rather not duplicate that >>>> logic. >>>> >>>> My inclination would be to filter similar to argsearch, which requires >>>> adding the source files to testfiles. Then you could use >>>> >>>> make test since=@ >>>> >>>> ifdef since >>>> gitchanged := $(shell git diff --name-only $(since) src/) >>>> endif >>>> >>>> Pierre Jolivet <[email protected] >>>> <mailto:[email protected]>> writes: >>>> >>>>> Hello, >>>>> 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? >>>>> Thanks for your help, >>>>> Pierre >>>>> >>>>> PS: here is such a list >>>>> $ git status -uno >>>>> On branch master >>>>> Your branch is up to date with 'origin/master'. >>>>> >>>>> Changes not staged for commit: >>>>> (use "git add <file>..." to update what will be committed) >>>>> (use "git checkout -- <file>..." to discard changes in working directory) >>>>> >>>>> modified: config/BuildSystem/config/types.py >>>>> modified: include/petscsys.h >>>>> modified: src/dm/label/tutorials/ex1f90.F90 >>>>> modified: src/ksp/ksp/tests/ex16f.F90 >>>>> modified: src/ksp/ksp/tutorials/ex5f.F90 >>>>> modified: src/ksp/ksp/tutorials/ex75f.F90 >>>>> modified: src/ksp/ksp/tutorials/ex76f.F90 >>>>> modified: src/ksp/ksp/tutorials/ex77f.F90 >>>>> modified: src/ksp/ksp/tutorials/ex7f.F90 >>>>> modified: src/mat/tests/ex196f90.F90 >>>>> modified: src/sys/tests/ex13f.F90 >>>>> modified: src/sys/tests/ex47f.F90 >>>>> modified: src/sys/tutorials/ex17f.F90 >>>>> modified: src/sys/tutorials/ex2f.F90 >>>>> modified: src/vec/vec/tutorials/ex11f90.F90 >>>>> modified: src/vec/vec/tutorials/ex18f.F90 >>>>> modified: src/vec/vec/tutorials/ex1f.F90 >>>>> >>>>> no changes added to commit (use "git add" and/or "git commit -a") >>> >> >
