<anholt>
robclark: you deleted a whole ton of useful stuff in e2736b76 and I really don't know where you're going with it
<robclark>
anholt: mostly just trying to get to the point where I have half a clue what is going on.. I've been going thru ci-templates docs/examples and looking at what other projects were doing, so I was trying to re-build things without so much copy/pasta from mesa ci (and trying to figure out which parts actually matter)
<anholt>
like, other than maybe the marge pipelines bit, you want all of it, though
<robclark>
well, I kinda need to get to the point where I understand what is going on.. the first step is container build with cross compile tool chains, which seems to be working(ish).. but I don't understand why stuff installed in container build step isn't there in kernel build steps
<anholt>
taking my code, it's a matter of adding the package to the container script and bumping the image tag
<anholt>
you don't want the package install env vars
<anholt>
you don't want to use the fdo distro tag without incorporating the templates commit
<anholt>
make sure your container job ran and built things, make sure your tag got used in your build stage, and if things look funny in build stage, docker run the container and go look around
<robclark>
hmm, ok.. a lot of that looked like mesa copy/paste, but I can try to bring that back.. I assume all the MESA_* variables can just be renamed (ie. it isn't actually inheriting anything from mesa)?
<robclark>
it was a bit hard to tell in it's previous form what came from where
<anholt>
sure, they can be renamed
<robclark>
ok.. I can play with that some more tomorrow.. I was kinda hoping going back to ci-templates examples would simplify things but wtv
ximion has quit []
veganaiZe has quit [Quit: veganaiZe]
jstein has quit [Ping timeout: 480 seconds]
alanc has quit [Remote host closed the connection]
alanc has joined #freedesktop
laguneucl has joined #freedesktop
<MrCooper>
is gitlab responding for anyone?
maq has joined #freedesktop
<MrCooper>
I'm getting 504 for git fetch and 502 in the browser
<bentiss>
works here for the couple of projects I tried
<bentiss>
last 502 I can see on the logs is at 9:12:58.529, so right when you complained
<bentiss>
this is likely due to the backups FWIW, I can see spikes in the noode usage
<MrCooper>
yeah, it's back
<bilboed>
is it because backups are scheduled at sunday midnight US time ?
danvet has joined #freedesktop
<bentiss>
bilboed: backups are scheduled every day at 4:00 UTC, but sometimes, like today, the first run fails, and an other one gets restarted
<bilboed>
gotcha
<bentiss>
robclark: BTW, can you use git caching like mesa for robclark/msm?
<bentiss>
robclark: that's 45.3GB out of 54.1 GB of git pulls from the farms that could be reduce to a few KBs
<bentiss>
robclark: it's not urgent important because it doesn't increase the bill but it uses git server resources for nothing
Guest1143 is now known as nirbheek
NoGuest17 has quit [Remote host closed the connection]
NoGuest17 has joined #freedesktop
ceyusa has quit [Ping timeout: 480 seconds]
ceyusa has joined #freedesktop
<danvet>
robclark, karolherbst should we just use the fd.o gitlab-ci helper repos for all this?
<danvet>
instead of rolling our own
<danvet>
bentiss, or what's the recommendation?
<karolherbst>
uhm... good question
<bentiss>
danvet: not sure what the question is about
<karolherbst>
I think most of the scripts we will use will be a bit similiar, no?
<danvet>
bentiss, ci-templates
<danvet>
or maybe I'm just not awake yet at all
<bentiss>
now I'm confused
<danvet>
karolherbst, kernel specific stuff we can share in drivers/gpu/.gitlab-ci/ or so
<karolherbst>
exactly
<karolherbst>
but e.g. the helpers to create the git tarball and stuff
<bentiss>
danvet: please use it, if you need it :)
<danvet>
bentiss, well eventually I expect we'll need to build some kernels + igt images even and then boot them
<bentiss>
FWIW, I am working on using boot2container in ci-templates too, in case you want to run piglit under qemu
* karolherbst
burries himself into s390x stuff again
<danvet>
on qemu or whatever
<bentiss>
cause right now ci-templates has a qemu template but is not very good (in term of dev experience)
<danvet>
I mean I have no clue about anything resembling best practices, just figured less hand-rolling and more standard is good here
<bentiss>
yep, totally agree
<bentiss>
but ci-templates is mostly for creating containers and running them
<bentiss>
I thought karolherbst was using it in his script
<bentiss>
danvet: the official guidance is: if you need to build a container anduse it in fd.o, then please use ci-templates
<bentiss>
the advantages are the following:
<danvet>
bentiss, I'm ok with the guidance :-) robclark karolherbst ^^
<bentiss>
- if we change the CI infra, we will make sure ci-template still works, while using docker in docker *will* break
<bentiss>
- the templates adds some fdo-specific labels to the container we are using on the runners (so you can make images that are transient, only valid for a couple of hours if you want)
<bentiss>
- eventually we are going to use those labels to clean up registries in the background
<bentiss>
that last point is still TBD, because the infra is not ready (from gitlab corp side)
<danvet>
bentiss, btw with the kernel's multirepo approach, anything to consider wrt images?
<danvet>
like should we all pile them up into one place somehow so there's more sharing?
<bentiss>
danvet: sorry, don't know what you mean here...
<danvet>
otoh that's already an issue with user repo forks, not really a kernel thing
<bentiss>
you mean the actual git tree?
<danvet>
bentiss, at least when I played it stores the images in a per repo registry
<danvet>
which makes sense for build specific stuff, but like the "fc34 with all the things we need to build" one could be shared
<danvet>
or just not worth the bother?
<bentiss>
ci-templates should allow you to share blobs between repos
<MrCooper>
danvet: docker images (or technically the layers they consist of) are deduplicated, even across different projects
<danvet>
MrCooper, ah cool, so not my problem :-)
maq has quit []
<bentiss>
so a fork doesn't have to rebuild the image, it just creates a manifest and resue the same blobs
<bentiss>
yeah
<bentiss>
for the git hosting, we now have 3 git servers, and gitlab is smart enough to do git deduplication, so we should be good hosting the various kernel trees on gitlab
<bentiss>
(though I wouldn't mind a gradual approach, not everybody moving the same day)
<bentiss>
and for git hosting, use the 'fork' button, not push from your own local copy, or it will end up not deduplicating the data
<danvet>
bentiss, yeah I think steps roughly are 1) get some experimental stuff going 2) do a topic pull to Linus with the first 1-2 driverrs or so in drivers/gpu/.gitlab-ci
<danvet>
3) move drm.git over and start using it there to validate subtree pulls
<danvet>
4) move drm-misc
<danvet>
5) slowly open up drm-misc to MR from contributors
<danvet>
or something like that
<bentiss>
danvet: sounds good
<danvet>
to make sure we don't set anything on fire
<bentiss>
danvet: FWIW, right now the nouveau folks are doing the experimental work
<bentiss>
the more we share the better though :)
<danvet>
oh step 1 seems to be msm + nouveau, which are fairly small in terms of activity
<bentiss>
yep, that's all fine :)
<danvet>
bentiss, yeah we discussed a bit over the w/e
<danvet>
I'm trying to get them to be a bit more bold and put it into the kernel repo under drivers/gpu directly
<bentiss>
danvet: that is not a bad idea :)
<danvet>
so that we have eventually an easier place to collaborate on this, instead of everyone rolling their sidecar ci repo themselves
<danvet>
you can still filter out certain targets like mesa does easily
laguneucl has quit [Ping timeout: 480 seconds]
NoGuest17 has quit [Remote host closed the connection]
NoGuest17 has joined #freedesktop
<pq>
The image de-duplication with registries is not really automatic, is it? It depends on the given tag existing in the given registry and it won't search for the tag in not-explicitly-related projects, does it?
<bentiss>
pq it works if you are using the same blobs
<pq>
Like if you have a tag in user repo that is even an explicit fork of the upstream repo, the upstream repo jobs will not look at the user repo for the tags?
<bentiss>
ci-templates does a retag fo the image and push it again (well skopeo does it on the server side), so you can reuse the same layers
<bentiss>
pq: the registry doesn't know about forks
<bentiss>
it works at the blobs
<bentiss>
*level
<pq>
hmm, I thought that whenever I merged an image change into Weston upstream, the upstream repo job would rebuild the image again, even if exists in the user repo.
<MrCooper>
pq: docker images can contain any number of layers, each of which is identified by a hash; deduplication means if multiple image tags reference the same hash for a layer, that layer exists only once in the backing storage
<bentiss>
yes, because ci-templates ensures that
<bentiss>
pq: from ci-templates, when you are entering the 'build container' job, if you are in a fork, we check if upstream has an image, and if it has, it syncs the upstream image with the fork. When you are in the upstream repo (FDO_UPSTREAM_REPO), we would rebuild the image if there is none
<bentiss>
so if the fork built an image, upstream will not take it
<pq>
yes, I understand how images are re-used from upstream in forks, but about the opposite direction?
<bentiss>
(there is a slight exception for detached MR pipelines that are executed in the namespace of the upstream project)
<bentiss>
pq: that was my second phrase: in the upstream repo, we have no information of the fork from the job that is running, so if the tag doesn't exist, we just build it
<bentiss>
(when merged on master/main)
<pq>
right, so hashes deduplicate, but I'm confused about how you would know the hash to look for, if don't know which tag in which registry
<pq>
the point I'm getting to is, would all kernel repos need a single "fork origin" to be able to re-use the images, and even then only in the direction of from origin in derived repos?
<bentiss>
pq: I think we shouldn care much about that: there might be 5 'upstream' images with all of them their own layers. The thing is that user forks will reuse the same images from their original fork
<pq>
ok, so drm-misc repo needs to be a fork of drm.git or something?
<pq>
I'm assuming it's practically impossible to re-build an image and end up with the same hash as before.
<bentiss>
no, drm-misc is going to be forked by users so it will be a root node
<bentiss>
pq: no,m you can not rebuild the same layer
<bentiss>
but maybe considering drm-misc or drm-next or drm being 'FDO_UPSTREAM_REPO', would sole that problem
<bentiss>
if all commits have to go in drm-next, then the images can be "officially"built there
<pq>
right, so de-dup is not automatically automatic, the repositories need to be organized for it to work.
<bentiss>
not the repo
<bentiss>
ci-templates doesn't care about if you are a fork or not
<bentiss>
ci-templates care about 'FDO_UPSTREAM_REPO' env variable
<bentiss>
we can set it to whatever we want and it will be doing the right thing, even if the 2 reops are not forks, or not even having the same tree
<pq>
yes, that's what I mean, but overlooked that setting its value would be inherited from Linus' :-)
<pq>
so it's set the same in all repos
<bentiss>
assuming you want to share the same image with other subsystems, then yes
<daniels>
set it to whatever you want it to be ...
<daniels>
all FDO_UPSTREAM_REPO is is a lookaside from when the named image tag in your templates is not available in your repo
<bentiss>
ideally to a repo that is official enough updated quickly enough for all the various trees
<bentiss>
is drm-next an automated merge or is it updated only when airlied opens his merge window?
<pq>
Right, so not automatic de-dup from Gitlab's behalf, but if you happen to use ci-templates in a certain way, then de-dup happens.
<bentiss>
pq: exactly
<pq>
I got confused because I thought MrCooper implied much more.
<bentiss>
pq: technically, all ci-templates is doing to keep the same layer is calling 'skopeo copy docker://source docker://dest', which you can arguably run on your own machine too :)
<bentiss>
(but ci-templates is smarter to do it only when required)
bcarvalho has joined #freedesktop
laguneucl has joined #freedesktop
bcarvalho has quit [Remote host closed the connection]
bcarvalho has joined #freedesktop
<daniels>
pq: right, there are two levels there. one is that ci-templates will use $FDO_UPSTREAM_REPO (whatever that's defined as) as a container image source when the requested image is not available in your repo
<daniels>
it does this by copying $FDO_UPSTREAM_REPO/$IMAGE_NAME:$IMAGE_TAG into your repo, which is where the second level kicks in - when you do that, the registry doesn't store a completely duplicated copy, because it notices that it already has that content so simply stores a reference to it rather than duplicating the entire content
<pq>
danvet, ^
ximion has joined #freedesktop
i-garrison has quit []
i-garrison has joined #freedesktop
<danvet>
pq, daniels ah so we really should be using ci-templates
<daniels>
yep
<daniels>
you can avoid it to make it simple, but then you'll just end up NIHing all the complexity over time, and doing it worse
veganaiZe has joined #freedesktop
tobtoht has quit [Remote host closed the connection]
tobtoht has joined #freedesktop
<robclark>
bentiss: re: git caching, sure.. how do I enable that?
<robclark>
danvet: I am using the ci-templates repo
<bentiss>
robclark: nouveau is running a daily schedule pipeline to update the archive. You can make it daily or shorter/longer depending how fast your tree is moving
<bentiss>
robclark: the scheduled pipeline is at 'make git archive' in the gitlab-ci.yaml file from nouveau
<robclark>
maybe for now I'll just use nouveau's caches? But I think at the end we want all the gitlab kernel driver trees to use the same thing..
<bentiss>
robclark: if your tree is close enough tonouveau, then sure
<robclark>
I mean, I guess the delta would normally be the stuff in drivers -next tree, which is tiny compared to size of whole kernel
<robclark>
s/tree/branch/
<bentiss>
yep, I get that
<bentiss>
if you can not see how much you save by using the nouveau archive I can easily get that for you
<bentiss>
but FWIW, using the nouveau tree as a base would be way better than starting from scratch
<bentiss>
and also yes, in the end, we'll probably just have the drm-next archive that everybody will be using
<robclark>
presumably this will speed up the "clone the kernel tree" step? Which seems to be one of the longer parts
<bentiss>
robclark: it should, yes
<bentiss>
basically, the running will pull the archive, unpack it, and then do a git remote update
Kayden has quit [Read error: Connection reset by peer]
K`den is now known as kayden
kayden is now known as Kayden
kaitsh has joined #freedesktop
Haaninjo has joined #freedesktop
<robclark>
bentiss: do I need some configuration to get CI_PRE_CLONE_SCRIPT to work? afaict it is not being executed.. I think.. and some (but not all) of my build jobs end up with no git tree (see https://gitlab.freedesktop.org/robclark/msm/-/pipelines/353619)
<danvet>
bentiss, robclark maybe we could do that image daily with linux-next?
<bentiss>
robclark: that script should be running on all packet machines
<robclark>
hmm, linux-next has a lot of force-push, so ends up with extra unimportant history, I guess
<robclark>
hmm
<bentiss>
robclark: "Skipping Git repository setup" -> you somehow have a git pull policy set to never or the equivalent (can't remember out of my head)
<robclark>
hmm, I think I'm inheriting GIT_STRATEGY=none in build step, which I think I don't want to do..
<bentiss>
yep
<bentiss>
if git strategy is none, the runner will not run the pre_clone script
* bentiss
<- dinner time, bbl
<robclark>
enjoy.. I think I'm getting close to have something working
<robclark>
danvet: btw, I think I want to slurp in dim to build jobs, so we can run the checks it does for correct s-o-b, fixes tags, etc, as part of CI run
<danvet>
robclark, sounds good
<danvet>
robclark, well eventually I'm thinking that maybe we should just move those over to gitlab-ci
<danvet>
once marge is set up on drm-misc or so
<danvet>
but that's going to take a while
<robclark>
yeah
<danvet>
robclark, once the gitlab-ci stuff is in drm-next maybe we can duplicate them
<danvet>
so that we don't have to deal with excessive amounts of external repos for no good reason
<danvet>
robclark, one thing that's annoying is that checkpatch has it all, but is also full of bikesheds
<robclark>
it looks like a single giant shell script, so I guess I can just wget it for now
<danvet>
so not useful at all as a CI linter
<danvet>
yeah it's all in one
<robclark>
yeah, I would strongly oppose checkpatch being part of CI pipeline
<robclark>
at least for drm/msm
<bentiss>
robclark: FWIW, on hid, I am running checkpatch as a 'allowed to fail'
<bentiss>
the nice thing is if you get green, you know it's fine, but if not, you can always wave it mentally :)
<robclark>
I suppose we could do that.. but my experience with checkpatch is that it is more noise than value
<danvet>
bentiss, yeah that's what we do with patchwork on intel-gfx too
<danvet>
but there's so much noise in there it's barely useful in many cases
<bentiss>
robclark: any reasons to start from scratch and not use karolherbst ci jobs?
<robclark>
well, anholt already had something initial setup, I just refactored it a bit so we could more easily add other builds (like x86)
<robclark>
also, seemed easier to have CI in-tree, rather than out
<bentiss>
well, ack to that, but karolherbst had a nice 'comment in MR in case of failure' you probably want
<bentiss>
I mean, not that it can not be added later
<karolherbst>
bentiss: we discussed this and it has silly security implications once you do CI in tree
<robclark>
yeah, it would be nice to get something like that.. but initially we won't be using MRs *yet*
<karolherbst>
because you can change CI and use a token to do random shit
<karolherbst>
true...
<robclark>
maybe merge-bot could take over the comment-in-MR role?
<robclark>
it would be nice to have for mesa as well
<karolherbst>
yeah, I am all for that
<bentiss>
right...
<robclark>
danvet: hmm, dim doesn't really want to so much be used as a standalone sane-checkpatch thing.. but I suppose if checkpatch does check things like Fixes tags pointing to a valid commit-id we could just use checkpatch with a long list of warning disabled..
<robclark>
anholt, bentiss: thinking ahead a bit, by the time we add some kernel gitlab-ci testing on real hw, I suspect we end up copy/pasta'ing a bunch of mesa baremetal container stuff.. I wonder if it would make sense to promote some of that to ci-templates?
<danvet>
robclark, well hence why I think copypasting might be easier
<danvet>
and checkpatch-with-disables sounds like a game of whack-a-mole
<danvet>
we're trying to do that in dim, but it's a bit hopeless
<robclark>
re: baremetal.. I think I'll start w/ copypasting just to get something running.. but I guess at some point we might want to refactor that
<robclark>
re: dim vs checkpatch.. yeah, not sure the best answer there.. I guess a different option would be some dim refactoring, or just copypaste some of dim into a standalone script
danvet has quit [Ping timeout: 484 seconds]
immibis has quit [Remote host closed the connection]
anholt has quit [Remote host closed the connection]
i-garrison has quit [Ping timeout: 480 seconds]
i-garrison has joined #freedesktop
ximion1 has joined #freedesktop
ximion has quit [Ping timeout: 480 seconds]
i-garrison has quit []
i-garrison has joined #freedesktop
tobtoht has quit [Remote host closed the connection]