[petsc-dev] Getting .gitlab.ci file out of repository? https://docs.gitlab.com/ee/ci/pipelines/settings.html

[Satish Balay]

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 <jed at jedbrown.org> wrote:
> > 
> > Satish Balay via petsc-dev <petsc-dev at 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.
>