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

[Barry Smith]

  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 <balay at 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 <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.
>>> 
>> 
>