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

[Jed Brown]

If we used the merge_request trigger, it could do the merge automatically and thus we wouldn't need to think about this.  (Perhaps we'd put "-o ci.skip" into our default push options.)

I don't like the idea of taking it out of the repository; it'd make it much harder to reproduce tests from an earlier time.  I think it would create a lot of new failure modes.

Satish Balay via petsc-dev <petsc-dev at mcs.anl.gov> writes:

> An automatic message asking rebase was preferred over other issues we previously had.
>
> And the examples/arch*.py are in sync with the sources [in branch] and .gitlab.ci is in sync with examples/arch*.py
>
> And updates to any of them can be done in a feature branch [as feature changes result in CI changes] - and the merge propagates such changes nicely [and does force a rebase]
>
> And if they are split up - then we'll have to worry about manually syncing them  - can't really test changes before doing updates. [and worry about having a single config file that handles both maint and master.]
>
> However - in some sense - the ability to modify .gitlab.ci in any feature branch is not a good thing..
>
> Satish
>
> On Mon, 22 Jun 2020, Barry Smith wrote:
>
>> 
>>    Should we get the .gitlab.ci yaml file out of the repository so people don't need to constantly monkey around with rebasing etc when something needs to change in the file?
>> 
>>    Seems to be number of ways of having out of the repository.
>> 
>>    What about the the examples/arch*.py files? Do we have to use the ones in the repository? 
>> 
>>    Of course we should rebase against master or maint when testing but it gets annoying when you did do that but then immediately you have to do it again since some test machine when down. Shouldn't really be a concern of the developer when test machines go up and down.
>> 
>>    Barry
>>