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@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 >>
