Time for drm-ci-next?

[Rob Clark]

On Thu, Jul 4, 2024 at 7:08 AM Daniel Vetter <daniel.vetter at ffwll.ch> wrote:
>
> On Tue, Jul 02, 2024 at 05:32:39AM -0700, Rob Clark wrote:
> > On Fri, Jun 28, 2024 at 10:44 AM Daniel Vetter <daniel at ffwll.ch> wrote:
> > >
> > > On Thu, Jun 27, 2024 at 11:51:37AM -0700, Rob Clark wrote:
> > > > On Wed, Jun 26, 2024 at 10:47 AM Daniel Vetter <daniel at ffwll.ch> wrote:
> > > > >
> > > > > On Wed, Jun 26, 2024 at 11:38:30AM +0300, Dmitry Baryshkov wrote:
> > > > > > On Wed, Jun 26, 2024 at 09:32:44AM GMT, Daniel Vetter wrote:
> > > > > > > On Mon, Jun 24, 2024 at 10:25:25AM -0300, Helen Koike wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > > On 24/06/2024 02:34, Vignesh Raman wrote:
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > On 15/03/24 22:50, Rob Clark wrote:
> > > > > > > > > > Basically, I often find myself needing to merge CI patches on top of
> > > > > > > > > > msm-next in order to run CI, and then after a clean CI run, reset HEAD
> > > > > > > > > > back before the merge and force-push.  Which isn't really how things
> > > > > > > > > > should work.
> > > > > > >
> > > > > > > This sounds more like you want an integration tree like drm-tip. Get msm
> > > > > > > branches integrated there, done. Backmerges just for integration testing
> > > > > > > are not a good idea indeed.
> > > >
> > > > But AFAIU this doesn't help for pre-merge testing, ie. prior to a
> > > > patch landing in msm-next
> > > >
> > > > My idea was to have a drm-ci-next managed similar to drm-misc-next, if
> > > > we have needed drm/ci patches we could push them to drm-ci-next, and
> > > > then merge that into the driver tree (along with a PR from drm-ci-next
> > > > to Dave).
> > >
> > > I guess I'm confused about what kind of pre-merge testing we're talking
> > > about then ... Or maybe this just doesn't work too well with the linux
> > > kernel. The model is that you have some pile of trees, they're split up,
> > > and testing of all the trees together is done in integration trees like
> > > linux-next or drm-tip.
> >
> > pre-merge: for msm we've been collecting up patches from list into a
> > fast-forward MR which triggers CI before merging to msm-next/msm-fixes
> >
> > Ideally drm-misc and other trees would do similar, we'd catch more
> > regressions that way.  For example, in msm-next the nodebugfs build is
> > currently broken, because we merged drm-misc-next at a time when
> > komeda was broken:
> >
> > https://gitlab.freedesktop.org/drm/msm/-/jobs/60575681#L9520
> >
> > If drm-misc was using pre-merge CI this would have been caught and the
> > offending patch dropped.
>
> That sounds more like we should push on the drm-misc pre-merge CI boulder
> to move it uphill, than add even more trees to make it even harder to get
> there long term ...
>
> Short term it helps locally to have finer trees, but only short term and
> only very locally.

The path to have fewer trees (ideally only one for all of drm) is to
use gitlab MRs to land everything :-)

drm-ci-next is only a stop-gap.. but one that we need.  The
${branchname}-external-fixes trick covers _most_ cases where we need
unrelated patches (ie. to fix random ToT breakage outside of drm or in
core drm), but it doesn't help when the needed changes are yml
(because gitlab processes all the yml before merging the
-external-fixes branch).  This is where we need drm-ci-next, otherwise
we are having to create a separate MR which cherry-picks drm/ci
patches for doing the CI.  This is a rather broken process.

I could conceivably see a scenario where we are landing both drm/ci
and drm/msm changes via the same tree.  But only if we were using
gitlab MRs and CI for landing all changes in that tree.

BR,
-R

> -Sima
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch