Yes, if that is our policy, which in seems to have to be, with the GitLab's hardwired .gitlab-ci I have added this, not yet tested or pushed.
Barry > On Jun 23, 2020, at 9:58 AM, Satish Balay <ba...@mcs.anl.gov> wrote: > > BTW: You might want to update petscgitbash to check if a rebase is needed > before it starts a test pipeline.. > > This might need a modified version of > ./lib/petsc/bin/maint/check-ci-settings.sh ['git fetch --unshallow ...' is > for the clones created by gitlab-ci] > > Satish > > On Tue, 23 Jun 2020, Satish Balay via petsc-dev wrote: > >> On Tue, 23 Jun 2020, Barry Smith wrote: >> >>> >>> The issue was when a machine went down we suddenly unknowningly had to >>> rebase against some strange branch before running the pipeline. That was >>> not a good work flow. Perhaps Satish fixed it so master and maint are >>> adjusted when a machine goes down hence no strange branches to merge >>> against. >> >> This was my attempt to work-around - until I pushed a better tested change >> to maint/master. It clearly didn't work. So I pushed my change to maint >> [which forced a rebase] - triggering this email thread. >> >> And the issue here is - do you want pipelines to succeed [and be ready for >> merge - when some tests are not working and ignored. And when they do come >> back - maint/master would be broken. >> >>> >>> I do think a model that "just worked" when a machine went down without >>> needing to change the .gitlab-ci file would be better. If I remember >>> vaguely can't every enry in .gitlab-ci be marked as "skip if the runner is >>> not available". Can we adopt that model? We may have tried it before and >>> were not happy with it? >> >> Then there won't be any test failures per CI - an one would have to check >> every failed job manually to verify if should be ignored or nor. >> >> >> >> One way to do this is with redundancy [of machines - where same test would >> work on either machine] - which we don't have for all OSes.. >> >> I think saving rebases is the wrong goal here.. Its cheap - its >> easy.[compared to other issues], and reorganizing to a more complicated CI >> to save this doesn't sound right. And there are many other reasons CI will >> change - not just machines going down.. >> >> Satish >> >>> >>> Barry >>> >>> >>>> On Jun 23, 2020, at 12:19 AM, Jed Brown <j...@jedbrown.org> wrote: >>>> >>>> Satish Balay via petsc-dev <petsc-dev@mcs.anl.gov> writes: >>>> >>>>> say - you reorganized some configure code - and changed with-x to with-x11 >>>>> >>>>> This means the corresponding change should also be config/*.py - for >>>>> tests not to break. [but other branches would still have to use whats >>>>> valid for them]. >>>>> >>>>> So encoding examples/*.py a single/remote gitlab-ci.yaml just creates >>>>> more problems >>>> >>>> I thought Barry was just proposing inlining the configure options into >>>> .gitlab-ci.yml, which I think would work fine, but also don't clearly see >>>> a point. >>>> >>>>> On Mon, 22 Jun 2020, Barry Smith wrote: >>>>> >>>>>> >>>>>> I see, the way it is now each test case in the .gitlab file is hardwired >>>>>> to an examples/*.py maybe we should just delete the examples/*.py and >>>>>> put them directly in the yaml file. >>> >> >
