>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3371136. --> Reported by: [hestenet](https://www.drupal.org/user/54034) >>> <p>This meeting:<br> &#10148; Is for core developers, initiative contributors, the Drupal Association and anyone interested in the initiative.<br> &#10148; Usually happens every other Wednesday at 11:00 PT / Thursday 06:00 UTC<br> &#10148; Is done over chat.<br> &#10148; Happens in threads, which you can follow to be notified of new replies even if you don&rsquo;t comment in the thread. You may also join the meeting later and participate asynchronously!<br> &#10148; Lots of threads get posted all at once! Don't worry - start at the top and then jump into the threads that most interest you.<br> &#10148; Has a public agenda anyone can add to in the issue<br> &#10148; *Transcript will be exported and posted* to the agenda issue. For anonymous comments, start with a :bust_in_silhouette: emoji. To take a comment or thread off the record, start with a :no_entry_sign: emoji.</p> <p>ping: @mixologic @FeyP @jurgenhaas (go to the issue of the next meeting to add or remove yourself from the list)</p> <h2>Transcript</h2> <h2>0&#65039;&#8419; Who is here today? Comment in the thread below to introduce yourself!</h2> <table> <tr> <td>markie</td> <td>hi.. checking in here</td> </tr> <tr> <td>markdorison</td> <td>Mark from Chromatic here :blob_wave:</td> </tr> <tr> <td>tyler36</td> <td>Hi from Japan</td> </tr> <tr> <td>Bj&ouml;rn Brala (bbrala)</td> <td>Bj&ouml;rn, :flag-nl:</td> </tr> </table> <h2>1&#65039;&#8419; Do you have any topics to propose for the meeting today? Feel free to propose them in this thread, and then I will give them their own unique threads for discussion. Conversation moving slow? Go ahead and open your own thread in the next numeric order.</h2> <table> </table> <h2>2&#65039;&#8419; GitLab CIWe've had some good adoption since the announcement of availability at DrupalConWe're getting a bit over 400 pipelines executed per week right now.</h2> <table> <tr> <td>Bj&ouml;rn Brala (bbrala)</td> <td>Was actually gonna ask that :sweat_smile: nice</td> </tr> <tr> <td>markie</td> <td>we added it to smart_trim.. still have a few things to shore up</td> </tr> </table> <h2>2&#65039;&#8419; 1&#65039;&#8419;&nbsp; GitLab CI - PerformanceA general concern is still that GitLabCI runs are noticeably slower than DrupalCI runs, not just in core, but also in some apples to apples contrib examples. This is something that @fjgarlin has been looking at a bit - but would also be a good area of contribution for anyone who has experience optimizing CI in GitLab.Is there any way to replicate tmpfs style optimizations from DrupalCI in GitLabCI without 'hacking' the runner?&nbsp;(edited)&nbsp;</h2> <table> <tr> <td>Bj&ouml;rn Brala (bbrala)</td> <td>Slower in absolute time, or slower in time&nbsp; per test?</td> </tr> <tr> <td>markdorison</td> <td>I came here to ask the same question</td> </tr> <tr> <td>hestenet (he/him)</td> <td>Certainly in absolute time. Although it'd be a good idea to compare the same test across both systems.</td> </tr> <tr> <td>hestenet (he/him)</td> <td>I swear I had a good example somewhere in backscroll but I'm having trouble finding it...</td> </tr> <tr> <td>Bj&ouml;rn Brala (bbrala)</td> <td>Would be interesting to know which parts are slower. Is there any baseline available for the old setup for types of tests, setup time etc?</td> </tr> <tr> <td>hestenet (he/him)</td> <td>Oh right - even these two examples of the api module tests:<a href="https://git.drupalcode.org/project/api/-/jobs/52555">https://git.drupalcode.org/project/api/-/jobs/52555</a> - 30 min, 7 sec<a href="https://dispatcher.drupalci.org/job/drupal_contrib/704012/console">https://dispatcher.drupalci.org/job/drupal_contrib/704012/console</a> 4 min, 42 sec</td> </tr> <tr> <td>Bj&ouml;rn Brala (bbrala)</td> <td>:face_with_open_eyes_and_hand_over_mouth:</td> </tr> <tr> <td>hestenet (he/him)</td> <td>Now these were the same ones where Fran saw different results, but even so...</td> </tr> <tr> <td>Bj&ouml;rn Brala (bbrala)</td> <td>There are so many things this could be. Packaging, storage types, resources, artifacts, chromedriversetuo, dB setup</td> </tr> <tr> <td>Bj&ouml;rn Brala (bbrala)</td> <td>I know one I think</td> </tr> <tr> <td>Bj&ouml;rn Brala (bbrala)</td> <td>I think on drupalci things ran on tmpfs?</td> </tr> <tr> <td>hestenet (he/him)</td> <td>Yeah - the possibilities are pretty daunting</td> </tr> <tr> <td>hestenet (he/him)</td> <td>Yeah</td> </tr> <tr> <td>hestenet (he/him)</td> <td>DCI runner had a lot of speed hacks</td> </tr> <tr> <td>Bj&ouml;rn Brala (bbrala)</td> <td>Io is waaaaaaay slower now</td> </tr> <tr> <td>hestenet (he/him)</td> <td>Not sure how to replicate when we want to use the gitlab ci runner - not sure how much we can inject without 'hacking' it</td> </tr> <tr> <td>Bj&ouml;rn Brala (bbrala)</td> <td>I noticed that a LOT when moving project analasis</td> </tr> <tr> <td>hestenet (he/him)</td> <td>That certainly makes sense.</td> </tr> <tr> <td>Bj&ouml;rn Brala (bbrala)</td> <td>Tmpfs is a runner option that is confgurable</td> </tr> <tr> <td>Bj&ouml;rn Brala (bbrala)</td> <td>I think</td> </tr> <tr> <td>hestenet (he/him)</td> <td>Ah! That would be great, if true</td> </tr> <tr> <td>Bj&ouml;rn Brala (bbrala)</td> <td><a href="https://docs.gitlab.com/runner/executors/docker.html#mounting-a-directory-in-ram">https://docs.gitlab.com/runner/executors/docker.html#mounting-a-directory-in-ram</a></td> </tr> <tr> <td>Bj&ouml;rn Brala (bbrala)</td> <td>I'm on a phone, searching is hard lol</td> </tr> <tr> <td>hestenet (he/him)</td> <td>Heh - no worries</td> </tr> <tr> <td>Bj&ouml;rn Brala (bbrala)</td> <td>But I looked into it back then l, and stopped cause of base config stuff I wasn't gonna get in that phase</td> </tr> <tr> <td>Bj&ouml;rn Brala (bbrala)</td> <td>But running the code and perhaps dbs and such on a tmpfs would be very fast</td> </tr> <tr> <td>Bj&ouml;rn Brala (bbrala)</td> <td>But you'd need a few gigs of extra ram I guess</td> </tr> <tr> <td>Bj&ouml;rn Brala (bbrala)</td> <td>I'll try and find the reference qhen I get back at my pc later</td> </tr> <tr> <td>Bj&ouml;rn Brala (bbrala)</td> <td>@hestenet (he/him) @drumm think, this might be how: <a href="https://gitlab.com/gitlab-org/gitlab-runner/-/issues/3847#note_410502307">https://gitlab.com/gitlab-org/gitlab-runner/-/issues/3847#note_410502307</a></td> </tr> <tr> <td>hestenet (he/him)</td> <td>Drumm is out of office until July 12- but we can definitely start looking into this</td> </tr> <tr> <td>Bj&ouml;rn Brala (bbrala)</td> <td>You will run into resource limit issues probably, but this might be a way.</td> </tr> <tr> <td>Bj&ouml;rn Brala (bbrala)</td> <td>@hestenet (he/him) any chance i could see the .toml for gitlab?</td> </tr> <tr> <td>Bj&ouml;rn Brala (bbrala)</td> <td>not sure if it contains secrets</td> </tr> <tr> <td>andypost</td> <td>FYI I used to try add Drupal testing to PHP&nbsp; this week and run-tests was ~x2 slower then phpunit runner in guthub infra&nbsp;(edited)</td> </tr> <tr> <td>andypost</td> <td>even concurrency does not help</td> </tr> <tr> <td>andypost</td> <td>if mysql is running in k8s it could bring x2-x3 slowness depending on k8s storage provider, moreover if DB is running not as daemonset</td> </tr> <tr> <td>Bj&ouml;rn Brala (bbrala)</td> <td>The dbs are service containers, so storage might be some sort of pvc of emptydir. I run nothing on cloud providers, so dunno what storage that would be. But prolly no ssd :sweat_smile:</td> </tr> <tr> <td>andypost</td> <td>@Bj&ouml;rn Brala (bbrala) do you mean services in terms of gitlabCI? IIRC runner creating common containers and there's no way to affect the process, surely this way times slower comparing to tmpfs</td> </tr> <tr> <td>Bj&ouml;rn Brala (bbrala)</td> <td>I'm not sure you cannot influence storage type tbh. There are settings for services</td> </tr> <tr> <td>andypost</td> <td>It's configurable at runner's manifest</td> </tr> <tr> <td>Bj&ouml;rn Brala (bbrala)</td> <td>Yeah so, there might be a few ways to configure how the runners are run to make sure we include optimizations like that. At the cost of memory usage.</td> </tr> <tr> <td>andypost</td> <td>btw Looking for ideas to add performance regression test directly to PHP, as I mostly done with general one <a href="https://github.com/php/php-src/pull/10050">https://github.com/php/php-src/pull/10050</a></td> </tr> <tr> <td>fjgarlin</td> <td><a href="https://drupal.slack.com/archives/CGKLP028K/p1688565591726929?thread_ts=1687941115.592569&amp;cid=CGKLP028K">https://drupal.slack.com/archives/CGKLP028K/p1688565591726929?thread_ts=1687941115.592569&amp;cid=CGKLP028K</a></td> </tr> <tr> <td>drumm</td> <td>We&rsquo;re provisioning these on AWS spot instances, so we can provision as much RAM as we want to pay for. In DrupalCI, the AMI (I think) set up the ram disk. Just having Kubernetes set up all storage to be backed by RAM is an interesting idea. That&rsquo;d save containers needing to set up anything special. Or stick to SSDs if the trade-offs favor that.</td> </tr> </table> <h2>2&#65039;&#8419; 2&#65039;&#8419; GitLab CI for CoreSpeaking of which - it would be good to continue supporting the work of folks trying to get core running.</h2> <table> </table> <h2>3&#65039;&#8419; GitLab issuesThis is our next big milestone, and frankly is what lets us fully realize the vision of getting everything moved to GitLab.We demoed a fork management option - and got your feedback on two areas:Trying to make sure that as much of the GitLab UI is usable as expected (someone trying to click a fork button when browsing a module, etc) Trying to limit the amount of back and forth needed between a d.o node and the GitLab issues - which are hopefully only needed as an access management step. </h2> <table> </table> <h2>3&#65039;&#8419; 1&#65039;&#8419; Truthfully though, our next big blocker before we see much more progress on this is actually our SSO work for the D7-&gt;D10 upgrade for D.O - because that is what will let us migrate credit, and implement these access management workflows.This is our next highest priority after the work we're doing for #autoupdates on the secure signing server.</h2> <table> <tr> <td>moshe</td> <td>We are hard blocked by a d.o. D10 upgrade? That raises an eyebrow at first impression.</td> </tr> <tr> <td>Bj&ouml;rn Brala (bbrala)</td> <td>I think it's hard blocked on the decoupling of auth from d7 which will power d10? I think that's what I read</td> </tr> <tr> <td>hestenet (he/him)</td> <td>Oh yes - not on the full migration.</td> </tr> <tr> <td>hestenet (he/him)</td> <td>There are some content components that go as well, like credit, but we have plans to do that without having to do the full site.</td> </tr> <tr> <td>Bj&ouml;rn Brala (bbrala)</td> <td>Is there a backlog or plan for the d.o. upgrade?</td> </tr> <tr> <td>Bj&ouml;rn Brala (bbrala)</td> <td>Feels like the whole gitlab thing is the biggest blocker in many ways?</td> </tr> <tr> <td>Bj&ouml;rn Brala (bbrala)</td> <td>(Sorry I'm being lazy to search, on mobile ;()</td> </tr> <tr> <td>hestenet (he/him)</td> <td>Yeah - the sso migration work is built out and needs testing, the content type stuff for the components that do need to mvoe are built as well (those are what have been shared in Fran's demo videos).</td> </tr> <tr> <td>moshe</td> <td>Ideally we could see a list of dependencies for adopting Gitlab issues. Are there more blockers behind this Auth work? I wasn't aware of that one. I'm looking for a "here is our best guess", not a commitment or anything like that.</td> </tr> <tr> <td>hestenet (he/him)</td> <td>I'll get an issue summary update together.</td> </tr> </table> <p>Participants:</p> <p>Bj&ouml;rn Brala (bbrala), markie, markdorison, hestenet, andypost, fjgarlin, drumm, moshe</p>