Hi,
On 12/09/24 11:18, Dmitry Baryshkov wrote:
On Mon, Sep 09, 2024 at 07:34:04AM GMT, Rob Clark wrote:
On Mon, Sep 9, 2024 at 2:54 AM Dmitry Baryshkov
<dmitry.baryshkov@xxxxxxxxxx> wrote:
On Mon, 9 Sept 2024 at 10:50, Maxime Ripard <mripard@xxxxxxxxxx> wrote:
Hi,
On Tue, Jul 09, 2024 at 01:27:51AM GMT, Dmitry Baryshkov wrote:
On Mon, 8 Jul 2024 at 21:38, Rob Clark <robdclark@xxxxxxxxx> wrote:
On Mon, Jul 8, 2024 at 1:52 AM Daniel Vetter <daniel.vetter@xxxxxxxx> wrote:
On Fri, Jul 05, 2024 at 12:31:36PM -0700, Rob Clark wrote:
On Fri, Jul 5, 2024 at 3:36 AM Daniel Vetter <daniel.vetter@xxxxxxxx> wrote:
On Thu, Jul 04, 2024 at 08:40:26AM -0700, Rob Clark wrote:
On Thu, Jul 4, 2024 at 7:08 AM Daniel Vetter <daniel.vetter@xxxxxxxx> 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@xxxxxxxx> 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@xxxxxxxx> 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.
So what I don't get is ... if we CI drm-misc, how does that not help
improve the situation here? Step one would be post-merge (i.e. just enable
CI in the repo), then get MRs going.
I guess post-merge is better than nothing.. but pre-merge is better.
post-merge can work if you have a "sheriff" system where someone
(perhaps on a rotation) is actively monitoring results and "revert and
ask questions later" when something breaks. Pre-merge ensures the
interested party is involved in the process ;-)
So ... make that happen? And it doesn't have to be for all of drm-misc,
mesa after all switched over to MR also on a bit a driver/area basis. So
agreeing among all drm-ci folks to use gitlab MR in drm-misc for pre-merge
testing shouldn't be that hard to make happen. And unlike a separate
branch it's not some kind of detour with a good chance to get stuck in a
local optimum.
Tree vs branch doesn't really have much in the way of distinction,
modulo gitlab permissions. In that it doesn't do much good if drm/ci
patches are landing on a different branch.
I guess what you are suggesting is that we have a single tree/branch
that drm/ci + drm/msm + (plus whoever else wants to get in on the
drm/ci, so probably at least vkms) lands patches into via gitlab MRs?
This again brings a separate CI-enabled tree. I think it has been
suggested to start with enabling DRM CI for drm-misc branches. Then we
can possibly start landing MRs with CI testing (probably starting with
vkms).
It's something we've discussed with Sima for a while, but enabling CI on
drm-misc at some point will make sense so we could just as well start
now.
The biggest unknown at the moment to start doing so is how we could keep
drm-tip and the rerere repo with MR.
Let's do a slow start and begin with post-merge testing. At least this
gives us an idea of how stable it is (and what does it take to keep it
green). Maybe we can perform post-merge testing for both drm-misc and
drm-tip.
The one thing is that currently the runtime for igt is quite long
(~1hr) because you can't really parallelize kms tests. So maybe
nightly scheduled runs would be a better idea.
SGTM. So, the question would be, who can set it up?
We will test the nightly pipelines in a forked repo and then will
set it up for drm-misc and drm-tip.
Regards,
Vignesh
